PageSpeed Insights Score Explained and How to Improve It

Most people meet PageSpeed Insights the same way: someone pastes a URL, a large coloured number appears, and a meeting turns into an argument about why it is 54 and not 90. The number is useful, but it is also easy to misread. It is one slice of a longer report, it comes from a simulated load, and it sits beside a second set of data that comes from real visitors. If you own a site, run SEO or manage marketing and need to talk to developers, understanding what the score is made of is the fastest way to stop chasing the wrong thing.

This guide explains the report from top to bottom, then walks through the improvements that tend to matter for each metric, then closes with a way to measure changes honestly. It is written for readers who are not engineers but need to ask engineers precise questions. Every number in the worksheet near the end is invented for illustration. For a shorter introduction to the same topic, see our shorter page speed and Core Web Vitals guide; this article goes further into how the score is built and how to act on it.

What PageSpeed Insights Actually Reports

Two sources of data in one page

PageSpeed Insights, usually shortened to PSI, is a Google tool that analyses the performance of a single URL and returns suggestions. According to Google's documentation, its report combines two kinds of data. The first is lab data, produced by Lighthouse, an open-source tool that loads the page in a controlled, simulated environment. The second is field data, which reflects what real users experienced and is powered by the Chrome User Experience Report, usually shortened to CrUX.

Google describes the difference plainly: field data is a historical record from many users on varied devices and networks, while lab data is one simulated load on a single device and a fixed network. Lab data is useful for debugging because you can repeat it, but the documentation warns that it may not capture real-world bottlenecks.

What the field section covers

The field section shows distributions of real visits for metrics such as First Contentful Paint (FCP, the time until the first piece of content appears), Largest Contentful Paint (LCP, the time until the largest visible element is rendered), Interaction to Next Paint (INP, how quickly the page responds to user input) and Cumulative Layout Shift (CLS, how much the layout jumps around). Google notes that these field metrics reflect the previous 28-day collection period, so a fix you shipped yesterday will take weeks to be fully visible there.

If a page does not have enough data of its own, PSI falls back to origin-level data, which covers all pages of the site. If the origin also lacks data, no field data is shown at all. That is common for new or low-traffic pages, and it does not mean the page is broken.

What the lab section covers

The lab section starts with four category scores: Performance, Accessibility, a category for general web practices, and SEO. This article concerns only Performance. Below the scores you see the individual performance metrics, then a long list of audits with suggested improvements. Treat the lab section as a repeatable test bench and the field section as the verdict from actual visitors.

What the 0 to 100 Score and Its Colors Mean

The three colour bands

Lighthouse documentation uses three bands for the performance score. A score from 90 to 100 is green and counts as good. A score from 50 to 89 is orange and means the page needs improvement. A score from 0 to 49 is red and counts as poor. These are fixed labels attached to a number, not a ranking against other websites.

How the number is calculated

The overall score is a weighted average of individual metric scores. Each raw metric value, for example an LCP of 3.1 seconds, is converted into a 0 to 100 metric score using a curve built from real-world HTTP Archive data. In Google's description, a metric value at the 25th percentile of that data maps to a score of 50, and a value at the 8th percentile maps to 90. The practical meaning is that moving from very slow to moderate is relatively easy, while the last few points near the top require disproportionately more effort.

One detail is easy to miss: the Opportunities and Diagnostics lists do not feed the score directly. They are suggestions. Following them often improves the metrics, and the metrics are what move the score.

Why a single number hides detail

Two pages can both score 72 for different reasons. One may have a slow server response and clean scripts; the other may respond fast and then freeze while a pile of JavaScript runs. The remedies are completely different. Always look at which metrics dragged the score down before you decide what to fix.

Why Lab Data and Field Data Disagree

Different devices, different networks, different moments

It is perfectly normal to see a red lab score next to a green field assessment, or the reverse. Lab data comes from one simulated load. Field data comes from the people who actually visit, and many of them use faster devices than the simulated phone, or they revisit the page with warm caches. The reverse also happens: a site whose audience is mostly on older phones and weak connections can look fine in the lab and weaker in the field.

Different metric sets

The two sections do not even measure the same things. A lab run reports Total Blocking Time (TBT, the amount of time the main thread was blocked by long tasks while the page loaded), which is a lab-only proxy for responsiveness. Field data reports INP, which is gathered from real interactions that a lab run does not perform. A page can have a poor TBT and still have an acceptable INP if visitors rarely trigger the heavy code paths, and the opposite is possible too.

Different time windows

The lab result is a snapshot from the moment you pressed the button. The field result averages the last 28 days. If you ran a campaign that brought a different audience, shipped a new script last week, or changed a template, the two will drift apart until the field window catches up. Ask which of the two answers your question: lab data tells you what a change did right now, field data tells you what visitors have been living with.

What to do when they conflict

Do not average them and do not pick the more flattering one. Use the field data to decide whether there is a real problem for visitors, and use the lab data to find the cause and to check a fix. If field data is missing, say so in your report rather than filling the gap with lab numbers.

Mobile and Desktop Results

What the mobile test simulates

PSI offers separate mobile and desktop tabs. According to the documentation, the mobile test simulates a mid-tier phone, the documentation names a Moto G4 as the reference, on a mobile network, while the desktop test emulates a desktop machine on a wired connection. The tests run in a Google datacenter in North America, Europe or Asia, and the Lighthouse environment block in the report shows which one was used.

Throttling in plain words

Throttling is the simulated limit on network and CPU applied during the lab test. The mobile profile is deliberately slower than the desktop profile. That is why a page that scores comfortably on desktop can drop dramatically on mobile with no change to the code: the same JavaScript simply takes longer on a slower simulated processor, and the same images take longer on a slower simulated network.

Which tab matters more

Look at the device split of your real visitors in your analytics and Search Console before deciding. If most visitors use phones, the mobile tab is closer to their reality, and mobile also relates to how Google crawls; see our mobile-first indexing checklist for that side. Google also scores desktop with its own curves, so a desktop 95 and a mobile 95 are not interchangeable achievements.

The Metrics Behind the Performance Score and Their Weights

The five weighted metrics

According to the Lighthouse performance scoring documentation for Lighthouse 10, the performance score is built from five metrics with these weights. Earlier versions used different weights, for example Time to Interactive carried weight in Lighthouse 8, so an old screenshot may not match a new report.

What the weights tell you about priorities

Three metrics, TBT, LCP and CLS, carry 80 percent of the score between them. TBT alone is the largest slice at 30 percent. A page whose main problem is heavy JavaScript can therefore lose a lot of points even if it looks fast. Equally, fixing a layout shift problem affects a quarter of the score. FCP and Speed Index matter, but they are the smaller levers.

Why you cannot trade one metric for another freely

Because the score is a weighted average of curved metric scores, a very good result on one metric cannot fully rescue a very poor result on another. Read the individual metric values rather than the total, and set goals metric by metric, a method this guide returns to in the measurement section.

Core Web Vitals: Thresholds and the 75th Percentile Rule

The three targets

Core Web Vitals are the subset of metrics Google asks site owners to watch for real-user experience. The documented good thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less. In Search Central, Google words the same targets as aiming for LCP within the first 2.5 seconds, an INP of less than 200 milliseconds and a CLS of less than 0.1.

What the 75th percentile means

Google's guidance says to measure the 75th percentile of page loads, separately for mobile and desktop, and a page passes only if it meets all three targets at that percentile. Picture 100 real visits sorted from fastest to slowest: the 75th percentile is the experience of the visit at position 75. It deliberately reflects harder experiences rather than the average, so a site cannot pass simply because most visitors are on fast devices.

A pass is all three together

The assessment is not a score you average. Meeting LCP and CLS but missing INP means the page does not pass. When someone reports that the Core Web Vitals assessment failed, ask which of the three metrics was outside its threshold and for which device type.

From FID to INP

You may still see older articles and plugins that mention First Input Delay (FID). According to the web.dev documentation, INP was promoted from experimental to pending in 2023 with the intent to eventually retire FID, and it became a stable Core Web Vital in 2024. INP is broader: instead of looking only at the delay before the first interaction starts being handled, it considers the responsiveness of interactions across the visit. If a vendor still sells you an FID fix, ask what it does for INP.

Reading the Report: Opportunities, Diagnostics and Passed Audits

Opportunities versus diagnostics

Below the metrics the lab report lists audits with suggestions. Opportunities typically point to specific resources that could load faster. Diagnostics describe broader properties of the page, such as how much work the main thread did. As noted above, neither list is part of the score formula; they are leads for investigation. A large estimated saving in an opportunity is a hint, and the metric value you measure afterwards is the evidence.

How to triage a long list

Reading the whole list top to bottom wastes time. A workable routine looks like this:

1. Note which of the five weighted metrics are weak.
2. Open only the audits that relate to those metrics.
3. Group the findings by who can fix them: content team, template developer, server administrator or a vendor script.
4. Write down the expected effect on a metric, not on the score.

Passed audits and the trap of ignoring them

The passed audits section is collapsed by default, and it is worth opening once. It tells you what already works, such as image dimensions being set or text compression being active, so your team does not undo it by accident during a redesign. It also stops you reporting an existing strength as a new fix.

Treat the field assessment as the starting question

Open the report in this order: field assessment first, then the lab metrics, then the audits. If the field assessment already shows good values for all three vitals, the audit list becomes a nice-to-have list rather than an emergency.

Improving Largest Contentful Paint

Break LCP into four parts

The web.dev guidance on optimizing LCP splits the time into four subparts: Time to First Byte (TTFB, the wait until the server starts to answer), resource load delay, resource load duration and element render delay. As a guideline, not a strict rule, it suggests roughly 40 percent of the time goes to TTFB, under 10 percent to load delay, roughly 40 percent to load duration and under 10 percent to render delay. The guide also cautions against turning those percentages into fixed millisecond targets; the subparts are meaningful relative to one another. The practical use is diagnostic: find the largest subpart of your page and begin there.

Server response and TTFB

For TTFB the guidance is to minimize redirects, since visitors who arrive through several redirects wait longer, and to avoid unique URL parameters that prevent a content delivery network from serving cached copies. If you have long redirect chains from old campaigns, our redirect chain cleanup guide shows how to find and shorten them.

Resource load delay: let the browser find the image early

Load delay is the gap between the page starting and the browser beginning to fetch the LCP resource. It grows when the image is referenced only inside an external stylesheet or script. In that case the guidance is to preload the image from the HTML with a high fetch priority so it is discovered early. For a normal image in the page markup, set the fetchpriority attribute to high on the one image that is likely to be the LCP element. The guidance warns that setting it on more than one or two images makes it less useful.

Never lazy load the LCP image

The same guide states that you should never lazy load your LCP image, because that always leads to unnecessary resource load delay. This is one of the most common self-inflicted problems: a plugin or template applies the loading attribute set to lazy to every image, including the hero. Check the image at the top of your page and make sure it is loaded eagerly, while images far below the first screen can stay lazy.

Load duration and render delay

Load duration is mostly about file size and network, which the image section below covers. Render delay is what happens when the element has downloaded but cannot be painted yet, for example because it waits behind render-blocking stylesheets or a script that must run first.

Improving Total Blocking Time and INP

Why TBT and INP are cousins

Both come from the same underlying issue: the browser's main thread is busy and cannot respond. TBT measures that busyness during load in the lab; INP measures how long real interactions take. Web.dev describes INP as the sum of three parts: input delay (the wait until event handlers start running), processing duration (how long the handlers take) and presentation delay (the time until the next frame is painted). Long tasks and script activity can extend input delay, heavy handlers extend processing, and large layout or style work extends presentation.

Cut the amount of JavaScript that runs

The documentation notes that script evaluation, meaning parsing, compiling and executing, can introduce long tasks on the main thread and delay the response to user input. The simplest lever is to ship less script: remove features nobody uses, avoid loading a whole library for one function, and load code only on the pages and interactions that need it. Splitting a large bundle into smaller pieces that load on demand is a request you can pass to developers in those exact words.

Break up long work in event handlers

For handlers that do a lot, the guidance is to split the work into separate tasks so the browser can paint in between. It mentions that setTimeout is one way to do this because the callback runs as a new task, and it suggests yielding right after the code that updates the interface, while postponing non-critical work such as saving or spell checking. As a site owner you do not need to write this, but you can ask: after a click, what runs before the screen updates, and can anything wait?

Third-party code on the main thread

Chat widgets, tag managers, personalization and ad scripts all execute on the same main thread as your own code. The next sections cover them in more detail; for now, note that auditing them often yields larger savings than polishing your own scripts.

Improving Cumulative Layout Shift

Images and video without dimensions

According to web.dev, the first thing to check is whether images and video elements carry width and height attributes, or whether space is reserved with the CSS aspect-ratio property. Browsers use those attributes to set a default aspect ratio before the file loads, so the text below the image does not jump down when it arrives. The guide puts it directly: always include width and height size attributes on images and video elements. In a content management system this usually means a template setting rather than editing each post.

Ads, embeds and iframes

The same article advises reserving space for ads, embeds and iframes with a minimum height or an aspect ratio, and keeping a placeholder when no ad loads, because collapsing the reserved space can cause a shift of its own. If you sell or display advertising on your pages, this is the most important CLS habit to agree on with whoever supplies the creatives.

Content injected after load

Banners, cookie notices, newsletter bars and recommendation blocks that appear above existing content push everything down. Web.dev suggests reserving space for them, placing them lower in the viewport, or letting the user trigger them, for example through a button. It also notes that shifts within 500 milliseconds of a user input are not counted, which is why content that appears after a click is treated differently from content that appears on its own.

Web fonts and animations

For fonts, the guide recommends choosing a fallback font, reducing size differences with the size-adjust descriptor and related overrides, preloading critical fonts and using the font-display value optional when you want to avoid a re-layout entirely. For animations, use transform changes rather than properties such as top and left, which trigger layout. Finally, keeping pages eligible for the back/forward cache lets returning visitors see a restored page without new shifts.

Network and Server Side

Start with the server response

If the largest subpart of your LCP is TTFB, no amount of image work will fix it. Typical reasons for a slow first byte include heavy page generation, slow database queries, missing page caching, and redirects before the final URL. Ask your developer or hosting administrator to measure server response time for the page separately from the front end, and compare a logged-out request with a logged-in one if your site personalizes pages.

Compression and caching in general terms

Text resources such as HTML, CSS and JavaScript are normally sent compressed, and static files such as images, fonts and stylesheets can be given cache headers so that returning visitors do not download them again. These are standard server settings, so the useful question to ask is simply whether they are enabled and verified on the files that matter, not which setting name to use. Be careful with pages that contain personal or account-specific information: those should not be cached publicly.

Protocols and delivery networks

Modern HTTP versions allow many files to be requested efficiently over one connection, and a content delivery network places copies of static files closer to visitors. Both are infrastructure decisions with costs and trade-offs, and they help most when visitors are geographically spread out. Treat them as options to evaluate with measured TTFB and load duration rather than as default fixes.

Avoid breaking caches by accident

As the LCP guidance notes, unique URL parameters can prevent edge servers from serving cached content. Tracking parameters appended to every link, or random version strings on assets, are common causes. Review how your campaign links and asset URLs are built.

Images: Format, Size and Loading

Choose modern formats and sensible dimensions

Images are often the largest files on a page and frequently the LCP element. Modern formats such as WebP and AVIF generally produce smaller files than older formats at comparable visual quality, though results depend on the image, so test your own files. The more reliable win is dimension: an image displayed 600 pixels wide should not be served as a 3000 pixel original. For deeper guidance on the search side of images, our image SEO guide covers file naming, alt text and image discovery.

Responsive images

The HTML srcset and sizes attributes let the browser pick a suitable file for the screen width. If your template outputs a single large file for every device, phones download far more than they can display. This is a concrete item to request from a developer and easy to verify in the Opportunities list.

Lazy loading rules

Lazy loading, set with the loading attribute, delays images until the visitor scrolls near them. It suits images below the first screen. It does not suit the image at the top of the page, as the LCP section explained. Also keep width and height set on lazy images, otherwise the late arrival creates layout shift.

Backgrounds and decorative graphics

An image set as a CSS background is discovered later than one in the markup, because the browser must first read the stylesheet. If a background image is your LCP element, either move it into the markup or preload it with a high fetch priority.

CSS, Render-Blocking Resources and Fonts

What blocks rendering

Stylesheets and some scripts in the head of a page can stop the browser from painting until they are downloaded and processed. This affects FCP, LCP and the render-delay part of LCP. The Opportunities list usually names the specific files. A good first step is to list them and ask for each one whether it is needed for the first screen.

Trim unused CSS and JavaScript carefully

Audits often report unused CSS and JavaScript. Be cautious: code that is unused on the tested page may be needed on another page, in another state or after an interaction, such as a menu, a form error or a checkout step. Remove code only after testing those states; silencing an audit is not a goal in itself.

Deferring non-critical scripts

Scripts that are not needed for the first render can be loaded with the defer or async attribute so they do not block parsing. The right choice depends on whether a script depends on others, so developers should test the order before changing a whole page.

Fonts without shifts or delays

Custom fonts can cause two problems: invisible or swapped text while they load, and layout shift when the fallback and final fonts have different sizes. The mitigations are the ones above: a close fallback font, the font-display setting chosen deliberately, preloading the few fonts used in the first screen, and loading fewer font weights. Every extra weight is another file.

Third-Party Scripts and Ads

Why third-party code deserves its own audit

Analytics, tag managers, chat widgets, consent tools, social embeds, maps and ad scripts are written and updated by other companies. They can add network requests, execute long tasks and inject content that shifts the layout, and you do not control their release schedule. That is also one reason lab scores vary: the documentation lists changing ads and A/B tests among the causes of fluctuation.

A simple inventory method

List every external script your pages load, with a column for the owner, the purpose, the pages it runs on and the date someone last confirmed it is still needed. Remove scripts with no owner. Load the rest only on pages that need them, and ask whether a lighter option exists for the same purpose.

1. Open the network view of a browser developer tool and filter by third-party domains.
2. Note the size and number of requests per vendor.
3. Compare the lab report with each major script temporarily disabled on a test copy.
4. Decide keep, delay or remove, and record the decision.

Ads and the balance between revenue and speed

Advertising is a legitimate part of many publishers' business, and it pulls in both script weight and layout instability. The practical balance is to reserve space for every ad slot, avoid placing the largest ad in a position that becomes the LCP element, and limit the number of slots above the fold. Our article on ads and Core Web Vitals for publishers walks through that trade-off, and placing ads without hurting user experience covers the layout side.

Akua Adforce is a marketplace where publishers list ad space and buyers browse listings. For a publisher, the point of this section is simple: a clean, stable page makes any ad slot easier to evaluate for both sides. Akua Adforce does not run or measure speed tests for your site.

How to Measure Changes Without Fooling Yourself

Expect run-to-run variance

The Lighthouse documentation says scores can fluctuate because of factors outside Lighthouse itself: A/B tests, changing ads, internet routing changes, differences between test devices, browser extensions that alter requests or inject JavaScript, and antivirus software. It recommends thinking of performance as a distribution of scores rather than a single number. In practice that means running the same page several times and looking at the spread before concluding that a change worked.

A repeatable testing routine

1. Pick a short list of representative pages: the home page, a typical content page, a listing or category page and a conversion page.
2. Test each page at least three to five times before the change and again after it, using the same device type.
3. Record the individual metric values for each run, not only the score.
4. Compare the middle value and the range, not the single luckiest run.
5. Check the field data again after the 28-day window has had time to fill with post-change visits.

Set goals per metric

A goal such as "get to 90" tells nobody what to do. A goal such as "bring LCP on the article template under 2.5 seconds on mobile" is specific and testable, and it points to a responsible owner. Pair each goal with the field metric that proves it worked for real visitors.

Keep a change log

Write down every deploy that touches templates, scripts, images or server settings, with a date and a short description. When a metric moves, you can then look back and see what changed, including changes you did not make yourself, such as a vendor script update. Your search performance data can complement this record; our Search Console performance report guide shows how to read page-level trends alongside your change dates.

Prioritizing the Work: Impact Versus Effort

A priority table

The table below is a general planning aid, not a measured ranking of fixes. Impact depends on your pages, so confirm each row against your own report.

Quick wins first, structural work second

Low-effort items that address a clear problem come first, because they can be shipped and checked within days. Larger items such as bundle splitting or server work need planning, so start the conversation early even while quick wins are being shipped.

Do You Need a Score of 100? Common Mistakes

Why 100 is not the finish line

The scoring curve makes the final points expensive, and the Lighthouse documentation itself notes that scores vary by environment. A page at 92 with good field metrics is in a healthier position than a page chased to 100 by removing features visitors use. Aim for green in the field assessment on the pages that matter, and let the lab score confirm the direction.

Mistakes that appear again and again

• Testing only the home page and assuming every template behaves the same.
• Comparing one run before with one run after.
• Treating the Opportunities estimates as promises instead of hints.
• Removing code flagged as unused without checking menus, forms and other states.
• Lazy loading every image, including the top one.
• Fixing the desktop score while most visitors use phones.
• Adding a performance plugin or script that itself adds weight, then not re-testing.
• Ignoring the 28-day field window and declaring failure after two days.

Do not tune a page only for the test

Hiding content from the test, serving a different page to measurement tools or delaying useful elements only to improve a number defeats the purpose, since real visitors still experience the page as it is. Improve the page, then let the metrics follow.

PageSpeed and SEO: What Google Actually Says

The documented position

Google's Search Central documentation says: "We highly recommend site owners achieve good Core Web Vitals for success with Search." It adds that this, together with other page experience aspects, aligns with what its core ranking systems seek to reward. That is the extent of the statement. It does not claim that a PageSpeed Insights score is a ranking factor, and it does not promise that improving a score changes a position.

How to use that sensibly

A fast, stable page is better for the person reading it, which is a good reason to care about it even without a ranking argument. Search results depend on many things, including relevance and content quality, so treat speed work as one part of a technical program rather than a shortcut. If you want a structure for the wider program, our technical SEO audit checklist places speed alongside crawling and indexing checks, and our JavaScript SEO guide is worth reading when heavy scripts are the bottleneck.

What not to claim

Avoid telling colleagues or clients that a higher score will bring more traffic. The only supportable claims are about the measured metrics: a lower LCP, a lower CLS, a faster response to input. What those changes do to visits, sales or rankings has to be observed over time, not assumed.

Sample Template: PageSpeed Improvement Worksheet

The worksheet below uses made-up example values only. It does not describe a real site. Copy it into a spreadsheet and replace every value with your own measurements.

How to use the worksheet:

1. Fill the Before column from the median of several runs.
2. Write one planned action per row so its effect can be separated.
3. Log the deploy date in your change log.
4. Fill the After column with new medians, then compare field data after the 28-day window.

Columns worth adding if your team needs them:

• Field assessment status (pass or fail) per device type.
• Ticket or task reference.
• Notes on anything outside your control, such as a vendor script update.

Frequently Asked Questions

What is a good PageSpeed Insights score?

Google's Lighthouse documentation treats 90 to 100 as good (green), 50 to 89 as needs improvement (orange) and 0 to 49 as poor (red). A green score is a useful signal, but check the individual metrics and the field data too. A lower score with passing Core Web Vitals in real-user data may need less urgent work.

Why does my score change every time I test?

Lighthouse scores vary between runs because of network conditions, test device differences, changing ads, A/B tests, extensions and other factors outside the tool. Google suggests thinking of performance as a distribution of scores. Run the same page several times, compare medians and the range, and avoid judging a change from a single run.

What is the difference between lab data and field data?

Lab data comes from Lighthouse loading your page once in a controlled, simulated environment, which makes it repeatable and good for debugging. Field data comes from real Chrome users through CrUX, covers the previous 28 days and shows what visitors actually experienced. They can disagree, and both are worth reading.

Which Core Web Vitals thresholds should I aim for?

The documented good thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less, measured at the 75th percentile of page loads and separated into mobile and desktop. A page passes the assessment only when it meets all three together.

Does a higher PageSpeed score improve my Google ranking?

Google does not say that. Its documentation recommends good Core Web Vitals and says they align with what its core ranking systems seek to reward, alongside other page experience aspects. It does not promise ranking changes from a higher PSI score. Improve speed for visitors, and measure results over time without assuming an outcome.

Where should I start if my mobile score is red?

Open the lab metrics and see which of the five weighted ones is weakest. Common first checks are the top image (not lazy loaded, correctly sized), image dimensions for layout shift, and heavy third-party scripts for blocking time. Fix one item at a time, test several runs and keep a change log.

Conclusion and Next Step

What to carry away

A PageSpeed Insights score is a weighted summary of five lab metrics, shown next to field data from real visitors. The colours are fixed bands, the weights favour blocking time, loading and layout stability, and the Core Web Vitals pass or fail is decided by real-user data at the 75th percentile. Improve one metric at a time, test repeatedly, keep a log and be honest about what you can and cannot conclude.

A practical next step

Run the worksheet above on three representative pages this week, pick the single weakest metric and ship one low-effort fix. When you are ready to read more about the wider search side of the site, browse the SEO guide articles for related topics.