How to Run a Lighthouse Performance Audit and Actually Fix the Findings

Step 1: Run the Audit the Right Way

In Chrome, open the page, press F12 for DevTools, and select the Lighthouse panel. Choose Mobile device emulation, tick the Performance category (add the others if you want them), and click Analyze page load. Lighthouse reloads the page with simulated throttling, a slower CPU and a fast 3G class network, and produces the scored report in under a minute.

Three habits make results trustworthy. Run in an incognito window, because extensions inject scripts that show up in your findings; you end up optimizing your ad blocker. Close other heavy tabs, since Lighthouse borrows your machine's CPU and a busy machine skews timings. And run three times, taking the middle result: variance of a few points between identical runs is normal and means nothing.

The same engine runs in other wrappers when DevTools does not fit. PageSpeed Insights runs Lighthouse on Google's servers, removing your machine from the equation and adding real user field data alongside, the distinction covered in our website speed test guide. The CLI, npm install -g lighthouse, then lighthouse https://example.com --output html --output-path report.html, scripts audits for multiple URLs, and the node module drives programmatic runs, including against authenticated pages when paired with browser automation.

Step 2: Understand What the Score Actually Is

The performance score is a weighted blend of six lab metrics, and knowing the weights tells you where points live. In current Lighthouse versions: Total Blocking Time carries 30%, Largest Contentful Paint 25%, Cumulative Layout Shift 25%, First Contentful Paint 10%, and Speed Index 10%. Each metric's value converts to points on a curve calibrated against real website data, then the weighted blend produces the score. Ninety and above shows green, 50 to 89 orange, below 50 red.

The practical implications: TBT, which measures how long the main thread was blocked by long JavaScript tasks, is the single heaviest lever, which is why script-heavy sites score poorly even when they look fast. LCP and CLS together carry half the score and are also two of the three Core Web Vitals, so improving them pays twice, in the lab score and in the field assessment Google ranks with. TBT itself is the lab stand-in for INP: both punish long main thread tasks, so TBT fixes generally improve INP too.

One warning against score-chasing: the score is a compressed summary for humans, and the metrics are the real targets. A page at 78 with LCP at 2.1 seconds is in better shape than a page at 85 with LCP at 3.8 seconds and a suspiciously light script load. Judge changes by metric values, and treat the score as a communication device for stakeholders who want one number.

Step 3: Work the Findings in Order of Leverage

Below the metrics, the report lists opportunities, changes with estimated savings, and diagnostics, structural information without direct estimates. The estimates are rough and do not sum, but the ordering is useful, and the same handful of findings top the list on most sites.

Image findings usually lead: properly size images (a 2000 pixel image in a 400 pixel slot), serve images in next-gen formats (WebP or AVIF over JPEG and PNG), defer offscreen images (lazy-load below the fold), and efficiently encode images (compression quality). Together they are usually the largest byte savings on the page, and the fixes are mechanical: an image pipeline or CDN that resizes, converts, and compresses automatically clears all four findings site-wide at once.

Eliminate render-blocking resources points at stylesheets and synchronous scripts in the head that delay the first paint. The fix pattern: inline the small amount of CSS needed for above-the-fold content, load the rest asynchronously, and add defer to every script that does not need to execute before render, which is nearly all of them. Reduce unused JavaScript and Reduce unused CSS quantify how much of your bundles the page never executes; the Coverage panel in DevTools shows the same data live, and code splitting plus dropping dead third-party tags is the durable fix. Minimize main-thread work and Avoid long main-thread tasks are the TBT diagnostics, pointing at the scripts that block interactivity, with third-party tags frequently the worst offenders, each one visible under Reduce the impact of third-party code with its cost in milliseconds attached.

Server findings appear as Reduce initial server response time when TTFB is high, and no frontend fix compensates for a slow origin: caching, CDN, and query optimization per our speed testing guide are the levers. For sites with deeper structural issues across many pages, a crawl-based technical audit such as SE Ranking's website audit complements per-page Lighthouse runs by finding slow, broken, and misconfigured pages across the whole site in one pass.

Step 4: Rerun, Compare, and Know the Tool's Limits

After each meaningful fix, rerun under identical conditions, same wrapper, same device setting, incognito, median of three, and compare metric values against your recorded baseline. Keeping a simple log of date, change, and metrics turns optimization into a sequence of verified wins rather than vibes. Expect diminishing returns: the first day of image and script work often moves a score 20 points, the following week moves it 5, and pushing 95 to 100 is rarely worth the engineering time it costs.

Know what Lighthouse cannot tell you. It is a lab tool: one synthetic load, no login, no real audience variance, which is why a green lab score and a failing field assessment coexist on pages whose real visitors carry older phones than the simulation. Field data from PageSpeed Insights or Search Console remains the verdict on user experience, with Lighthouse as the diagnostic that explains it. Lighthouse also only sees the load it measured: anonymous, cold cache, landing page style. Authenticated flows, cart states, and post-interaction performance need scripted measurement, the territory of our Playwright performance guide. And a perfect score does not mean the site survives traffic, capacity is the domain of load testing, an entirely separate discipline.

Step 5: Automate with Lighthouse CI

Manual audits catch today's problems; automation prevents next quarter's. Lighthouse CI (LHCI) runs audits in your pipeline on every build, compares results against budgets committed to the repository, and fails the build when a budget breaks. Setup is a config file declaring the URLs to audit and assertions like LCP under 2.5 seconds, TBT under 300 milliseconds, CLS under 0.1, plus a pipeline step running lhci autorun. The LHCI server, or its GitHub integration, tracks score history per commit, so the answer to "when did the product page get slow" becomes a graph with a culprit commit instead of an archaeology project.

Budget on metric values rather than the overall score: scores wobble a few points run to run, which makes score-based gates flaky, while a metric regression from 2.1 to 3.4 seconds is unambiguous and worth a red build. Audit a representative set, home page, one product or article template, checkout or signup, rather than every URL, since template-level regressions cover most real-world cases. This slots into the same pipeline discipline as the rest of your automated checks, covered in CI/CD test automation, and pairs with scheduled production monitoring from website monitoring for changes that never pass through the pipeline, third-party script updates being the classic example.