Site Speed Optimization: How to Diagnose, Fix and Keep Your Website Fast

Site speed optimization is the work of reducing how long a website takes to load, respond and stay visually stable, so visitors can use your pages without friction. A slow website loses people before they read a word, and it can hold back how well your pages meet Google’s page experience signals. This guide shows how to find where your site is actually slow, which fixes to make first, and how to prove they worked.

It is built as a workflow: measure with real-user data, diagnose the bottleneck, fix it in a sensible order, verify, then guard against regressions. WordPress gets its own section, but the principles apply to any CMS.

One limit up front. Google says Core Web Vitals are used by its ranking systems and recommends good scores, but it also says that good results in Search Console or third-party tools do not guarantee top rankings. Treat speed as one part of page experience, not as a ranking switch.

How to read this guide

Each recommendation carries one of three labels.

Confirmed: supported by official documentation from Google Search Central, web.dev, WordPress core or MDN. Sources are listed at the end.
Recommended: a widely used practice and SEORAF’s editorial recommendation. It is not a documented ranking rule.
Depends: right for some sites and wrong for others. Test it on your own pages before making it permanent.

This guide does not report client results or SEORAF test results. Numbers come from cited public sources, and code snippets are illustrations with placeholder file names. Your results will depend on your website, hosting, audience, devices and implementation.

Quick start: the first hour

Site Speed Optimization Technical SEO Site Speed Optimization

Test an important URL in PageSpeed Insights on mobile. Read the real-user section before focusing on the lab score.
Open the Core Web Vitals report in Search Console and note which metrics and page groups need attention.
If Time to First Byte (TTFB) is high, investigate redirects, caching, hosting and CDN delivery before concentrating on browser-side optimizations.
If LCP fails, identify the LCP element. Check whether the browser can discover it early, whether it is being lazy-loaded incorrectly, and whether its loading priority is appropriate.
If CLS fails, check image dimensions and reserve space for embeds, ads and banners that load later.
If INP fails, investigate long JavaScript tasks, expensive event handlers and third-party scripts.
Change one thing at a time where practical, retest under comparable conditions, and allow field data to reflect changes before judging the long-term result.

What site speed optimization means

Site speed optimization is the process of improving how quickly a browser receives, renders and responds to your pages. It can involve server response, resource size, network distance, caching and the efficiency of HTML, CSS and JavaScript. It is one part of the wider discipline covered in our technical SEO guide.

Page speed usually refers to the performance of an individual page, while site speed is often used more broadly to describe performance across a website. In practice, investigate problems by URL and page template rather than relying on one site-wide number. Google’s documentation explains how page experience and Core Web Vitals are considered in Search; strong performance does not replace relevance, content quality or other ranking considerations. [Confirmed]

Four layers help explain where performance problems can originate. Identifying the affected layer makes it easier to choose an appropriate fix.

Layer	What it covers	Typical levers
Network	Latency and bandwidth between the visitor and server	CDN, fewer redirects, HTTP/2 and HTTP/3 where supported
Server	How quickly HTML is generated and sent	Hosting, page caching, database and backend efficiency
Frontend	How the browser parses and runs HTML, CSS and JavaScript	Render-blocking resources, long tasks, DOM size
Content weight	The amount of data a page requests	Image size and format, fonts, scripts and third-party tags

The four layers of web performance and common optimization options for each.

Why speed matters

For visitors and business. Faster pages can reduce friction, but performance statistics need context. A widely cited Akamai and SOASTA study, summarized by Retail TouchPoints, reported that a 100-millisecond delay could hurt retail conversion rates by as much as 7%. The study dates from 2017 and covered retail sites. A breakdown reported by WARC described different effects for desktop and smartphone users. Treat this as historical, context-specific evidence, not a forecast for your website. [Confirmed as published research; Depends for your site]

For search. Google’s documentation says Core Web Vitals are used by its ranking systems and recommends good page experience. However, good scores do not guarantee top positions, and page experience is only one part of search performance. Relevant, useful content remains important. [Confirmed]

For crawling. Google’s crawl budget guide is primarily relevant to very large or frequently updated sites and sites with specific indexing or crawling problems. Google explains that faster page loading and rendering can help its systems process content, but most small and medium websites do not need to treat crawl budget as their main reason for improving speed. The size figures in Google’s guide are rough guidance, not universal eligibility rules. [Confirmed]

For mobile. The 2025 Web Almanac reported that 48% of mobile sites passed all three Core Web Vitals, compared with 56% on desktop. Its results provide a broad view of the web, not a prediction of your site’s performance. Use your own mobile field data to decide what to fix. [Confirmed as published data]

Measure first: field data versus lab data

Many ineffective speed projects start by measuring the wrong thing or treating one test run as the complete picture.

Field data comes from real visitors using supported data sources. Chrome’s Chrome User Experience Report (CrUX) powers the field-data section of PageSpeed Insights and contributes to the Core Web Vitals report in Search Console. CrUX uses a rolling 28-day collection window and reports Core Web Vitals at the 75th percentile, meaning the threshold represents the experience at or below which 75% of the observed experiences fall. Availability can vary by URL, origin, device and data volume. [Confirmed]

Lab data comes from a controlled or simulated page load, such as a Lighthouse test. It is useful for repeatable debugging, but a lab run does not represent every device, network, visitor or interaction on your site. [Confirmed]

When the two disagree, use field data to understand real-user outcomes and lab tools to investigate possible causes. See web.dev’s guide to why lab and field data can differ. In PageSpeed Insights, check whether the report shows URL-level or origin-level data. If a URL has insufficient field data, the tool may show origin-level data instead, which can hide problems limited to a particular template. [Confirmed]

The tools

Tool	Data type	Use it for
PageSpeed Insights	Field data when available, plus lab data	First check of an important URL on mobile and desktop
Search Console, Core Web Vitals report	Field	Finding page groups and metrics that need attention
Chrome DevTools and Lighthouse	Lab	Debugging, waterfalls, long tasks and layout shifts
WebPageTest	Lab	Waterfalls and tests from different locations and devices
GTmetrix	Lab	Waterfall and resource-level analysis
web-vitals JavaScript library or a real-user monitoring (RUM) service	Field	Collecting your own real-user data and, with suitable instrumentation, attributing problems to elements or interactions

Measurement tools by data type. Use field tools to judge real-user outcomes and lab tools to investigate potential causes.

What the Lighthouse score is, and is not

The Lighthouse performance score is a weighted combination of lab metrics. Lighthouse 10 introduced a scoring model that includes LCP, CLS, Total Blocking Time, First Contentful Paint and Speed Index. Metric definitions and weights can change between versions, so consult the documentation for the version you use. INP is not directly measured by a standard page-load Lighthouse run because that run does not automatically represent the full range of real user interactions. Total Blocking Time can help diagnose responsiveness problems in the lab, but it is not a substitute for field INP. Use the score to identify opportunities, not as a ranking target. [Confirmed]

Core Web Vitals: current thresholds

Metric	Measures	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	Loading: when the largest visible content element renders	2.5 seconds or less	Over 2.5 to 4.0 seconds	Over 4.0 seconds
Interaction to Next Paint (INP)	Responsiveness across clicks, taps and key presses	200 milliseconds or less	Over 200 to 500 milliseconds	Over 500 milliseconds
Cumulative Layout Shift (CLS)	Visual stability	0.1 or less	Over 0.1 to 0.25	Over 0.25

Core Web Vitals thresholds, assessed at the 75th percentile of eligible real-user visits. See web.dev’s explanation of the thresholds.

Core Web Vitals field assessments use the 75th percentile, and the same metric thresholds apply to mobile and desktop. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID measured the delay of the first qualifying interaction, while INP evaluates interaction responsiveness throughout a visit. Hovering, scrolling and zooming are not counted as INP interactions. [Confirmed]

Time to First Byte (TTFB) and First Contentful Paint (FCP) are useful diagnostic metrics, but they are not Core Web Vitals. Time to Interactive is not a current Core Web Vital or a component of the current Lighthouse performance score. [Confirmed]

Diagnose before you fix

What you see	Possible bottleneck	Where to investigate
TTFB consistently above about 0.8 seconds at the 75th percentile	Server processing, redirects, cache misses or distance from visitors	Server, hosting and CDN; Caching
Poor LCP with relatively low TTFB	LCP resource discovered late or assigned low priority, or rendering blocked	Fix LCP
Poor LCP and a large LCP image	Long resource download, inappropriate image dimensions or format	Images
Poor INP	Long JavaScript tasks, expensive event handlers, third-party tags or a large DOM	Fix INP
Poor CLS	Unsized images, embeds, ads, late banners, fonts or layout changes	Fix CLS
Passes on desktop but fails on mobile	CPU constraints, JavaScript work, image sizes or network conditions	Mobile testing
Lab looks fine but field data is poor	Real devices and networks, post-load shifts, or interactions not reproduced in the lab	Measure first

Symptom-to-cause guide. These are diagnostic clues, not proof of a cause; investigate before changing the site.

What to fix first, and why

This is SEORAF’s recommended sequence, informed by web.dev’s guidance on effective ways to improve Core Web Vitals. Adapt it to your own field data and technical findings. [Recommended]

Start with a metric that field data shows is failing. Investigate the page groups and templates affected rather than optimizing a metric that already performs well.
Investigate TTFB if it is high. TTFB comes before the rest of the page response, and a high value can make a good LCP difficult to achieve. It is a diagnostic signal, not a Core Web Vital threshold. [Confirmed]
Check LCP discovery and priority. A critical image that is discovered late may spend more time waiting to start downloading than it spends downloading. Inspect the LCP subparts before choosing a fix. [Confirmed]
Reserve layout space to reduce CLS. Setting dimensions and reserving space for late content are often straightforward, low-risk improvements.
Optimize image dimensions, formats and compression. These changes can reduce resource size and loading time when image delivery is a bottleneck.
Investigate JavaScript and third-party scripts. They can contribute to poor INP, but delaying or removing scripts can break features. Test key user flows.
Finish with lower-priority housekeeping. Minification, database cleanup and plugin pruning may help, but measure their effect instead of assuming they will produce major gains.

Fix Largest Contentful Paint (LCP)

First identify the LCP element. PageSpeed Insights may show it in diagnostics, and Chrome DevTools can help you inspect it. On many pages it is an image, but it can also be a text block or another large visible content element.

Web.dev describes four parts that help explain LCP: TTFB, resource load delay, resource load duration and element render delay. A useful diagnostic pattern is to look for excessive time in any one part. Example percentages sometimes used to illustrate a well-optimized image-based page—roughly 40% TTFB, under 10% load delay, roughly 40% load duration and under 10% render delay—are not universal targets. Actual proportions depend on the page and how its LCP element is delivered. See Optimize LCP. [Confirmed]

Optimizing one part can expose another bottleneck. For example, compressing an image can reduce its download time, but if the element remains hidden until JavaScript runs, render delay may still keep LCP slow. Check all relevant parts rather than assuming that a smaller image will solve every LCP problem. [Confirmed]

1. Make the LCP resource discoverable and appropriately prioritized

The browser can often discover an image earlier when its URL appears in the initial HTML. Problems can arise when an image is inserted by JavaScript, its real URL is hidden in an attribute such as data-src, or it is delivered as a CSS background image. Inspect the page source and network waterfall before deciding how to change it. [Confirmed]

<!-- Illustration only: use when this image is the LCP element
     and the priority hint is appropriate for the page -->
<img src="hero.webp" width="1200" height="630" fetchpriority="high" alt="Describe the image">

If a critical LCP image must be loaded as a CSS background, a preload may help the browser discover it earlier. Use this only after confirming that discovery delay is a problem; an unnecessary preload can compete with other important resources.

<!-- Illustration only: use the actual critical image URL -->
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

Preload and fetchpriority do different jobs. Preload tells the browser to discover and fetch a resource early; fetchpriority provides a hint about the resource’s relative priority. Neither should be applied indiscriminately. Use fetchpriority="high" only when the LCP resource has not already been given appropriate priority and the hint is justified. Marking many images as high priority can cause them to compete with one another. Check current browser support and test the result. [Confirmed]

Avoid lazy-loading the LCP image. Lazy loading can delay its discovery or request until the browser determines that it is needed. However, do not blindly add a priority attribute to every hero image: first inspect the rendered HTML, browser priority and network waterfall. [Confirmed]

2. Reduce render delay

Reduce render-blocking CSS by removing unused rules and deferring non-critical styles where appropriate. Inline critical CSS only when the trade-off makes sense; large inline styles cannot be cached separately.
Avoid unnecessary synchronous scripts in the document head. Use appropriate loading strategies after checking script dependencies.
Avoid hiding the LCP element behind client-side rendering, consent logic or an A/B testing script when the content can be rendered earlier without breaking required behavior.
Investigate long JavaScript tasks and main-thread work that delay rendering.

[Confirmed] The correct fix depends on the actual render-blocking resource or main-thread bottleneck identified during testing.

3. Reduce resource load duration

Serve appropriately sized images in a suitable format, use compression, improve delivery and set sensible cache headers. A CDN may help when network distance or origin load is a problem. Hosting critical resources on the same origin can sometimes avoid an additional connection, but the best approach depends on the existing setup. Check the LCP subparts before assuming download duration is the main bottleneck. See web.dev’s common misconceptions about optimizing LCP. [Confirmed]

4. Reduce TTFB

See Server, hosting, CDN and TTFB below. For a metric-by-metric walkthrough with WordPress examples, see our guide on how to fix Core Web Vitals issues.

Fix Interaction to Next Paint (INP)

INP evaluates the responsiveness of qualifying interactions throughout a visit. It focuses on the interaction with the worst latency, with an outlier adjustment for very high interaction counts. Each interaction can involve input delay, event-handler processing and presentation delay. Long tasks on the main thread can contribute to delays in these stages. [Confirmed]

Find the slow interaction. Start with field data, ideally from real-user monitoring that can attribute INP to a specific element or interaction. Then reproduce the interaction in a lab by following real user flows. Test while the page is still loading, when the main thread may be busy. A page may not have a usable INP value when there are not enough qualifying interactions in the available field data. [Confirmed]

Then apply the techniques recommended by web.dev in its guides to improving Core Web Vitals and optimizing INP:

Break up long tasks and yield when appropriate. A task longer than 50 milliseconds is considered a long task. Splitting expensive work can give the browser opportunities to respond to input between tasks. The scheduler.yield() API can help where supported, but check current browser support and provide an appropriate fallback before relying on it.
Ship less JavaScript. Use the Coverage tool in Chrome DevTools to investigate unused code, split code that is not needed at startup, and review whether every tag manager script is necessary.
Avoid unnecessarily expensive rendering updates. Investigate large DOM trees, repeated layout calculations and avoidable updates. CSS containment can help in suitable cases, but test visual and interaction behavior before using it.

[Confirmed] The most useful fix depends on which interaction and code path are responsible for the delay.

Heavy page builders and third-party widgets can add scripts, DOM nodes and main-thread work. Whether they are a meaningful bottleneck on your site is [Depends]: measure first and test changes on staging.

Fix Cumulative Layout Shift (CLS)

Layout shifts often happen when content arrives after the initial layout has been drawn. Web.dev identifies common causes such as images without dimensions, ads and embeds without reserved space, dynamically injected content and web fonts. See Optimize CLS. [Confirmed]

Images. Set width and height attributes or use CSS aspect-ratio where appropriate. These dimensions help the browser reserve space before the image loads. With srcset, use candidate images with compatible aspect ratios unless the layout intentionally changes between candidates.

<!-- Illustration: replace the dimensions and alt text with your own -->
<img src="photo.webp" width="800" height="450" alt="Describe the image">

Ads, embeds and banners. Reserve space using an appropriate min-height, width and height, or aspect-ratio. If the final size varies, choose a layout that minimizes unexpected movement. Avoid leaving an unpredictable zero-height area that expands after the rest of the page has rendered. Where practical, place late-loading content where it will not push important content unexpectedly.

/* Illustration only: replace with dimensions suited to your layout */
.ad-slot {
  min-height: 250px;
}

Fonts. Font loading can change text dimensions and cause layout shifts. font-display: swap can make text appear sooner, but it does not guarantee zero shift when the web font replaces the fallback. Depending on the design, options include choosing an appropriate font-display value, matching fallback font metrics with size-adjust and related descriptors, and preloading a critical font when evidence shows it is needed.

Animations. Animating layout properties such as top, left and margin can trigger layout recalculation and unexpected movement. Prefer animations using transform where appropriate, while checking the actual visual behavior.

Back/forward cache (bfcache). The browser’s back/forward cache can restore a page quickly when the page is eligible. Some response headers and JavaScript behaviors can affect eligibility, so check the browser’s current bfcache guidance and diagnostics before changing cache headers or event listeners. Do not remove security or privacy protections merely to pursue a performance gain.

Lab versus field. A standard lab load may not capture every layout shift that occurs later in a visit. Field CLS can include shifts after initial loading, such as content moving as visitors scroll. Shifts associated with qualifying recent user input are treated differently under the CLS definition. Use field diagnostics when lab CLS looks good but visitors still experience layout movement.

These techniques are documented in web.dev’s CLS guidance; the right implementation depends on the page layout. [Confirmed]

Server, hosting, CDN and TTFB

What TTFB is. Time to First Byte measures the time from the start of a navigation or request until the first byte of the response arrives. Depending on the measurement, it can include redirects, DNS lookup, connection and TLS setup, and server processing. Web.dev’s rough guidance classifies 0.8 seconds or less at the 75th percentile as good and over 1.8 seconds as poor. TTFB is not a Core Web Vital, and the thresholds are diagnostic guidance rather than a Google ranking requirement. Results vary with measurement method, network, location and caching. [Confirmed]

Common causes of high TTFB discussed in web.dev’s Optimize TTFB guide include redirect chains, visitors far from the origin server, slow server processing and caching behavior that sends requests to the origin unnecessarily. Query-string parameters can affect caching depending on how the cache is configured; do not remove tracking parameters without checking analytics and cache rules. [Confirmed]

What to do:

Remove unnecessary redirect hops after confirming the intended canonical URL and redirect behavior.
Cache HTML and serve it from a CDN where the content and platform allow it. The 2024 Web Almanac discusses CDN use across the web; the published figures are a snapshot, not a requirement for every website.
Check whether tracking parameters or cache rules cause requests that could be cached safely to bypass the cache. Preserve analytics functionality and personalized content.
Check where your real visitors are located and test TTFB from relevant regions with a tool such as WebPageTest.

Hosting. [Depends] Shared, VPS, managed and cloud hosting can all vary in quality. Rather than choosing by label alone, compare your own pages under similar conditions. Where possible, compare cached and uncached responses from relevant locations before paying for an upgrade.

HTTP/2 and HTTP/3. [Recommended] These protocols support multiplexing and can improve resource delivery under suitable conditions. They are often configured by the host or CDN. Confirm the protocol in the browser’s Network panel rather than assuming it is enabled. With modern protocols, combining every CSS or JavaScript file into one large file is not automatically beneficial; measure the effect on your site.

Database. [Depends] Slow queries and inefficient backend operations can raise TTFB on dynamic sites. Page caching may bypass much of this work for anonymous visitors. Measure first, back up before cleanup, and compare the results because gains vary between sites.

Caching: browser, page and CDN

Layer	What it stores	Notes
Browser cache	Static files on the visitor’s device	Controlled in part by HTTP caching headers
CDN or edge cache	Static files and, if configured, eligible HTML near the visitor	Can reduce distance to the origin and origin load
Page cache	Generated HTML pages on the server or cache layer	Can skip PHP and database work for eligible requests
Object cache	Results of repeated database queries	Can help dynamic requests that repeatedly need the same data

Caching layers and the work each one can reduce.

Browser caching. A common best practice is to give static files versioned or fingerprinted URLs, such as a filename containing a content hash, and cache them for a long time when appropriate. When the file changes, the URL changes too. See web.dev’s HTTP cache guide. The immutable directive can tell browsers that a fresh resource does not need revalidation; see MDN’s Cache-Control documentation. [Confirmed]

# Illustration only: use for a fingerprinted static file
# such as style.4f2a1c.css, after configuring your server
Cache-Control: public, max-age=31536000, immutable

For files whose URLs do not change when the contents change, use an appropriate shorter lifetime or revalidation strategy. Long caching without reliable versioning can leave visitors with stale files. [Confirmed]

Page caching on dynamic sites. [Recommended] Excluding cart, checkout, account and other personalized pages from shared page caching is standard practice on many shops and membership sites. Follow the platform and host’s instructions, purge cache when needed, and test as a logged-out visitor as well as with relevant logged-in flows.

Avoid overlapping cache layers without a plan. [Recommended] If your host already provides server-level caching, read its documentation before adding another caching plugin. Multiple layers can work together, but they need compatible settings and a clear purge strategy.

Testing pitfall. Compare cold-cache and warm-cache loads separately when diagnosing performance. A first visit and a repeat visit can behave differently, so record which condition you tested. [Recommended]

Note that Cache-Control: no-store can affect back/forward cache eligibility. Do not remove it solely for speed; first consider the security and privacy reasons the directive may be present. [Confirmed]

Images

Images are often the LCP element, but check the LCP subparts before assuming file size is the main bottleneck.

Serve the right size. Avoid sending a very large image to a device that displays it at a much smaller size. Use srcset and sizes where appropriate so the browser can choose a suitable candidate, and set dimensions to help prevent layout shifts. [Recommended]

Choose a modern format. Google’s WebP documentation reports that lossy WebP images can be substantially smaller than comparable JPEGs at similar quality, while lossless WebP can be smaller than PNG in many cases. AVIF may compress some images further, but the result depends on the source image, encoder, settings and quality target. Compare visual quality and actual file sizes rather than assuming a fixed percentage saving. [Confirmed for WebP documentation; Depends for AVIF results]

<!-- Illustration: modern formats with a fallback.
     Use actual file paths and suitable dimensions. -->
<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" width="800" height="450" alt="Describe the image">
</picture>

Compress deliberately. Lossy compression is often suitable for photographs; inspect the result at the size visitors will see. Lossless compression can be preferable for graphics with sharp edges or text where artifacts would be noticeable. [Recommended]

Lazy-load below-the-fold images. The loading="lazy" attribute can defer off-screen image loading. Do not lazy-load the LCP image or another image that is immediately needed for the initial viewport. For carousel images, use lazy loading or other loading controls only when appropriate to the carousel’s behavior and browser support. fetchpriority="low" is a priority hint; it does not itself defer an image or guarantee that the browser will wait to download it. Avoid delaying the first visible slide. [Confirmed]

CSS and JavaScript

How the browser builds a page. The browser parses HTML into the DOM and CSS into the CSSOM, combines information to determine rendering, calculates layout and paints pixels. Stylesheets can block rendering, while ordinary synchronous scripts can block HTML parsing. Reducing unnecessary blocking work can help the browser display content sooner. [Confirmed]

CSS. Use DevTools Coverage to investigate unused rules, remove unnecessary CSS, defer non-critical styles where appropriate, and minify and compress what remains. Inline only small amounts of critical CSS when the trade-off is justified. If a stylesheet blocks rendering of the LCP element, its loading time may contribute to LCP. [Confirmed]

JavaScript loading. A classic script without async or defer generally blocks HTML parsing while it is fetched and executed. A classic script with defer downloads in parallel and executes after HTML parsing, preserving document order among deferred classic scripts. A classic script with async executes when available, without a guaranteed execution order relative to other async scripts. Module scripts have their own loading behavior, so check the relevant documentation before applying these rules to every script type. [Confirmed]

<!-- Illustrations only: confirm script dependencies before use -->
<script src="app.js" defer></script>
<script src="independent-widget.js" async></script>

Minification and compression. Minification removes unnecessary characters from source files. HTTP compression, such as Brotli or Gzip, reduces the size of supported text responses in transit. Configure compression at the server or CDN where appropriate. Minification can help, but its impact is often smaller than fixing a major resource or execution bottleneck. [Recommended]

Delay-until-interaction features in optimization plugins. [Depends] These features can reduce early JavaScript work, but they can also delay expected behavior, break forms or menus, and shift work to the first interaction, potentially worsening INP. Test the main user journeys after enabling them.

Third-party scripts

Analytics, ads, chat widgets, heatmaps and social embeds can execute code or request resources that your site does not directly control. Audit these integrations periodically, remove tags that are no longer needed, load them only where required, and reserve space for embeds. To understand their impact, record a DevTools Performance trace with and without a tag where practical, or compare field data before and after a carefully controlled change. Do not remove required measurement, consent or security functionality merely to improve a lab score. [Recommended]

WordPress-specific improvements

These techniques apply to many WordPress sites. For plugin-focused guidance, see the website speed optimization plugin guide, and for metric-specific troubleshooting, see the Core Web Vitals fix guide.

Know what WordPress core already does. Since WordPress 6.3, core can add fetchpriority="high" to the image it considers the most likely LCP image and avoids combining that hint with loading="lazy" on the same image. Core’s image-loading behavior has changed across releases and may be affected by themes, plugins or custom code. Check the rendered page source and network priority before adding your own attributes. The core team’s benchmark results were measured under specific test conditions and are not a guarantee of the same improvement on your site. See the WordPress 6.3 image performance announcement. [Confirmed]
Audit plugins by measurement. [Recommended] Plugins can add scripts, styles, database queries or network requests. On a staging copy, deactivate likely candidates one at a time and compare results. Remove duplicate plugins only after checking what each one does.
Understand your page-caching setup. [Recommended] Check whether the host provides server-level or edge caching before installing another plugin. Follow the provider’s instructions and avoid overlapping configurations that conflict.
Exclude dynamic pages from shared page caching. [Depends] Cart, checkout, account and other personalized pages on WooCommerce or membership sites generally need appropriate cache exclusions. Follow the platform’s current guidance and test logged-in and logged-out behavior.
Check image output. [Recommended] If a plugin or CDN converts images to WebP or AVIF, confirm in DevTools that the expected format is served, the fallback works where needed, and image dimensions are set.
Watch theme and builder weight. [Depends] Large DOM trees and unnecessary scripts can affect rendering and interaction responsiveness. Compare real templates and field data before deciding to replace a theme or builder.
Fonts. [Depends] Hosting fonts on your own domain may avoid an extra connection, but it does not guarantee faster rendering. Choose a suitable font-display strategy and check the CLS section for layout-shift considerations.
Database cleanup. [Depends] Removing unneeded revisions, expired transients or obsolete data may be useful housekeeping. Back up first and measure TTFB before and after; cleanup does not automatically make every page faster.
PHP version. [Depends] Use a version supported by WordPress, your theme and your plugins. Check compatibility and test on staging before upgrading.
Work on staging first. [Recommended] Make one change, test the main user flows—such as navigation, search, forms and checkout—and deploy only after confirming that the site still works as expected.

Mobile performance testing

Person waiting for a web page to load on a smartphone — Mobile visitors may face slower processors and networks, so include mobile field data and realistic device testing in your workflow.

Core Web Vitals thresholds are the same on mobile and desktop, but the 2025 Web Almanac reported lower pass rates on mobile than on desktop. That broad dataset is a useful reminder to test mobile performance, not evidence that every site will have the same gap. [Confirmed as published data]

In PageSpeed Insights, read the mobile results first if mobile performance is important to your audience, and check whether the report uses URL-level or origin-level field data.
In Chrome DevTools, use device emulation and CPU or network throttling as approximations. They do not fully reproduce the behavior of a physical device.
When possible, test on a real mid-range phone and follow common user flows: open a menu, use search, submit a form or add an item to a cart. Test interactions during loading as well as after the page settles.
Compare available mobile field data in Search Console and PageSpeed Insights.
Do not rely only on a fast desktop computer and office Wi-Fi. They may hide problems visitors experience on slower devices or networks.

Before-and-after measurement methodology

Use a consistent process to document what changed and avoid attributing improvements to the wrong cause. [Recommended]

Scope. Pick three to five representative URLs covering your main templates: home page, article, category or product page, and a page known to have performance problems.
Baseline. Record available field values for LCP, INP and CLS at the 75th percentile, the date, whether data is URL-level or origin-level, TTFB and lab results from several comparable Lighthouse mobile runs. Note the tool version, device settings, throttling and test location.
One change at a time. Record what changed and when. If several changes must be bundled, list them together so you do not imply that a single change caused the entire result.
Retest under comparable conditions. Lab results vary between runs. Use several runs and compare a consistent summary, such as the median, instead of relying on one result.
Verify in field data. CrUX uses a rolling 28-day window. Allow up to about four weeks for the window to reflect a change, but timing and data availability vary. A RUM implementation using the web-vitals library can provide a faster signal from your own visitors, provided enough data is collected.
Judge the actual outcome. Check whether the relevant field metric improved or moved into the Good range. A higher Lighthouse score alone is not proof that real-user Core Web Vitals improved.
Record context. Note other changes that might affect the comparison, such as traffic mix, seasonality, new ads, new tags or redesigns.
Be careful with attribution. Do not claim that traffic, conversions or revenue changed because of speed unless the evidence supports that conclusion and other plausible causes have been considered.

Use this table to record each optimization, compare lab measurements under similar test conditions, and track field data when available. Leave unavailable values blank rather than estimating them.

Date	URL	Change made	Lab before / after	Field before / after	Notes
Add test date	Add tested URL	Describe the change	Record comparable values	Record available values and dates	Record conditions and other changes

Template for logging each change. The row contains prompts, not real performance data.

Regression testing and maintenance

Performance can regress as a site changes. New plugins, tags, ad units, hero images and design updates can add work or alter page behavior. Pair these checks with a broader review such as our advanced SEO audit checklist.

Retest after trigger events: theme, plugin or WordPress updates, new third-party tags, hosting or CDN changes, redesigns, and new ad or embed placements.
Review routinely: check the Core Web Vitals report in Search Console and PageSpeed Insights field data on a schedule you can maintain, such as monthly. There is no single official review cadence for every site. [Recommended]
Consider field monitoring: the web-vitals library or a RUM service can flag changes in your own traffic without waiting for the full CrUX window. Results depend on implementation and data volume.
Guard CLS and user flows: where appropriate, use Lighthouse user flows and timespan testing to investigate layout shifts and interaction behavior during common journeys. [Recommended]
Set a performance budget. [Depends] Examples include a maximum size for a hero image or limits for third-party scripts. Budgets are most useful when your development or publishing workflow can enforce them.
Check bfcache eligibility after changes to caching headers or scripts, using browser diagnostics and current documentation.
Keep a change log so that a regression can be connected to a relevant deployment or configuration change.

Common speed optimization mistakes

Lazy-loading the LCP image. This can delay discovery or loading of the main visible content.
Hiding the LCP image behind JavaScript or data-src attributes when that prevents the browser from discovering it early.
Compressing an image without checking the other LCP parts. The image may not be the main bottleneck.
Chasing a 100 Lighthouse score instead of investigating field Core Web Vitals and the experience of real visitors.
Testing only on desktop, on a warm cache or on a fast connection. These conditions may hide other users’ problems.
Stacking caching or optimization plugins without checking compatibility. Overlapping configurations can conflict or make diagnosis harder.
Delaying or removing scripts without testing. Forms, menus, checkout, consent and analytics may stop working or behave differently.
Assuming font-display: swap eliminates layout shifts. It does not guarantee that the fallback and final font have matching dimensions.
Animating layout properties such as top, left or margin without checking the resulting layout behavior.
Using long cache lifetimes on unversioned files. Visitors may receive stale assets after a deployment.
Promising ranking or revenue gains from speed work. Neither outcome is guaranteed by a performance change.

Prioritized checklist

Do first

Read field data in PageSpeed Insights and Search Console; list failing metrics and affected page groups.
Check TTFB using comparable tests and relevant visitor regions.
Identify the LCP element on important page templates.
Check whether the LCP resource is discoverable early, is not lazy-loaded, and has an appropriate loading priority. Do not force fetchpriority="high" on every image.
Set image dimensions and reserve space for embeds, ads and other content that loads later.

Do next

Remove unnecessary redirect chains and investigate cache-bypassing parameters.
Configure page caching and a CDN where they suit the site; exclude personalized pages as needed.
Serve appropriately sized, compressed images in suitable formats, with fallbacks where needed.
Investigate render-blocking CSS, unnecessary JavaScript and long main-thread tasks.
Audit third-party tags and remove those that are genuinely unused.

Then maintain

Log changes and retest under comparable conditions.
Allow time for the rolling field-data window to reflect changes; do not assume it updates on an exact schedule.
Review Core Web Vitals regularly and after significant updates.
Check bfcache eligibility when relevant, without compromising security or privacy.

Frequently asked questions

What is site speed optimization?

Site speed optimization is the process of improving how quickly pages load, respond to interactions and remain visually stable. It can involve server response, resource size, caching, delivery, rendering and code execution.

Does site speed affect SEO?

Google says Core Web Vitals are used by its ranking systems and recommends good page experience. However, good scores do not guarantee top rankings, and speed does not replace relevant, helpful content or other search considerations.

What are the current Core Web Vitals thresholds?

Good thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Field assessments use the 75th percentile of eligible real-user visits.

What is a good PageSpeed Insights score?

There is no official Lighthouse score that guarantees rankings. Use the lab score to identify diagnostic opportunities, and use available field Core Web Vitals data to understand real-user performance.

What is a good TTFB?

Web.dev’s rough guidance classifies TTFB of 0.8 seconds or less at the 75th percentile as good. TTFB is not a Core Web Vital, so interpret it alongside your site’s rendering behavior, cache status, network and audience location.

Why is my site fast on desktop but slow on mobile?

Mobile devices may have less processing power and slower network connections. Heavy JavaScript, large images and third-party scripts can therefore become more noticeable. Check mobile field data and test on a real device when possible.

How long until improvements appear in Search Console?

CrUX uses a rolling 28-day window. Allow up to about four weeks for the window to reflect a change, but timing and data availability vary. Your own properly implemented real-user monitoring may show an earlier signal.

Do I need a CDN?

It depends on where your visitors are, how your origin performs and which resources can be cached. Compare response times from relevant audience regions and investigate your existing caching setup before deciding.

Do I need a speed plugin on WordPress?

It depends on your hosting and existing configuration. If server-level caching already exists, another caching plugin may be unnecessary or may conflict unless configured correctly. Check your host’s documentation first, then see our website speed optimization plugin guide.

Will fixing speed improve my rankings?

Improving Core Web Vitals can help your pages meet Google’s page experience recommendations, but no one can guarantee a ranking change. Measure the performance outcome directly and assess search performance separately.

Sources and further reading

The following official documentation and published research support the technical explanations and recommendations in this guide. Check the source pages for updates before relying on version-specific details.