WordPress Failing Core Web Vitals Mobile: Causes and Fixes

Google rates a page as good on a metric when the 75th percentile of real visits meets that threshold. Mobile and desktop are scored separately, so the same pages can pass on one and fail on the other. Check the mobile report on its own.

In the HTTP Archive's 2025 Web Almanac(opens in a new tab) (July 2025 data), 48 percent of origins had good Core Web Vitals on mobile against 56 percent on desktop.

LCP was the metric most often failed on mobile: 62 percent of origins had a good LCP, against 77 percent for INP and 81 percent for CLS.

• Largest Contentful Paint (LCP): 2.5 seconds or less.
• Interaction to Next Paint (INP): 200 milliseconds or less.
• Cumulative Layout Shift (CLS): 0.1 or less.

The metric in your report points to the cause. Heavy or late images usually hurt Largest Contentful Paint (LCP). Plugin and page-builder JavaScript usually hurts Interaction to Next Paint (INP). Images, embeds, and web fonts without reserved space cause layout shift (CLS). Slow hosting raises the time to first byte, which delays every metric.

Plugins are the usual source of the extra JavaScript. Audit the installed list before you change theme code. A plugin you no longer use still loads its scripts until you remove it.

Google Tag Manager slows the Largest Contentful Paint (LCP) when its tags run before the page paints. The container itself is small. The problem is what it launches: every tag fires from a trigger, and many inject synchronous scripts. On a mid-range phone, the main thread spends its first seconds running those scripts instead of painting your page.

The fix is re-sequencing, not removing the container. Paint the page first, load the container after, and let each tag fire on the event it needs. Your analytics still collects the data. It just stops blocking the first render. To find which tags to defer, use the third-party script audit.

The hero image is usually the LCP element on a WordPress page. WordPress 6.3 and later(opens in a new tab) add high fetch priority to the image they judge most likely to be the LCP image, and never lazy-load that same image. Google's guidance on optimizing LCP(opens in a new tab) says never to lazy-load the LCP image.

So the failures now come from other places. Core keeps loading attributes a theme or page builder already set. It picks by a heuristic, the first large image in the page, so that image may not be your hero. An image under the size threshold, 50,000 pixels of width times height by default, is not eligible for high priority. Others serve the hero unsized, or send a desktop-size file to phones.

• Find the LCP element in DevTools, then read its loading and fetchpriority attributes in the page source.
• Remove any lazy-loading setting a theme or builder added to the hero.
• Set responsive sizes that match the rendered width, so phones do not download the desktop file.
• Give high fetch priority to one or two images at most, because setting it on more stops it helping.

Interaction to Next Paint (INP)(opens in a new tab) replaced First Input Delay as a Core Web Vitals metric in March 2024. It measures how quickly the page responds to input across a visit, so heavy builder-generated markup and theme scripts show up there too.

Deferring scripts helps, but a theme that loads everything up front limits what deferral can recover. Measure the INP on the pages your visitors use before deciding whether the theme needs a rewrite. If you want that measured for you, the Core Web Vitals optimization service starts with a field-data diagnostic.

Google's guide to optimizing INP(opens in a new tab) starts from field data, then splits a slow interaction into input delay, processing time and presentation delay. Each part has a different fix.

• Input delay: long tasks, often scripts still running from page load, hold the interaction back.
• Processing time: the click handler does too much work before the browser can paint.
• Presentation delay: a large DOM makes the next paint slow.

Start with the Core Web Vitals report in Search Console(opens in a new tab). It names the failing metric and the group of pages it affects. Then run the same pages through PageSpeed Insights(opens in a new tab) and read the field data section, which uses the same real-visitor data.

Test each template, not only the homepage. Search Console groups URLs with a similar experience, so a failing group usually points to one template, such as posts or product pages, even when the homepage passes.

For the cause, open Chrome DevTools, record a mobile page load in the Performance panel, and find the LCP marker. The element it points to is the one to fix. If that element is a script or a tag, the cause is the tag manager or the theme. If it is the hero image, the cause is image loading.

Fix one cause, then wait for the 28-day field window to fill before you judge the result. A lab score can improve on the same day that the field data stays red. For why the two numbers disagree, read PageSpeed score 90 but Search Console flags.

Layout shift happens when content moves after it first appears. The usual causes are images and embeds without width and height attributes, and web fonts that swap in and change the line lengths of text. Set explicit dimensions on images and embeds so the browser reserves their space before they load.

Font swapping is a smaller but common cause. Check whether the theme loads fonts from several places, and whether a late font change moves the page. Reserve the space first, then look at the fonts.

• Set width and height on every image and embed.
• Reserve space for embeds that load late.
• Load each font once, from one source, and check how the swap moves the text.

Time to First Byte (TTFB) measures how long the server takes to start responding. Google's guidance on TTFB(opens in a new tab) calls 0.8 seconds or less a rough target at the 75th percentile, and more than 1.8 seconds poor. It is not a Core Web Vital, but it comes before every loading metric.

If the response is slow, image and script fixes can only recover so much, because the page cannot start until the server answers. A cached page can hide the problem: the homepage may come from cache while a post or product page waits on the database.

• Measure TTFB on a page that is not cached.
• Compare it across templates, not only the homepage.
• Fix a slow response before you tune images and scripts.

A caching plugin speeds up the server response. These problems happen in the browser after that response arrives, so a plugin on its own rarely fixes them. Each extra speed plugin can also add scripts of its own. Test the page with the plugin switched off before you credit it with a fix.