Google Lighthouse for Beginners: A Real Portfolio Optimization Case Study

Source: Dev.to

Introduction

You’ve learned what Google Lighthouse is, how it works, and what the metrics mean. Most tutorials stop there, but this article shows you how to actually improve those scores.

It’s aimed at junior developers—especially those using Lighthouse for the first time—who want practical guidance on acting on Lighthouse reports.

Prerequisites

• Basic understanding of the main Core Web Vitals and loading metrics: FCP, LCP, INP, CLS.

Preparing Your Environment

1. Test in the right environment

   • To measure real‑world performance, run Lighthouse on the live domain where the site is hosted.
   • You can also run it during development or on a local production build to catch issues, but don’t use those results to judge the site’s real performance.

2. Use an incognito window before running Lighthouse. This avoids browser extensions interfering with the test results.

💡 Tip

PageSpeed Insights shows how real users experience your site via the Chrome UX Report (CrUX) data. It’s great for spotting real‑world performance issues and making decisions based on actual user data.

Note: PageSpeed Insights also uses Google Lighthouse, so the lab data, audits, and improvement insights are presented in a very similar way.

Things to Keep in Mind When Analyzing Lighthouse Results

• Scores vary from one scan to another (sometimes by 20–30 points).

  • Run Lighthouse 4–5 times to get a reliable picture.
  • Optionally, run it again after 1–2 hours for a broader view.

• After fixing an issue, don’t just look at the final Performance score.

  • Return to the Insights tab.
  • Verify that the insight is no longer highlighted or that its severity has decreased.
  • Check the accompanying values (time saved, file size, delay) to see actual improvements.

• Some fixes won’t cause a noticeable jump in the Performance score, but they can still boost overall performance.

• You don’t need to fix everything Lighthouse flags.

  • Some items are inherent to how your site is built and may not be worth the effort unless they cause major issues.

• Prioritize:

  • Red (high‑warning) insights usually have the biggest impact and deserve attention first.
  • Yellow (medium‑warning) insights are worth considering, especially when the fix is small and easy.

Practical Walk‑through: My Portfolio

Baseline Lighthouse Runs

Before making any changes, I ran Lighthouse multiple times to establish a reliable baseline.

Why mobile? Google is mobile‑first, and in my case both mobile and desktop load the same assets (only the layout differs). Improving mobile results therefore improves desktop results as well.

Initial Scores

• Mobile Performance Score: 55

Metric Contributions

Takeaway: The page is stable (CLS, TBT) but slow to show content (FCP, LCP, Speed Index). The next steps focus on those three metrics, starting with FCP because getting content on screen earlier usually helps LCP as well.

Targeting FCP

Filtering Lighthouse Suggestions for FCP

Normally I’d start with the Insights tab, but a diagnostic caught my eye:

Potential savings: 2445 KiB from unused JavaScript.

What I Found

• Total built JavaScript bundle size: 2517 KB – absurd for a simple portfolio page.
• Most of the size came from home.js (2005 KB) and index.js (472 KB).

Investigation

I inspected the libraries imported in my components and discovered one library responsible for the bulk of the size. I only needed a small part of it, so I:

1. Changed the import to pull in just the required subset.
2. Re‑built the project.

Result

• Bundle size dropped dramatically (from ~2.5 MB to a few hundred KB).
• The browser now downloads far less code, allowing the page to start rendering much sooner.

Impact on scores:

• Performance score jumped from 55 → 87.
• FCP and LCP improved because the page could display content earlier.

Note: Even though Lighthouse marks “Reduce unused JavaScript” as unscored, cutting down that much JavaScript had a massive effect on the overall performance.

Summary of Fixes

Final Thoughts

• Run multiple Lighthouse audits to get a stable baseline.
• Prioritize high‑severity insights (red warnings) but don’t ignore medium‑severity ones if they’re easy fixes.
• Focus on the metrics that matter most for your current score (e.g., FCP, LCP, Speed Index).
• Even “unscored” suggestions can have a huge impact—always investigate large savings warnings.

By following this systematic approach, you can turn Lighthouse from a static report into a actionable roadmap for real performance improvements. Happy optimizing!

Improving Page Performance: What I Did and Why

1. Reduce JavaScript Bundle Size

• The original bundle was large and slowed the page’s initial load.
• After trimming unused code and lazy‑loading where possible, the JavaScript size dropped dramatically (see the diagnostics screenshot).

2. Self‑Host Google Fonts

Why?

How?

1. Download the required fonts from Google Fonts.
2. Convert the .ttf files to WOFF2 (smaller, web‑optimized).
   • Use a converter or the Google‑WebFont‑Helper site for ready‑made WOFF2 files.

After self‑hosting, the performance score jumped to ≈95‑96 because the external request and its render‑blocking delay disappeared.

3. Prioritize the Largest Contentful Paint (LCP) Image

The LCP image was being fetched with normal priority, causing a delay.

<!-- Placeholder for hero image -->
<img src="hero.jpg" fetchpriority="high" alt="Hero image">

Adding fetchpriority="high" tells the browser to load this image first.
Result: No noticeable change in the numeric score, but it’s a solid best practice for real‑world loading speed.

4. Optimize Image Delivery

• All images (except the LCP image, already only 30 KB) were converted to WebP.
• Combined image size dropped from ≈8 000 KB → 200 KB.

5. Final Results

Note: A few Accessibility and SEO insights were also addressed, but they are omitted here to keep the focus on performance.

6. Network Dependency Tree Insight (Ignored)

Lighthouse flagged a high‑severity “Network Dependency Tree” issue: some resources waited for earlier requests, preventing full parallel loading.

• Fixing it would have required a major rewrite of the page’s architecture.
• The critical‑path latency was only ~300 ms, negligible compared to the other gains.

Thus, I left this as‑is.

7. Keeping Performance Healthy

1. Run Lighthouse after every major change (new section, library, image, etc.).
2. Integrate Lighthouse into CI/CD and enforce a minimum performance threshold – a failing build will alert you immediately.
3. Track key metrics (FCP, LCP, CLS) over time. Export reports (HTML/JSON) to keep a history.
4. Use PageSpeed Insights for real‑user data (CrUX) once traffic grows.
5. Optional advanced monitoring:
   • Add the web‑vitals library to collect real‑user metrics.
   • Feed those metrics into your analytics platform for ongoing visibility.

Bottom line: The goal isn’t a perfect score; it’s understanding and continuously addressing what slows your site. Once you can read a Lighthouse report effectively, deciding what to fix, what to ignore, and how to keep the site fast becomes straightforward.