WordPress Slow on Mobile: Fix Mobile Core Web Vitals, LCP, and INP (2026)

Key facts at a glance

WordPress mobile speed in 2026

Last updated June 30, 2026

What the mobile test simulates: A Moto G Power class mid-range phone on slow 4G, about 1.6 Mbps, with a four-times CPU slowdown. Your fast laptop is nothing like it, which is why desktop can look perfect while mobile fails.
The three metrics and targets: LCP under 2.5s for loading, INP under 200ms for responsiveness, CLS under 0.1 for stability, at the 75th percentile of real visits. Mobile is where these most often fail.
The most-missed mobile cause: The hero image discovered late. If it is lazy-loaded or a CSS background, the browser fetches it after everything else, so LCP is slow even when the file is small. Never lazy-load the LCP image.
What WordPress does for you: Since 5.9 it skips lazy-loading the first content image, and since 6.3 it adds fetchpriority="high" to the likely LCP image. Page builders and CSS-background heroes often defeat this.
Why taps feel laggy: INP, which replaced FID on March 12, 2024, fails when too much JavaScript keeps the throttled mobile CPU busy. Reduce and defer scripts so the main thread can answer taps.
Measure mobile field data: Google ranks on the mobile version and on the field data of real Chrome visitors over the trailing 28 days. A fix shows in the lab immediately and in the field over the following weeks.

Source: the web.dev documentation on Core Web Vitals thresholds, LCP, and INP, the Google Search Central pages on Core Web Vitals and mobile-first indexing, the WordPress core notes on image performance and lazy-loading, the Lighthouse throttling documentation, and our hands-on mobile work. Get a quote in 60 seconds →

Why mobile is its own problem

The reason a site can be fast on desktop and slow on mobile is concrete, and it helps to know exactly what Google tests. When PageSpeed Insights runs the mobile score, it does not use your machine. It emulates a mid-range phone, a Moto G Power class device, on a throttled slow-4G connection of around 1.6 megabits per second with roughly 150 milliseconds of latency, and it applies a four-times CPU slowdown on top to approximate a phone that is warm and busy rather than fresh. That is a deliberately humble device on a deliberately ordinary connection, because it represents the median visitor, not the engineer testing on a fast laptop on office wifi.

On that device, three things that your desktop hides all bite at once. The same JavaScript your plugins, page builder, and third-party tags ship takes several times longer to parse and run on the slower, throttled CPU. Every image, stylesheet, and script takes longer to arrive over the slower connection. And a hero image sized for a wide screen is a heavy download that the phone is asked to make first. A fast desktop powers through all of this and still feels quick, which is why the weight has nowhere to hide until you look at mobile.

This is not only about user experience, though a slow mobile site does lose visitors. Google indexes and ranks using the mobile version of your site under mobile-first indexing, and it scores Core Web Vitals from the real-world experience of Chrome users, reporting mobile and desktop separately. So the mobile result is the one that feeds ranking, and a site that quietly fails on mobile is being judged on that failure even if desktop looks perfect. The good news is that the fixes are specific and mostly mechanical, and the rest of this page works through them in the order that matters.

The three metrics Google scores

Google measures the mobile experience with three Core Web Vitals, each capturing a different way a page can feel slow. A page passes only when at least 75 percent of real visits are in the good range for all three.

Metric	Good	What it measures on mobile
LCP	≤ 2.5s	Loading. Time until the largest visible element, usually the hero image on mobile, finishes rendering.
INP	≤ 200ms	Responsiveness. How quickly taps and clicks get a visible response, near the worst across the visit. Replaced FID on March 12, 2024.
CLS	≤ 0.1	Stability. How much the layout shifts while loading, which is more disruptive on a small screen.

These are the good thresholds at the 75th percentile of real-user data per the web.dev documentation. For the cross-device breakdown of all three, see our Core Web Vitals fix. This page focuses on what makes them fail specifically on mobile, starting with the metric that fails most: LCP.

Where the mobile second goes

Optimize the image is only part of the story, and chasing it alone is why a lot of mobile LCP work stalls. The web.dev documentation breaks LCP into four consecutive parts, and on mobile the time can pile up in any of them. Knowing which part is slow tells you which fix actually moves the needle, instead of guessing.

Part of LCP	What it is	The mobile cause and fix
Time to First Byte	From the click until the first byte of HTML arrives.	A slow host or no page cache, felt more over a mobile connection. Fix with a page cache, a good host, and a CDN.
Resource load delay	From the first byte until the browser starts downloading the LCP image.	The mobile killer most people miss. A lazy-loaded hero, a CSS background image, or an image referenced from CSS or JavaScript is discovered late. Fix by keeping the LCP image in the HTML, not lazy-loading it, and preloading it.
Resource load duration	How long the LCP image itself takes to download.	A desktop-sized image over slow 4G. Fix with a responsive srcset and a modern format like WebP or AVIF so the phone pulls a small file.
Element render delay	From the image finishing download until it actually paints.	Render-blocking CSS and JavaScript still parsing on the slow CPU. Fix by inlining critical CSS and deferring non-essential JavaScript.

The part most people overlook is resource load delay, the gap before the browser even starts downloading the hero. On WordPress that gap is usually self-inflicted: the hero is lazy-loaded, or it is a CSS background the browser cannot see until the stylesheet parses, so the most important image is fetched last. Shrinking the image does nothing about that gap. The next section is about exactly this, because WordPress has built-in machinery to prevent it that page builders routinely defeat.

What WordPress does for mobile LCP, and how it breaks

Modern WordPress tries hard to get the hero image right, and on a plain theme it usually does. Understanding the three things it does, and the one assumption they all rely on, is the key to the most common mobile LCP problem.

Since WordPress 5.5: automatic lazy-loading

WordPress adds loading="lazy" to images and iframes that have width and height, so off-screen media does not load until needed. Good for everything below the fold, dangerous if it catches the hero.

Since WordPress 5.9: skip the first content image

To protect the largest paint, WordPress deliberately does not lazy-load the very first content image or iframe on the page, on the assumption that it is the most likely LCP element.

Since WordPress 6.3: automatic high priority

WordPress adds fetchpriority="high" to the first non-lazy image larger than 50,000 square pixels, telling the browser to fetch it before lower-priority resources. It will not override a fetchpriority or loading attribute you set yourself.

The single assumption under all three is that your largest image is a normal img tag that WordPress outputs as the first content image. When that holds, the hero is not lazy-loaded and gets the high priority hint, and mobile LCP is usually fine. The trouble is how often it does not hold on real sites.

How page builders and themes defeat it

CSS background heroes. A hero set with a CSS background-image is not an img tag at all, so WordPress cannot skip-lazy or prioritize it, and the browser only discovers it after parsing the CSS.
Sliders and builder markup. A slider or a builder may render the hero in a way WordPress does not count as the first content image, so a smaller image above it gets the priority and the real LCP image is left lazy-loaded.
Plugins that force lazy-load on everything. A lazy-load plugin that does not exclude the first image re-lazies the hero WordPress meant to skip.

In all three cases the result is the same: the most important image on the page is discovered and downloaded late, and mobile LCP suffers even if the file is small and the server is fast. The fix is to make sure the real LCP image is not lazy-loaded and does carry fetchpriority="high", and for a CSS-background hero, to preload it so the browser fetches it early.

Which symptom matches yours

Find the row that matches what you see on a phone. Each one points to a specific cause and fix.

Symptom	Most likely root cause
Fast on your laptop, clearly slow on phones	The mobile stack: a throttled CPU running the same JavaScript, a slow-4G connection, and desktop-sized images sent to phones. Send mobile less and lighter.
PageSpeed Insights mobile score is red while desktop is green	The test throttles a mid-range phone for the mobile score. It is real. Fix the mobile lab issues, but judge success by the mobile field data over the trailing 28 days.
The big image or headline takes seconds to appear on mobile	A failing mobile LCP. Often the hero is lazy-loaded or a CSS background, so it is discovered late, or it is an oversized file behind render-blocking JavaScript.
Your hero is a slider or a CSS background image	WordPress cannot prioritize a background image or some builder markup, so the LCP image loses its skip-lazy and high-priority treatment. Preload it, or render it as a real img.
Taps, menus, and buttons feel laggy on mobile after it loads	A failing mobile INP from too much main-thread JavaScript and third-party scripts on a slow CPU. Reduce and defer scripts so the main thread can respond.
Content jumps around as the mobile page loads	A high CLS from images and ads without reserved space, or fonts swapping in late. Set explicit dimensions and stabilize the layout.

The six mobile causes

Mobile slowness in WordPress is almost always a mix of these six, all amplified by the throttled device and connection.

1. The LCP image discovered late

The most common and most overlooked mobile cause, sitting in the resource load delay part of LCP. A lazy-loaded hero, a CSS background image, or an image referenced only from CSS or JavaScript is found by the browser late, so it starts downloading after everything else. The fix is to keep the LCP image as a real img in the HTML, never lazy-load it, give it fetchpriority="high", and preload it if it is a background image.

2. Oversized images served at desktop dimensions

The resource load duration problem. A wide, high-resolution hero sent to a phone at full size is a heavy download over slow 4G. The fix is responsive images, a smaller version sized for the phone through srcset, in a modern format like WebP or AVIF, which WordPress and most image plugins can generate.

3. Render-blocking CSS and JavaScript

The element render delay problem. Stylesheets and scripts in the document head block the first paint, so the page sits blank while they download and parse on the slow CPU, even after the image is ready. The fix is to inline the critical CSS for the first screen, defer the rest, and defer non-essential JavaScript so it does not stand between the visitor and the content.

4. Too much main-thread JavaScript and third-party scripts

The main cause of a failing mobile INP. Plugins, a heavy page builder, and third-party tags like analytics, chat widgets, and ad scripts all run JavaScript on the main thread, and the throttled mobile CPU cannot keep up, so taps feel laggy. The fix is to reduce the script footprint, defer what is not needed immediately, load scripts only on the pages that use them, and break up or replace the heaviest third-party tags.

5. Layout shift from unsized media and late fonts

A high mobile CLS comes from images, videos, and embeds without reserved space, ad slots that have no size until the ad loads, and web fonts that swap in late and reflow the text. On a small screen a shift is more disruptive. The fix is explicit width and height on media, reserved space for ads and embeds, and font loading that does not reflow the text when the real font arrives.

6. Heavy page builders and plugin bloat

The amplifier behind the others, and often the reason the LCP heuristics break too. A page built with a heavy builder ships a large amount of CSS and JavaScript, and twenty to thirty plugins each add their own assets, all of which the weak mobile CPU has to process. Often the biggest single win on mobile is trimming or replacing the heaviest builder or plugin. We audit the footprint on the speed optimization hub.

Field data vs your laptop

This is the distinction that decides whether you are measuring the right thing, and it trips up most people optimizing mobile. There are two kinds of speed data, and they answer different questions. Lab data is a single test run on the simulated phone under controlled conditions, like the score at the top of PageSpeed Insights or a Lighthouse run. It is repeatable and great for diagnosis. Field data is the real experience of your actual Chrome visitors, collected over the trailing 28 days, and it is what Google uses to assess Core Web Vitals for ranking.

The trap is judging mobile by the wrong one. Opening your site on your fast laptop and seeing it load instantly tells you nothing about mobile, because your laptop is not the throttled mid-range phone on slow 4G that the test, and many of your visitors, actually use. Even the mobile lab score is a simulation, useful but not the verdict. The verdict is the mobile field data in the Core Web Vitals assessment, which reflects what real phones experienced. So measure on mobile, fix the mobile lab issues to guide the work, and confirm success when the mobile field data moves into the good range.

What this means in practice

Because field data is a trailing 28-day average, a mobile fix does not flip the assessment overnight. The lab score improves immediately, which confirms the change worked, and the field data catches up over the following weeks as real visits accumulate at the new speed. Patience after the fix is normal, not a sign it did not work.

DIY vs hand it off

A clear single bottleneck, like one oversized hero image, is a reasonable self-fix. A lazy-loaded LCP image you cannot un-lazy, a failing INP, or several issues at once is where handing it off saves time. If the left column matches you can likely do this. If the right column matches, get help.

✓

Realistic on your own

✓The mobile issue is one oversized hero image you can resize and serve as WebP
✓Your hero is a normal img and you just need it not lazy-loaded
✓An image optimization plugin and a caching plugin get you most of the way
✓You can read PageSpeed Insights and find the LCP element
✓CLS is a single unsized image you can set dimensions on
✓You can re-test on mobile and confirm the lab score improved

✗

Hand it off, save the time

✗The hero is a CSS background or slider and the LCP image loads late
✗Mobile INP is failing and you cannot tell which scripts to defer
✗Deferring JavaScript breaks the layout or the menu
✗A heavy page builder is the bottleneck and needs careful trimming
✗Several metrics fail at once and you do not know where to start
✗It is a store and a slow mobile checkout is costing sales

How to diagnose it

Work in this order. The first step makes sure you are measuring mobile, not your laptop.

Measure on mobile, with field data

Run PageSpeed Insights on the page and read the Mobile tab, looking at the Core Web Vitals field assessment, not just the lab score. Search Console's Core Web Vitals report also splits mobile from desktop.

Identify the failing metric

Is it LCP (slow loading), INP (laggy taps), or CLS (jumping layout)? Name the one that is over threshold on mobile before touching anything, because each points at a different fix.

For LCP, find the element and how it loads

PageSpeed Insights names the LCP element. Check whether it is an img or a CSS background, whether it has loading="lazy", and whether it carries fetchpriority="high". A lazy or background hero is your cause.

For LCP, then check the file itself

If discovery is fine, look at size and format: is a desktop-sized JPEG being served to phones, and is there render-blocking CSS or JavaScript delaying the paint after it loads.

For INP, look at the JavaScript

A laggy mobile interaction means main-thread JavaScript. Look at the number of plugins, the page builder, and third-party scripts like chat, analytics, and ads that run on every page.

For CLS, find what shifts, and check the floor

Reload on a phone and watch what jumps: an unsized image, an ad slot, or text reflowing as a font swaps. Then confirm a page cache and CDN are in place, since TTFB is the floor under LCP.

How to fix it

Each branch targets one mobile problem. Fix the one your diagnosis pointed to first, then re-test on mobile.

Make the LCP image load early

This is usually the biggest mobile win. The hero must not be lazy-loaded and should carry the high priority hint so the browser fetches it first.

<!-- LCP image: NOT lazy, high priority, responsive -->
<img src="hero-800.webp"
     srcset="hero-480.webp 480w, hero-800.webp 800w, hero-1600.webp 1600w"
     sizes="(max-width: 600px) 480px, 800px"
     width="1600" height="900"
     fetchpriority="high" loading="eager" alt="...">

If the hero is a CSS background image the browser finds late, preload it so it starts downloading immediately.

<!-- In the head: preload a CSS-background hero -->
<link rel="preload" as="image" href="hero-800.webp" fetchpriority="high">

In WordPress this often means excluding the hero from a lazy-load plugin and rendering it as a real img so core can prioritize it.

Shrink and modernize the images

Serve a phone-sized file in a modern format so the download is small over slow 4G. An image optimization plugin generates the WebP or AVIF versions and the srcset.

Original:  hero.jpg     3500px   ~3 MB   sent to every device
Optimized: hero-480.webp 480px    ~40 KB  served to phones via srcset

Below the fold, keep WordPress lazy-loading on so off-screen images do not compete with the hero.

Fix mobile INP, the laggy taps

Reduce and defer JavaScript so the main thread is free to respond. Load non-critical scripts after the page is interactive, and only where they are used.

<!-- Defer non-critical scripts so they do not block interaction -->
<script src="non-critical.js" defer></script>

<!-- Better: load a heavy third-party widget on interaction,
     not on every page load -->

In WordPress, audit plugins and third-party tags, defer non-essential scripts, dequeue assets on pages that do not use them, and replace the heaviest chat, analytics, or ad scripts with lighter options.

Fix mobile CLS, the jumping layout

Reserve space for everything that loads in, so nothing pushes the content once it arrives.

<!-- Always set width and height so the browser reserves space -->
<img src="photo.webp" width="1200" height="800" alt="...">

/* Reserve a fixed height for an ad or embed slot */
.ad-slot { min-height: 250px; }

/* Load fonts without a late reflow */
@font-face { font-family: "Brand"; font-display: swap; }

Put a fast floor under it

Lower the server response and asset latency so the mobile device is not waiting before it starts. This is the Time to First Byte part of LCP, and it amplifies every other fix.

Page cache   -> serves finished HTML, lowering TTFB
CDN          -> delivers images, CSS, JS from near the visitor
Object cache -> speeds repeated database queries (e.g. Redis)

See the slow site fix for the full caching and hosting picture.

A lazy-loaded or background hero, failing INP, or several metrics down at once?

Let us fix your mobile speed in 2 hours →

A real mobile-speed session

A composite from the mobile performance work we do most weeks, with identifying details removed.

Scenario

A business site looked instant on the owner’s laptop, but Search Console flagged a poor mobile Core Web Vitals assessment and the bounce rate from phones was high. The mobile PageSpeed score was deep in the red while desktop was green, and the owner had already compressed their images, so they could not understand why mobile LCP was still over four seconds.

Diagnosis

Mobile LCP was failing, but not because of file size. The theme rendered the hero as a CSS background-image, so WordPress could not skip-lazy or prioritize it, and the browser only discovered it after parsing the stylesheet. The biggest cost was resource load delay, the gap before the image even began downloading, which compression does nothing about. A block of render-blocking JavaScript in the head added to the render delay on the throttled CPU.

Resolution

We preloaded the hero image with a high priority hint so the browser fetched it immediately, served it as responsive WebP through srcset so phones pulled a small version, and deferred the non-critical JavaScript while inlining the critical CSS. The LCP element now started downloading at the top of the load instead of near the end. The mobile lab score jumped immediately, and the mobile field assessment moved into the good range over the following weeks.

⏱

Total elapsed

The mobile optimization work fit inside the 2-hour window; the field data caught up over the following weeks.

When to stop and hand it off

Resizing one hero image is a good self-fix. Hand it off when the mobile problem is the harder kind. First, the LCP image is a CSS background or buried in builder markup and you cannot get it to load early. Second, mobile INP is failing and you cannot tell which scripts are holding the main thread or which are safe to defer. Third, deferring JavaScript or working critical CSS keeps breaking the layout or the menu. Fourth, several metrics fail at once and you do not know which to chase. We measure the mobile field and lab data, find which part of LCP is slow, and fix the failing metric the right way, image discovery, image size, script, layout, and caching, on your existing site without a rebuild, then verify the mobile result improves. Flat $49 to $149, done in two hours when scope fits, money back if we cannot improve your measured mobile speed.

Get a quote in 60 seconds

WordPress mobile speed FAQ

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

Because the test, and your real phone visitors, are running the page on a much weaker machine than your laptop. Google scores mobile by emulating a mid-range phone, a Moto G Power class device, on a throttled slow-4G connection of around 1.6 megabits per second, with a four-times CPU slowdown applied on top to mimic a hot, busy phone. Your laptop is none of those things. So three problems that your desktop hides all surface at once on mobile: the same plugin and page-builder JavaScript takes far longer to run on the slower CPU, every image and script takes longer to arrive over the slower connection, and a hero image sized for a wide screen is a heavy download on a phone. The fix is to send mobile less and lighter and to make it do less work, smaller responsive images, less render-blocking and main-thread JavaScript, and fewer third-party scripts.

WordPress already lazy-loads images and adds fetchpriority. Why is my mobile LCP still slow?

Because those built-in optimizations rely on WordPress correctly guessing which image is your largest one, and on many sites that guess is wrong. Since WordPress 5.5 every image with width and height gets loading="lazy" automatically, and since 5.9 WordPress deliberately skips lazy-loading the very first content image so it does not delay the largest paint. Since 6.3 WordPress also adds fetchpriority="high" to the first non-lazy image larger than 50,000 square pixels, the one it thinks is the LCP element. The catch is that this is a heuristic on standard in-content images. Page builders, sliders, and themes that render the hero as a CSS background image, or that output the hero in a way WordPress does not recognize as the first content image, defeat it: the real LCP image ends up lazy-loaded and without the priority hint, so the browser discovers and fetches it late and mobile LCP suffers. The fix is to make sure the actual LCP image is not lazy-loaded and does carry the high priority hint.

My hero is a background image set in CSS. Does that change anything?

Yes, and it is one of the most common hidden causes of slow mobile LCP in WordPress. A CSS background image is not an HTML img element, so it is invisible to WordPress core lazy-loading and fetchpriority logic, which only act on img and iframe tags. The browser also cannot see a background image until it has downloaded and parsed the CSS that references it, so it discovers the most important image on the page late, which on a slow mobile connection adds a long resource load delay before the image even starts downloading. If your theme or page builder uses a CSS background for the hero, the fix is to preload that image with a high priority hint so the browser fetches it early, or better, to render the hero as a real img element so WordPress and the browser can prioritize it normally.

Does mobile speed actually affect my Google ranking?

Yes, in two compounding ways. First, Google uses Core Web Vitals as part of its page experience signals, and it states that good Core Web Vitals align with what its core ranking systems reward. Second, Google primarily indexes and ranks using the mobile version of your site under mobile-first indexing, and it measures Core Web Vitals from the real-world experience of Chrome users, with mobile and desktop reported separately. Put together, the mobile experience is the one that counts for ranking, and a site that passes on desktop but fails on mobile is being judged on the mobile result. On top of the ranking effect, mobile is usually the majority of traffic, so a slow mobile site loses conversions directly. Fixing mobile speed protects both the ranking and the revenue.

My PageSpeed Insights mobile score is red but desktop is green. What does that mean?

It means the test is putting your site on a throttled mid-range phone for the mobile score and on fast hardware for the desktop score, and your site only struggles under the harder mobile conditions, which is exactly what your phone visitors experience. One important distinction on that report is lab data versus field data. The score at the top is a single lab test run on the simulated phone, useful for diagnosis. The Core Web Vitals assessment, when it appears, is field data, the real experience of your actual Chrome visitors over the trailing 28 days, and that is what Google uses for ranking. So fix the mobile lab issues to guide the work, but judge success by the mobile field data moving into the good range, which happens on a rolling basis over the weeks after the fix.

Why do taps and menus feel laggy on my mobile site even after it loads?

That is a responsiveness problem, measured by Interaction to Next Paint, and on mobile it comes down to too much JavaScript on a slower processor. INP, which replaced First Input Delay as a Core Web Vital on March 12, 2024, measures how quickly the page responds to taps and clicks throughout the visit and reports close to the worst one. When a tap feels laggy, the main thread is busy running JavaScript, from plugins, a heavy page builder, and third-party scripts like chat widgets, analytics, and ad tags, so the browser cannot respond until that work finishes. A desktop CPU powers through it; the throttled mobile CPU does not. The fix is to reduce and defer JavaScript, load scripts only on the pages that need them, and break up or replace the heaviest third-party tags, so the main thread stays free to respond to taps quickly.

Content jumps around while my mobile page loads. How do I stop it?

That is Cumulative Layout Shift, the visual-stability metric, and it is often worse on mobile where there is less screen room to absorb a shift. It happens when an element loads without its space reserved, so everything below it jumps when it arrives. The usual culprits are images and embeds without width and height attributes, ad slots that have no reserved space until the ad loads, and web fonts that swap in late and reflow the text. The fixes are direct: set explicit width and height on images and video so the browser reserves the space before they load, reserve a fixed size for ad and embed slots, and load fonts so the fallback occupies a similar space to the final font to avoid a reflow. On mobile this stops the frustrating moment where a button moves just as a visitor goes to tap it.

I installed a caching plugin but mobile is still slow. Why?

Caching helps the server respond faster, but it does not shrink the page, and on mobile the page weight and the JavaScript are usually the real bottlenecks. A page cache stores the finished HTML so the server can hand it over quickly, which lowers Time to First Byte and genuinely helps, since that is the first of the four parts of LCP. But once that HTML arrives, the phone still has to download the same oversized images, parse the same render-blocking CSS, and run the same heavy JavaScript, none of which caching touches. So a cached site with a four-megabyte hero image and a dozen third-party scripts is still slow on mobile. Caching is the floor, worth having, but the mobile gains come from the asset-level work: smaller responsive images, the LCP image discovered early and not lazy-loaded, deferred and reduced JavaScript, and a stable layout. We set up caching and a CDN and then do the asset work that caching cannot.

Can you make my WordPress site fast on mobile without rebuilding it?

In most cases yes, because mobile speed is usually fixed by optimizing what is already there, not by starting over. We measure the mobile field data and lab data to find the actual bottleneck, then work the levers that matter on mobile: serve responsive modern-format images and make sure the LCP image is discovered early, not lazy-loaded, and carries the high priority hint, defer and reduce JavaScript and tame third-party scripts to fix INP, inline critical CSS and remove render-blocking resources, stabilize the layout to fix CLS, and put a proper cache and CDN under it all. That is configuration and optimization on your existing theme and plugins, not a rebuild. Occasionally a single extremely heavy plugin or page builder is the bottleneck and the honest answer is to replace that one piece, which we will tell you before doing. Flat $49 to $149, done in two hours when scope fits, money back if we cannot improve your measured mobile speed.

Sources and further reading

Every technical claim on this page traces back to the web.dev Core Web Vitals documentation, Google Search Central, the WordPress core development notes, or the Lighthouse documentation.