How to Run a Google Lighthouse Performance Test and Raise Your Score

A Lighthouse performance test is often the first thing a client shows me on a discovery call. Someone ran PageSpeed Insights, saw a red 41 on mobile and now wants it green by Friday. I understand the urge. However, a score without context leads to the wrong fixes in the wrong order. In this guide I explain how to run the test properly, how to read the report and how to solve the recommendations that matter most.

What is a Lighthouse performance test and what does it measure?

A Lighthouse performance test is a lab measurement in which Google's open source Lighthouse tool loads a page under fixed, throttled conditions and scores it from 0 to 100 based on five metrics. It reflects one simulated page load, not the experience of your real visitors.

The five Lighthouse performance metrics are First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time and Cumulative Layout Shift. Each one gets its own score. Then Lighthouse combines them into a weighted average, and that average is the big number at the top of the report.

Lighthouse also runs three other categories: Accessibility, Best Practices and SEO. They matter, but this guide focuses on performance, because that is where most teams lose time. One more point before we start. Lighthouse does not only grade the page; it also lists the files behind each problem and an estimated saving. So treat the report as a diagnosis, not a report card. A report card tells you whether you passed. A diagnosis tells you where it hurts and why.

How is Lighthouse different from PageSpeed Insights?

Both use the same engine. The difference is where the test runs and what data comes with it. Lighthouse runs on your own machine inside Chrome DevTools, from the command line or through Lighthouse CI. PageSpeed Insights runs Lighthouse on Google's servers and adds real user data from the Chrome User Experience Report (CrUX).

In practice I use both. First I open PageSpeed Insights to see the field data for the live URL. Then I reproduce the problem locally in DevTools, where I can change code and test again within seconds.

One caution: do not compare scores across tools. PageSpeed Insights emulates a mid-tier mobile device on a throttled network. DevTools applies similar throttling, yet your own processor still affects the result. Therefore, always compare like with like: same tool, same settings, same device.

Why do lab data and field data disagree?

Lab data comes from one simulated device on one simulated connection. Field data comes from real Chrome users who opted in to share usage statistics. According to the PageSpeed Insights documentation, field data covers a trailing 28 day period and Google reports it at the 75th percentile.

Because of that, the two sources can tell different stories about the same URL. Your lab LCP might look slow while your field LCP looks fine, because most of your visitors use recent phones on fast Wi-Fi. The opposite also happens. For example, the lab test may look clean while field INP is poor, because no one clicks anything during a lab test.

So which one should you trust? For decisions, field data wins, because it reflects what people actually experience. Lab data wins for debugging, because you get the result immediately. Keep in mind that field data needs time. After a fix, the 28 day window has to roll over before the improvement shows in full. Also, low traffic pages may not have enough visits for field data at all. In that case, you only have the lab result to work with.

What are the ways to run a Lighthouse performance test?

You have four options. The right one depends on who runs the test and how often:

• PageSpeed Insights: Paste a URL and read the result in your browser. No setup, so it suits marketing teams and managers.
• Chrome DevTools: Open DevTools, switch to the Lighthouse panel and generate a report. It works on staging and on pages behind a login.
• Command line: Install the npm package with "npm install -g lighthouse" and run it against any URL. It makes repeated runs and scripted comparisons easy.
• Lighthouse CI: It runs on every deploy and can fail a build when a metric drops below your budget.

For a small business website, the first two are enough. However, if your team ships changes to a store several times a week, you need the command line or Lighthouse CI. Otherwise regressions slip through and nobody notices until sales drop.

How do you run the test step by step in Chrome DevTools?

DevTools gives you the most control. This is the routine I follow on every project:

1. Open Chrome in an Incognito window. Extensions distort results, and Incognito disables most of them.
2. Load the page you want to test, press F12 and open the Lighthouse panel.
3. Choose Navigation mode. It measures the initial page load.
4. Choose Mobile first, since Google uses the mobile version for indexing.
5. Tick only Performance. The run finishes faster and the report stays focused.
6. Click "Analyze page load" and leave the tab alone until the report appears.
7. Repeat the run at least three times and write down the median.

Also save each report as JSON or HTML. When you test again after a fix, you can put the two reports side by side and see exactly what changed. Timespan mode is useful too. It records what happens while you click through the page, which helps when you hunt for interaction problems.

How does Lighthouse calculate the performance score?

The Lighthouse performance score is a weighted average of five metrics. The Chrome for Developers scoring guide lists the current weights:

• Total Blocking Time: 30 percent.
• Largest Contentful Paint: 25 percent.
• Cumulative Layout Shift: 25 percent.
• First Contentful Paint: 10 percent.
• Speed Index: 10 percent.

Each raw value sits on a scoring curve that Google derives from real website data in the HTTP Archive. The same guide defines the color bands. A score from 0 to 49 is red, 50 to 89 is orange and 90 to 100 is green.

The practical lesson is simple. Three metrics carry 80 percent of the score. In other words, you cannot lift the score for good without fixing TBT, LCP and CLS. Also note that the curve is not linear. Moving from 50 to 70 is usually quick. Moving from 90 to 100 often takes a disproportionate amount of work.

Why does the score change every time you run it?

Running the same page twice and getting a Lighthouse performance score of 71 and then 78 is normal. The Chrome scoring guide names the usual suspects: A/B tests, changes in ad serving, internet routing changes, different devices, browser extensions and antivirus software.

In my own work, the most common causes are more mundane. The server is busy at that moment. The page cache has not warmed up yet. Third party scripts respond at different speeds on each load. And background apps on the test machine compete for the processor.

For that reason, I never act on a single run. My rule is to run the test at least three times, ideally five, under identical conditions and to record the median. When I measure the effect of a change, I run the before and after tests on the same day, on the same network and on the same machine. That way you can tell whether the difference comes from your fix or from noise. I treat differences under five points as noise. That threshold is a starting rule from field experience, not a guarantee.

How should you read a Lighthouse report?

Read a Lighthouse performance report in order of importance, not from top to bottom. Start with the Metrics section. Which of the five metrics are red or orange? This table tells you more than the overall score, because it tells you what kind of problem you have.

Next, move to the Insights section. With Lighthouse 13, Google merged many older audits with the insights from the DevTools Performance panel. For example, separate warnings about image formats, compression and sizing now appear under one "Improve image delivery" insight. Each insight shows an estimated saving and the resources involved.

After that, check Diagnostics. These items do not change the score directly, but they explain the cause: main thread work, DOM size, cache lifetimes and similar details. You can skip Passed audits on the first read.

Finally, use the "Show audits relevant to" filter. Click LCP and the report only shows items that affect LCP. This filter is the fastest way to find the biggest item without drowning in warnings.

What should you do when LCP is slow?

LCP marks the moment the largest visible element renders. The good threshold is 2.5 seconds. On business websites, that element is usually a hero image, the first slide of a carousel or a large headline. The "LCP breakdown" insight splits the time into four parts: server response, resource load delay, resource load duration and render delay.

The largest part points to the fix. These are the three cases I see most:

• The browser discovers the image late. A CSS background or a JavaScript slider hides the image from the preload scanner. Use a regular img tag and add fetchpriority="high".
• The hero image uses lazy loading. Adding loading="lazy" to an image above the fold delays LCP directly. Keep lazy loading for images further down.
• The file is far too large. Serving a 3000 pixel photo in a 400 pixel slot wastes bandwidth. Resize it and convert it to WebP or AVIF.

For quick fixes, the image resizer does the job. Still, the lasting fix is a site setup that resizes images automatically on upload.

Why is Total Blocking Time so high?

TBT adds up the time during page load when long tasks keep the main thread busy for more than 50 milliseconds each. During those moments the browser cannot respond to a tap or click. With a weight of 30 percent, it is the single most influential metric in the score.

The cause is almost always JavaScript. Page builders, heavy themes, chat widgets, cookie banners and several analytics tags all compete for the same thread. For instance, I often find a WordPress form plugin that loads on every page even though the only form lives on the contact page.

My order of work is straightforward. First, remove scripts that nobody uses. Then defer or async the rest. After that, load heavy components only when the user interacts with them. The "Reduce JavaScript execution time" and "Minimize main-thread work" items show which files cost the most time.

There is one more thing worth knowing. In Navigation mode, Lighthouse cannot measure INP, because nobody interacts with the page. That is why TBT works as a lab proxy for responsiveness. When you cut TBT, field INP usually improves as well.

How do you fix layout shifts and CLS?

CLS measures how much visible content moves unexpectedly while the page loads. The good threshold is 0.1. We have all tried to tap a button just as it jumped away. That frustrates users and causes mistaken clicks.

The "Layout shift culprits" insight lists the elements responsible. These are the usual causes and fixes:

• Images without dimensions: add width and height to the img tag or set an aspect-ratio in CSS.
• Ads and embeds that load late: reserve a fixed space for them in advance.
• Web fonts that arrive late: check your font-display setting and pick a fallback font with similar metrics.
• Cookie banners and announcement bars that push content down: overlay them in a fixed position instead.

Do not underestimate the cookie banner. On many sites I have audited, it caused most of the CLS on its own, and a few lines of CSS solved it.

How do you solve image delivery recommendations?

In Lighthouse 13, image warnings live in the "Improve image delivery" insight. It checks three things. Is the format modern? Is the compression sufficient? Does the file size match the slot on screen?

The fix therefore has three steps. First, convert JPEG and PNG files to WebP or AVIF; every current browser supports WebP. Second, lower the quality setting to a level nobody notices. Third, use srcset so each screen size downloads a suitable file and phones do not pull desktop images.

Instead of doing this by hand, build a system. On WordPress, an image optimization plugin handles it. On a custom build, an image pipeline that resizes files on upload closes the issue for good. I set up that pipeline on day one of every web design project, because content teams stop resizing photos manually within a few months. For stores with thousands of product photos, the stakes are higher. It is one of the first things I check during ecommerce consulting work.

How do web fonts and caching affect your score?

Brand fonts matter to most companies. However, every weight is a separate file. A theme with two families in four weights each can download eight font files on first load. The "Font display" insight flags cases where text stays invisible until the font arrives.

My advice is to cut the number of weights to two or three, host the fonts yourself in WOFF2 format and set font-display to swap or optional. That way text appears immediately in a fallback font and switches when the brand font is ready. If the fallback has similar metrics, the switch does not create layout shift either.

On the caching side, the "Use efficient cache lifetimes" insight shows files that browsers download again on repeat visits. Give CSS, JavaScript, images and fonts a long cache lifetime and add a version string to file names, so updates still reach users. This setting barely moves the first load score. However, it makes the site feel much faster for anyone who views more than one page.

Finally, confirm that Brotli or Gzip compression is active on the server. I still find it switched off on older shared hosting plans.

How do you remove render blocking resources and unused code?

The browser does not paint anything until it has downloaded and processed the CSS and synchronous JavaScript in the head of the page. The "Render blocking requests" insight lists these files and the time you could save.

Follow these steps. First, extract the critical CSS the first screen needs, inline it and load the rest later. Next, add defer to your script tags; a deferred script downloads without stopping the page from rendering. Then look at "Reduce unused JavaScript" and "Reduce unused CSS". With off the shelf themes, it is common to find that most of the stylesheet goes unused on a given page.

However, be careful here. If you get the critical CSS wrong, the page flashes without styles for a moment, which hurts the experience. So after each change, check the page by eye on a slow connection. The Coverage tab in DevTools shows line by line which code actually runs. It is a good place to start the cleanup.

How do third party scripts affect the score?

Third party scripts are files that load from someone else's domain: analytics tags, ad pixels, chat tools, maps, video embeds and review widgets. The "3rd parties" insight shows the transfer size of each one and the main thread time it uses.

Marketing needs many of these scripts, so deleting everything is not the answer. Instead, ask one question about each tag: which decision does this data support today? Heatmap scripts nobody has opened in years, pixels for ad accounts that no longer run and analytics code loading twice are the leftovers I find most often.

For the scripts you keep, change the timing. Load the chat widget after the first user interaction. Replace a YouTube embed with a thumbnail that loads the player on click. Show a static map image that opens the interactive map on demand. As a result, you keep your measurement and still cut a large share of the initial load. If you manage tags through Google Tag Manager, review the triggers as well, because many tags fire on every page by default.

Why does server response time affect the score?

When the server sends the first byte late, everything after it starts late too. The PageSpeed Insights documentation sets the good threshold for Time to First Byte at 800 milliseconds. In Lighthouse 13, this topic sits under the "Document request latency" insight, which looks at redirects, server time and compression together.

In my experience, typical causes include underpowered shared hosting, no page caching, an outdated PHP version, slow database queries and redirect chains. For example, a chain that goes from http to https, then to www, then to a trailing slash URL costs hundreds of milliseconds before the visitor sees anything.

You can spot redirect chains quickly with the redirect checker. On the server side, page caching, a current PHP version and a CDN bring enough improvement for most business sites. If you are about to move the site, keep these settings on your checklist. My guide on protecting SEO during a website redesign covers the wider process.

What do the Accessibility, Best Practices and SEO categories tell you?

The three non performance categories check basic technical hygiene. Note that Lighthouse 12 removed the PWA category, so older tutorials that mention a fifth circle are out of date.

For example, Accessibility looks at color contrast, alt text, form labels and heading order. Best Practices covers HTTPS, console errors, vulnerable libraries and correct image aspect ratios. SEO checks the basics: a title and meta description, an indexable page, descriptive link text and a valid robots.txt file.

You can fix missing tags with the meta tag generator and create a clean file with the robots.txt generator. That said, a perfect SEO score in Lighthouse does not mean good rankings. The category only confirms that nothing technical blocks the page. It says nothing about content quality, search intent or authority. For a broader technical review, read my article on technical SEO after AI.

How do you prioritize fixes after a Lighthouse performance test?

A Lighthouse performance test can produce dozens of recommendations, and they are not equal. I decide the order with three questions. Which metric does the item affect? How large is the estimated saving? How much effort does the fix take?

This sequence works for most sites:

1. Find the metric that is red in the field data and start there.
2. Take the cheap, large wins: lazy loading mistakes, images without dimensions, unused scripts.
3. Fix server and cache settings, because they help every page at once.
4. Then reduce JavaScript from themes and plugins.
5. Leave architectural changes for last: a new theme, a rebuild or a platform move.

Also think in templates rather than single pages. One fix to the product template improves hundreds of URLs at the same time. So test one sample each from the home page, category pages, product or service pages and blog posts. I explain how I group templates on bigger sites in my guide to category structure for large websites.

Does your Lighthouse performance score need to be 100?

No. The Lighthouse performance score is an indicator, not a goal. Google's Core Web Vitals documentation recommends good Core Web Vitals and bases them on real user data. The Lighthouse lab score itself is not what Search looks at.

Here is what I see in practice. When a mobile score climbs from 65 to 85, users feel the difference. When it climbs from 92 to 99, you often have to give up an analytics tag, a chat tool or a visual effect the brand wants. Whether that trade makes business sense is a separate decision.

My suggested target is this: all three Core Web Vitals green in the field, and a mobile lab score above 70 where possible. Treat that range as a starting point from field experience, not a guarantee. If you are far slower than your competitors, speed is a clear priority. On the other hand, if you are already fast, a few extra points will return less than work on content and conversion. If you are unsure where to focus, we can set that balance together as part of SEO consulting.

How do you measure and protect your improvements?

Speed work is never finished, because sites keep changing. A new plugin, a new campaign pixel or a heavy banner can undo months of gains within weeks. So make measurement a habit.

I use three layers. The first is the Core Web Vitals report in Search Console. It groups URLs by field status and lets you start a validation after you fix an issue. The second is a monthly PageSpeed Insights check, where I test the main templates on the same day and log the results in a spreadsheet. The third, for sites that ship often, is Lighthouse CI with a performance budget that blocks a release when a metric slips.

On top of that, keep a change log. Note the date of every new plugin, removed script or new tag. When the score drops, that log is the quickest route to the cause. In short, a steady measurement rhythm beats a one off speed project.

Summary: a short checklist for your next test

If you want the whole guide on one card, then follow this order in your next Lighthouse performance check:

• Check field data in PageSpeed Insights first and start with any red metric.
• Run lab tests in Incognito, on the mobile setting, at least three times.
• Focus on individual metrics and estimated savings, not the headline score.
• Check the hero image for LCP, JavaScript for TBT and elements without dimensions for CLS.
• Make changes at template level and record each one in a change log.
• Confirm results with 28 days of field data in Search Console.

If you are planning a new site, building these rules into the design from the start costs far less than adding them later. You can find typical budgets on my website design prices page. And if you would like to read your current report together, get in touch.