Optimize PageSpeed: Improve Load Time and Core Web Vitals Properly

Slow websites cost attention. Users do not like waiting, crawlers waste time on sluggish pages, and important content appears later than necessary. Still, PageSpeed is not an end in itself.

A fast page with poor content does not automatically become visible. But a slow page with very good content wastes user experience, conversion potential and technical quality.

This is exactly where three RankScan measures come in: “Slow-loading pages”, “Poor Core Web VitalsCore Web Vitals are a set of Google metrics that measure real-world user experience in the areas of loading performance, interactivity and visual stability.Open glossary entry →” and “Slow pages with search traffic”. All three belong to the Website Health category. Each one relies on its own data source. RankScan measures the first one in its own crawlCrawling is the process by which a search engine bot fetches a URL and downloads its content. It is the first step before a page can be indexed.Open glossary entry →. The second and third read field dataReal User Monitoring (RUM) captures performance and experience data from real users during their actual visit. It provides so-called field data from real-world usage.Open glossary entry → from real Chrome users in the Chrome UX Report (CrUX).

The right interpretation matters:

PageSpeed optimization does not mean chasing a perfect Lighthouse scoreLighthouse is an open-source diagnostic tool from Google that audits a page's performance, accessibility and other quality aspects in a simulated lab environment.Open glossary entry →. The goal is a fast, stable and user-friendly page based on real user dataField data are performance measurements based on real users and their actual devices and connections. They show whether a performance problem is genuinely relevant.Open glossary entry →.

In this article, you will learn what each of the three measures checks, how to check load timePageSpeed refers to the loading time and responsiveness of a website. PageSpeed optimisation covers measures that improve loading time, responsiveness and visual stability.Open glossary entry → and Core Web Vitals yourself and which levers have the greatest effect.

Three Measures, Three Data Sources #

RankScan splits load time and Core Web Vitals into three measures. Each one measures something different. So a page can appear in one measure and not in another.

“Slow-loading pages”: the Fetch in the Crawl #

RankScan fetches every page in the crawl. It measures the time from the request until the HTML response has fully loaded. Time spent in the crawler’s queue does not count. If the fetch takes longer than 3 seconds, the page counts as slow.

The crawl does not load images, scripts or fonts. It does not render the page in a browser either. The value therefore depends mainly on server response, cachingCaching stores previously retrieved content so it is available faster on repeat requests, relieving both servers and the network.Open glossary entry → and the size of the HTML.

Confirmation pages do not count, not even in the total number of pages. One example is the thank-you page after a form. Nobody waits for content there.

“Poor Core Web Vitals”: the Values of the Whole Domain #

This measure reads field data from real Chrome users in the Chrome UX Report. RankScan fetches the values every night, for mobile devices. It rates the value of the whole domain, not of individual pages.

A metric counts when its 75th percentile is in the red:

• LCP above 4 seconds,
• INP above 500 milliseconds,
• CLS above 0.25.

These thresholds match Google’s classification in Search Console.
Source: Google Search Console Help: Core Web Vitals report

The measure counts metrics, not pages. If Google has no field data for your domain, RankScan does not measure this measure. This mainly affects small websites with few Chrome visitors.

“Slow pages with search traffic”: Individual Pages With Clicks #

This measure combines two sources: clicks from Google Search Console and the CrUX values of the individual page. A page counts when both apply:

• It has at least 10 clicks from Google Search in the last 30 days.
• At least one of its metrics (LCP, INP or CLS) is in the red on mobile devices.

RankScan queries the CrUX values per page every night. Up to 100 pages are queried, the pages with the most impressionsImpressions indicate how often a website's search result was shown in Google Search, regardless of whether it was clicked. They are a core Google Search Console metric and reflect a page's raw visibility for given queries.Open glossary entry → in Search Console first. Google only provides values for an individual page when enough Chrome users have visited it. If these values are missing, the page is also missing from this measure.

RankScan sorts the list by clicks and shows at most 50 pages. This measure has the highest severity of the three. These pages already bring visitors from search. A relevant share of the measured mobile visits has a poor loading, interaction or stability experience. This is what the CrUX value at the 75th percentile for mobile devices shows. A poor INP or CLS is not the same as a slow load time. The load time of the HTML file in the crawl is measured only by “Slow-loading pages”.

Typical Slowdowns #

Slow pages usually have several causes. Only some of them show up in the crawl’s HTML fetch. The rest affect visitors and therefore the Core Web Vitals.

• slow server response,
• large images,
• uncompressed assets,
• render-blocking CSSRender-blocking resources are files such as CSS or JavaScript that the browser must load and process before it can render the page, thereby delaying rendering.Open glossary entry →,
• too much JavaScript,
• slow third-party scripts,
• web fonts,
• layout shifts,
• missing caching,
• no Content Delivery NetworkA content delivery network (CDN) is a network of distributed servers that delivers static content closer to the user, reducing loading times.Open glossary entry → (CDN, a distributed server network for faster delivery),
• a heavy theme,
• plugin sprawl,
• client-side rendering.

Important: always assess a slow page together with its page type and its relevance.

A slow product category with revenue potential is more important than a rarely visited archive page.

Why Load Time Matters for Search Engine Optimization (SEO) and Users #

Google describes Core Web Vitals as metrics that measure real user experience in the areas of loading performance, interactivity and visual stability. Google recommends that site owners achieve good Core Web Vitals, both for Search and for good user experience in general.
Source: Google Search Central: Understanding Core Web Vitals and Google Search results

The realistic interpretation:

• PageSpeed is part of page experience.
• Page experience can influence how pages perform in Google Search.
• But it does not replace helpful contentHelpful content refers to content created primarily for people that delivers a clear answer and shows substance, originality and trust, rather than being optimized mainly for search engines.Open glossary entry →, relevance, search intentSearch intent is the goal behind a search query: does the user want to learn something, buy something or reach a specific page? Content only ranks well if it matches this intent.Open glossary entry →, authority or technical indexability.
• Good load time helps especially where user experience and conversion matter.

Google explains in its page experience documentation that page experience is a factor for good content and search experience, but it is not more important than helpful, relevant content.
Source: Google Search Central: Understanding page experience in Google Search results

For RankScan, this means:

Slow pages do not automatically lose rankings, but they are a measurable quality and user-experience problem.

Core Web Vitals: LCP, INP and CLS #

Core Web Vitals measure three central aspects of user experience.

web.dev describes Core Web Vitals as a set of metrics for loading experience, interactivity and visual stability. The recommended thresholds are evaluated at the 75th percentile.
Source: web.dev: Web Vitals

LCP: Make the Main Content Visible Faster #

Largest Contentful Paint measures when the largest visible element in the viewport has loaded.

Often this is the:

• hero image,
• article image,
• large H1The H1 is a web page's main heading. It names the central topic, is visible to users and should generally appear only once per page.Open glossary entry →,
• product image,
• banner,
• large text block.

Poor LCP is often caused by:

• a large hero image,
• a slow server,
• render-blocking CSS,
• lazy loadingLazy loading is the deferred loading of content such as images only when it enters the visible area, in order to reduce the initial loading time.Open glossary entry → on the most important image,
• missing image prioritization,
• slow fonts,
• client-side rendering,
• third-party scripts.

How to Improve LCP #

Important measures:

• compress the hero image,
• use WebPWebP and AVIF are modern, space-saving image formats that produce much smaller files than JPEG or PNG at comparable quality, improving loading time.Open glossary entry → or AVIF, modern space-saving image formats,
• deliver responsive imagesResponsive images deliver an appropriately sized image variant depending on the device's screen size and resolution, so that unnecessarily large files are not loaded.Open glossary entry → with srcset,
• do not lazy-load the LCP image,
• prioritize the LCP image with fetchpriority="high",
• load critical CSS early,
• improve server response,
• delay unnecessary scripts,
• use a CDN for static assets.

Example:

<img
  src="/images/hero.webp"
  srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="..."
>

INP: Improve Responsiveness #

Interaction to Next Paint measures how quickly a page responds to user interactions.

INP replaced the older FID metric. While FID only looked at the first interaction, INP evaluates responsiveness across all interactions on a page.

Poor INP is often caused by:

• too much JavaScript,
• long main-thread tasks,
• heavy frameworks,
• many third-party scripts,
• complex event handlers,
• large bundles,
• chat widgets,
• tracking scripts,
• client-side search or filters,
• unoptimized hydrationHydration is the process of making server-delivered HTML interactive in the browser via JavaScript. The markup already exists; JavaScript only adds the behaviour.Open glossary entry →.

How to Improve INP #

Important measures:

• reduce JavaScript,
• use code splitting,
• delay non-critical scripts,
• review third-party scripts,
• split long tasks,
• optimize event handlers,
• avoid unnecessary re-renders,
• reduce hydration,
• load interactive components selectively.

For JavaScript-heavy websites, INP is often the most important performance lever.

CLS: Avoid Layout Shifts #

Cumulative Layout Shift measures how much elements unexpectedly move while a page is loading.

Poor CLS is often caused by:

• images without width and height,
• ads without reserved space,
• embedded videos without placeholders,
• banners that load later,
• cookie banners,
• web fonts,
• dynamic content above the visible area.

How to Improve CLS #

Important measures:

• specify width and height for images,
• reserve space for ads and embeds,
• position cookie banners in a stable way,
• optimize font loading,
• do not insert late-loading content above existing content,
• use skeletons or placeholders.

Example:

<img src="/product.webp" width="800" height="600" alt="Product">

This lets the browser reserve space before the image has loaded.

The 75th Percentile: Why Averages Are Misleading #

Core Web Vitals are not evaluated by a simple average.

The recommended thresholds apply at the 75th percentile. This means that at least 75% of page views should reach the good value.

web.dev explains that tools for assessing Core Web Vitals should consider a page as passing when the recommended targets are reached at the 75th percentile of page views.
Source: web.dev: How Core Web Vitals thresholds were defined

Why this matters:

• A page can feel good for fast desktop users.
• Mobile users on weak connections can still have poor values.
• A few very slow users are not decisive on their own, but the majority must have a good experience.
• Mobile and desktop should be analyzed separately.

That is why “Poor Core Web Vitals” and “Slow pages with search traffic” rate the 75th percentile of field data. RankScan reads the values for mobile devices.

Field Data vs. Lab Data #

PageSpeed optimization has two data worlds.

Field Data #

Field data is based on real users.

Sources:

• Chrome UX Report,
• PageSpeed Insights,
• Google Search Console Core Web Vitals,
• Real User Monitoring,
• analytics with Web Vitals tracking.

Google Search Console describes the Core Web Vitals report as an evaluation of real usage data. The data comes from the Chrome UX Report. The report groups similar pages together.
Source: Google Search Console Help: Core Web Vitals report

Field data tells you:

Do real users have a problem?

Lab Data #

Lab data is generated in a simulated test environment.

Sources:

• Lighthouse,
• Chrome DevTools,
• WebPageTest,
• the lab section in PageSpeed Insights,
• local performance tests.

Lab data tells you:

Where could the technical problem be?

The Most Important Rule #

Field data shows whether a problem is relevant. Lab data helps identify the cause.

How to Measure PageSpeed Correctly #

A useful measurement workflow looks like this.

1. Check Google Search Console #

Start with the Core Web Vitals report.

Check:

• mobile and desktop separately,
• groups of similar pages with poor values,
• affected metric,
• number of affected URLs,
• page types,
• development over time.

2. Use PageSpeed Insights #

Test one typical page per page type, without parameters in the address.

Check:

• field data,
• lab data,
• LCP element,
• render-blocking resources,
• unused JavaScript,
• image sizes,
• server response timeTime to First Byte (TTFB) is the time until the browser receives the first byte of the server response, describing how quickly the server reacts.Open glossary entry →,
• layout shifts.

3. Use Lighthouse for Diagnosis #

Do not use Lighthouse as the only goal. Use it as a diagnostic tool.

A 100/100 score is not always economically sensible. It is more important to fix real user problems on important pages.

4. Use WebPageTest or DevTools for Details #

For technical teams, the following are helpful:

• waterfall analysis,
• Time to First Byte (TTFB), the time until the first byte of the server response,
• resource timing,
• main-thread work,
• third-party scripts,
• filmstrip,
• CPU throttling,
• network conditions.

5. Set Up Real User Monitoring #

For larger websites, RUM is worthwhile.

It helps you identify:

• real user devices,
• slow countries or regions,
• browser differences,
• page templates,
• outliers,
• conversion impact.

Prioritization: Which Slow Pages Matter? #

Not every slow URL needs to be optimized immediately.

The following table is a general professional assessment. RankScan shows one fixed severity per measure.

The most important rule:

Start optimization where many real users, important rankings or conversion goals are affected.

The Biggest PageSpeed Levers #

1. Optimize Images #

Images are often the biggest LCP lever.

Measures:

• use WebP or AVIF,
• size images correctly,
• use responsive images with srcset,
• compress images,
• prioritize the LCP image,
• lazy-load only below the fold,
• use meaningful placeholders,
• do not forget alt textAlt text is a text alternative for an image, stored in the alt attribute of the img element, describing the content or function of the image.Open glossary entry →.

Common mistake:

<img src="hero.jpg" loading="lazy">

when this image is the LCP element.

Better:

<img src="hero.webp" fetchpriority="high">

2. Improve Server Response #

TTFB is not directly a Core Web Vital, but it strongly affects LCP.

Measures:

• good hosting,
• page caching,
• object cache,
• OPcache,
• database optimization,
• CDN,
• Hypertext Transfer ProtocolHTTP (Hypertext Transfer Protocol) is the protocol through which browsers and servers exchange web content. HTTPS is the encrypted, secure variant of this protocol.Open glossary entry → (HTTP) version HTTP/2 or HTTP/3,
• compression,
• avoid unnecessary redirectsA redirect forwards users and search engines from one URL to another. It can be permanent (301) or temporary (302) and transfers signals to the target URL.Open glossary entry →,
• edge caching.

If the server responds slowly, no frontend optimization can fully rescue LCP.

3. Optimize CSS #

CSS can block rendering.

Measures:

• prioritize critical CSS,
• remove unused CSS,
• minify CSS,
• reduce large framework files,
• bundle CSS cleanly or split it selectively,
• avoid unnecessary nesting of fonts and CSS.

4. Reduce JavaScript #

Too much JavaScript is often the cause of poor INP and LCP.

Measures:

• remove scripts that are not needed,
• use code splitting,
• use defer or async,
• critically review third-party scripts,
• delay chat widgets,
• clean up tracking tags,
• reduce framework hydration,
• split long tasks.

For JavaScript-heavy pages, the article JavaScript SEO: Identify Rendering Problems is also relevant.

5. Optimize Fonts #

Web fonts can affect load time and CLS.

Measures:

• load only the required font weights,
• host fonts locally or deliver them efficiently,
• use font-display: swap or another suitable strategy,
• evaluate preload for central fonts,
• use variable fonts sensibly,
• choose fallback fonts with similar metrics.

6. Control Third-Party Scripts #

Many pages are slow not because of their own content, but because of third-party providers.

Typical scripts:

• tracking,
• tag managers,
• chat,
• heatmaps,
• A/B testing,
• cookie banners,
• ads,
• social widgets,
• review widgets.

Check:

• Is the script really needed?
• Does it have to load immediately?
• Can it load after consent or interaction?
• Are there leaner alternatives?
• Does it cause long tasks?
• Does it affect INP?

PageSpeed Optimization in WordPress and Content Management Systems (CMS) #

Many performance problems arise in the CMSA content management system (CMS) is software for creating, managing and publishing web content, usually without programming knowledge. Well-known examples are WordPress or Shopify.Open glossary entry → setup.

WordPress #

Common causes:

• too many plugins,
• heavy theme,
• page builders,
• unoptimized images,
• no caching,
• many external scripts,
• unoptimized database,
• unused CSS/JS files,
• poorly configured fonts.

Important measures:

• plugin audit,
• server-side caching,
• image optimization,
• database cleanup,
• remove unnecessary page-builder modules,
• check critical CSS,
• use a CDN,
• reduce theme weight.

Craft CMS, TYPO3, Laravel, Headless #

In custom setups, the levers are often different:

• template caching,
• query optimization,
• eager loading,
• asset transformations,
• CDN,
• Server-Side Rendering (SSR)With Server-Side Rendering (SSR), the server generates the finished HTML before delivering the page to the browser or crawler. Content is therefore present in the source immediately.Open glossary entry → and Static Site Generation (SSG),
• Application Programming Interface (API)An application programming interface (API) is an interface through which software systems communicate and exchange data. It defines how requests are made and answered.Open glossary entry → response times,
• frontend bundle size,
• image pipelines,
• edge caching.

Performance findings should therefore be grouped by template or page type whenever possible.

What to Do After a RankScan Finding #

Each of the three measures has its own steps in RankScan. They use the same tools: PageSpeed Insights for diagnosis, your developers or agency for implementation. RankScan starts the next run itself. You only mark the measure as done.

“Slow-loading pages” #

1. Pick three to four typical page types from the list, such as home page, offer and gallery.
2. Measure one page of each type without parameters in PageSpeed Insights. Note the biggest slowdowns. Pay special attention to server response time. It has the strongest effect on the value in the crawl.
3. Reduce the size of images and files that you upload yourself. They do not count in the crawl’s HTML fetch, but they slow down your visitors.
4. Pass the other slowdowns on to your developers or agency. They usually sit in the page template.
5. One fix in the template speeds up every page of that type.
6. Mark the measure as done once the pages load faster.

How RankScan checks it: the next full crawl checks all affected pages. RankScan then reports “Fixed” or “Not fixed yet” with the number of pages still missing.

“Poor Core Web Vitals” #

1. Open PageSpeed Insights and note which metric is in the red: LCP, CLS or INP. The measure in RankScan names the same metrics.
2. Note what each metric needs. LCP: compress the largest image, improve the server response time.
3. CLS: reserve space with fixed image sizes. INP: reduce heavy JavaScript.
4. Pass the list on to your developers or agency, then mark the measure as done.

How RankScan checks it: RankScan checks the measure with the next new CrUX data. Once no metric of the domain is in the red anymore, RankScan reports “Fixed”. Until then, the measure stays reported.

“Slow pages with search traffic” #

1. Sort the affected pages by search traffic.
2. Note the weak metrics of each page from PageSpeed Insights.
3. Pass the list on to your developers or agency, the page with the most traffic first. If several pages share a template, the fix in the template works for all of them.
4. Mark the measure as done once the pages load faster.

How RankScan checks it: RankScan checks the measure with the next new CrUX data per page. Once no page with search traffic has a metric in the red anymore, RankScan reports “Fixed”. Until then, the measure stays reported.

Why the CrUX Check Takes Time #

The Chrome UX Report is a 28-day rolling average. Google updates the data daily.
Source: Chrome for Developers: CrUX API

So an improvement only shows up partly from day to day. It becomes fully visible about four weeks after implementation. Until then, the measure stays reported in RankScan.

Diagnosis: How to Find the Cause #

The following steps go deeper into diagnosis. They fit all three measures.

Step 1: Determine the Page Types #

Check which pages are affected:

• a single page,
• all blog articles,
• all product pages,
• all categories,
• the homepage,
• landing pages,
• mobile or desktop.

Step 2: Check Field Data #

Use:

• Google Search Console,
• PageSpeed Insights,
• CrUX,
• Real User Monitoring.

Ask:

Is the problem visible for real users?
Which metric fails?
Mobile or desktop?
Which page type is affected?

Step 3: Run a Lab Diagnosis #

For representative URLs:

• Lighthouse,
• PageSpeed Insights,
• WebPageTest,
• Chrome DevTools.

Check:

• LCP element,
• TTFB,
• image size,
• CSS/JS blockers,
• main-thread time,
• third-party scripts,
• layout shifts.

Step 4: Prioritize the Cause by Metric #

Step 5: Implement Measures #

Start with the largest lever.

Not useful:

20 small optimizations without a measurement basis

Better:

one page type
one main metric
one clear technical bottleneck
one measurable measure

Step 6: Validate #

After implementation:

• test again with Lighthouse or PageSpeed Insights,
• start validation in Google Search Console (GSC),
• monitor RUM data,
• consider the 28-day window,
• do not evaluate rankings and conversions in isolation,
• mark the measure as done in RankScan.

Core Web Vitals field data does not react immediately. It takes about four weeks until improvements become stable in Search Console and CrUX.

What a Good PageSpeed Check Looks At #

This is a general checklist. RankScan does not measure all of it.

RankScan measures three things:

• the HTML fetch of every page in the crawl, threshold 3 seconds,
• LCP, INP and CLS of the whole domain from the Chrome UX Report, for mobile devices,
• LCP, INP and CLS of individual pages with at least 10 clicks from Google Search Console in 30 days.

For diagnosis, a good check also reviews:

• LCP,
• INP,
• CLS,
• TTFB,
• total page weight,
• image weight,
• unoptimized images,
• render-blocking CSS,
• unnecessary JavaScript,
• third-party scripts,
• font loading behavior,
• missing image dimensions,
• lazy loading on LCP elements,
• caching headers,
• compression,
• CDN usage,
• mobile vs. desktop,
• page types,
• organic traffic,
• conversion relevance,
• template patterns,
• connection with JavaScript SEO.

This turns individual measurements into a prioritizable Website Health workflow.

Example: Poor LCP Caused by the Hero Image #

Initial Situation #

A B2B blog has good content, but poor mobile Core Web Vitals. RankScan reports two measures:

“Poor Core Web Vitals”: LCP in the red
“Slow pages with search traffic”: several blog articles with clicks

Google Search Console also shows poor LCP for blog articles.

RankScan does not report “Slow-loading pages”. The server delivers the HTML quickly. The hero image does not count in the crawl’s HTML fetch. But it slows down visitors, and that is exactly what the CrUX values show.

Analysis #

PageSpeed Insights shows:

• the LCP element is the hero image,
• the image is 2.8 MB,
• the image is served as PNG,
• the image is larger than necessary,
• loading="lazy" is active on the hero image,
• a chat widget loads immediately.

Solution #

1. Convert the hero image to WebP/AVIF.
2. Deliver responsive image sizes.
3. Remove lazy loading for the LCP image.
4. Set fetchpriority="high".
5. Load the chat widget only after interaction.
6. Check page cache.
7. Measure again with PageSpeed Insights after deployment.
8. Mark both measures as done in RankScan.

Result #

The lab data shows the better LCP immediately. The CrUX values follow over the 28-day window. Once the LCP of the domain and of the blog articles is no longer in the red, RankScan reports both measures as “Fixed”. Whether rankings change depends on additional factors. What definitely improves is the user experience on the affected pages.

Common Mistakes in PageSpeed Optimization #

Mistake 1: Chasing Lighthouse 100/100 #

A perfect lab score is not the goal. Real user data and business-relevant pages matter more.

Mistake 2: Lazy-Loading the LCP Image #

The most important above-the-fold image should not be delayed.

Mistake 3: Testing Only Desktop #

Many problems appear on mobile because of weaker CPUs, slower connections and higher JavaScript costs.

Mistake 4: Ignoring Third-Party Scripts #

Chat, tracking, consent and A/B testing can strongly affect performance.

Mistake 5: Optimizing Page by Page Instead of the Template #

If a template is affected, the template must be optimized, not just one individual page.

Mistake 6: Selling PageSpeed as a Ranking Hack #

Fast pages help, but they do not replace search intent, content or technical indexability.

Mistake 7: Explaining AI Crawlers Too Generally With PageSpeed #

Fast, server-side available content is helpful for crawlers. But there is no general guarantee that AI crawlersAI crawlers are automated bots that fetch web pages for AI providers in order to find content, make it available for search functions, retrieve it for answers, or, depending on the provider, use it for model training.Open glossary entry → simply “ignore” slow pages. More important are accessibility, initial Hypertext Markup Language (HTML), status codes, robots.txt and rendering.

Checklist: Optimize PageSpeed and Core Web Vitals #

Use this checklist:

• Is field data available in Search Console or PageSpeed Insights?
• Is mobile or desktop affected?
• Which page type is affected?
• Which metric is poor: LCP, INP or CLS?
• What is the LCP element?
• Is the LCP image optimized and prioritized?
• Is there render-blocking CSS?
• Is there too much JavaScript?
• Are there long tasks?
• Are third-party scripts necessary?
• Are images correctly sized?
• Are width and height set?
• Are there layout shifts caused by ads, banners or fonts?
• Is caching active?
• Is compression active?
• Is the server fast enough?
• Are important pages validated again?
• Is the effect checked through field data?
• Have you marked the measure as done in RankScan?

In addition, AI crawlers and robots.txt, Lost ranking and 404 Errors help narrow down the cause cleanly and prioritize the next SEO measures.

Conclusion: PageSpeed Is a User and Quality Lever, Not a Perfection Game #

PageSpeed optimization is important, but it should be measurable and prioritized.

The three RankScan measures “Slow-loading pages”, “Poor Core Web Vitals” and “Slow pages with search traffic” show where load time or Core Web Vitals are a problem. What matters next is not a perfect score, but the right diagnosis:

1. check field data,
2. identify affected page types,
3. determine LCP, INP or CLS as the main problem,
4. analyze the technical cause in the lab,
5. fix the biggest lever first,
6. prioritize important pages and templates,
7. validate the effect through real user data.

This turns PageSpeed from an endless developer task into a controlled Website Health process for better user experience, more stable technical quality and better conditions for search visibilitySearch visibility describes how present and findable a website is in the organic search results. It is not the same as traffic, but reflects theoretical findability.Open glossary entry →.

Sources and Further Reading #

• Google Search Central: Understanding Core Web Vitals and Google Search results
• Google Search Central: Understanding page experience in Google Search results
• Google Search Console Help: Core Web Vitals report
• web.dev: Web Vitals
• web.dev: How Core Web Vitals thresholds were defined
• Chrome for Developers: CrUX API