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 the RankScan insight “Slow 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 →” comes in.

The insight means: RankScan has found signals that a website or URL group loads too slowly or fails important performance metrics. This is a Website Health topic with Medium priority — not because load time is unimportant, but because it should always be assessed in the context of content, 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 →, page type and business value.

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 how to measure load time, PageSpeed and 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 → correctly, which metrics matter and which measures have the greatest effect.

What Does “Slow Load Time” Mean? #

The RankScan insight “Slow Load Time” means that a page or URL group loads too slowly or shows performance problems that can affect user experience, crawlingCrawling 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 → or 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 →.

This can have several causes:

• 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 cachingCaching stores previously retrieved content so it is available faster on repeat requests, relieving both servers and the network.Open glossary entry →,
• 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: “Slow Load Time” should not stand as an isolated score. It should be connected to page type and 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 intent, 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.

For RankScan, this means it is important not just to report a lab number, but to consider real user experience and URL groups.

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 and is shown by URL groups.
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,
• poor URL groups,
• affected metric,
• number of affected URLs,
• page types,
• development over time.

2. Use PageSpeed Insights #

Test representative URLs for each URL group.

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 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 #

When RankScan reports “Slow Load Time”, proceed in a structured way.

Step 1: Determine the Affected URL Group #

Check whether it affects:

• a single URL,
• all blog articles,
• all product pages,
• all categories,
• the homepage,
• landing pages,
• mobile or desktop,
• specific countries or devices.

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 URL group 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 URL group
one main metric
one clear technical bottleneck
one measurable measure

Step 6: Validate #

After implementation:

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

Core Web Vitals field data does not react immediately. Depending on the data situation, it can take several weeks until improvements become stable in Search Console and CrUX.

What a Good PageSpeed Check Looks At #

A good PageSpeed check should do more than report a single load time.

A good check 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,
• URL groups,
• page types,
• organic traffic,
• conversion relevance,
• template patterns,
• connection with JavaScript SEO.

This turns “Slow Load Time” 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:

“Slow Load Time”

Google Search Console shows poor LCP for blog articles.

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 after deployment.

Result #

LCP improves significantly. 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: Not Working With URL Groups #

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

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 URL group 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?

In addition, AI Readiness Score, Improve Google Rankings 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 RankScan insight “Slow Load Time” shows where load time or Core Web Vitals are likely to be a problem. What matters next is not a perfect score, but the right diagnosis:

1. check field data,
2. identify affected URL groups,
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 visibility.

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