How to Fix Slow Website Loading on WordPress With Core Web Vitals

You can fix slow website loading on WordPress in an afternoon if you measure before you change anything. Google judges a page on three Core Web Vitals, and each one has its own cause and its own fix.

We tested every fix in this guide on a WordPress 7.1 test site in October 2026, with WooCommerce active. The numbers come from Lighthouse mobile lab runs and Chrome event timing on that site. Treat them as examples and not as promises for your own pages.

Next you will see what counts as slow, how to measure it for free, and five tested fixes. Older advice still lists First Input Delay among the Core Web Vitals, and that is no longer true.

What Counts as Slow Website Loading in 2026?

Slow website loading means a page fails one of three Core Web Vitals. According to web.dev, Largest Contentful Paint should land within 2.5 seconds. Interaction to Next Paint should be 200 milliseconds or less, and Cumulative Layout Shift should be 0.1 or less.

Google measures all three at the 75th percentile of page loads.

Metric	What it measures	Good	Poor
Largest Contentful Paint (LCP)	How fast the main content appears	2.5 seconds or less	Over 4.0 seconds
Interaction to Next Paint (INP)	How fast the page reacts to clicks and taps	200 ms or less	Over 500 ms
Cumulative Layout Shift (CLS)	How much the layout jumps while loading	0.1 or less	Over 0.25

Mobile and desktop are measured separately. A website loading slow on phones can still pass on desktop. Google’s Core Web Vitals page recommends good scores for success in Search. It does not promise a ranking for them.

Note: First Input Delay (FID) is retired. web.dev says INP became stable in 2024 and replaced FID. If a speed guide still tells you to fix FID, it was written before that change.

How to Measure Slow Website Loading on WordPress

Measure in two layers before you fix anything. Field data shows what real visitors experienced, and lab data shows one controlled test you can repeat. Check the field data in PageSpeed Insights and Search Console, run Lighthouse on one failing page, change one thing, and test again.

Step 1: Check Field Data in PageSpeed Insights

PageSpeed Insights shows real-user LCP, INP, and CLS for a URL, plus a lab test under it. Google’s PageSpeed Insights documentation says the real-user data comes from the Chrome User Experience Report over the previous 28-day collection period.

Enter your slowest page first and then your homepage. If a page has too few visits, PageSpeed Insights falls back to origin-level data for the whole site. That hides page-specific problems.

Step 2: Open the Core Web Vitals Report in Search Console

Search Console groups your indexed URLs by status and metric to show which parts of the site fail. Google’s Core Web Vitals report help page says a URL group takes the status of its most poorly performing metric. A group with poor CLS but good INP counts as poor.

Open the report for mobile first and then for desktop. Pages without enough data are left out. A short list does not mean a fast site.

Step 3: Run a Lab Test on One Failing Page

A lab test loads the page once in a controlled setup, which lets you find a cause. Run Lighthouse in Chrome DevTools or use the lab section of PageSpeed Insights, and test the same URL every time.

On our test page, Lighthouse reported an LCP of 4.8 seconds, a CLS of 0 and a Total Blocking Time of 0 ms. That told us loading was the weak spot. We started there.

Tip: web.dev advises checking whether Lighthouse agrees with your real-user data. If the two disagree, the web.dev LCP guide says the field data likely gives the more accurate picture.

How to Fix a Slow Largest Contentful Paint on WordPress

Find the biggest element above the fold and make it arrive sooner. According to web.dev, that element can be an image, a video, a background image, or a block of text. A separate web.dev guide splits LCP into four parts.

Those parts are time to first byte, resource load delay, resource load duration, and element render delay, as web.dev names them. The guide suggests a rough budget of 40 percent, under 10 percent, 40 percent, and under 10 percent in that order. It calls these guidelines and not strict rules.

WordPress already writes a srcset list for images from your Media Library. The browser can then choose a small file on a small screen. The trouble starts when a theme or plugin prints the original upload instead. On our test page, one 3.0 MB original photo made LCP jump from 5.0 seconds to 20.4 seconds on a simulated mobile connection.

In theme code, call wp_get_attachment_image() and let WordPress build the tag. We tested this call and it returned width, height, srcset, and sizes attributes without any extra work:

echo wp_get_attachment_image( $attachment_id, 'large' );

If that image is the main one above the fold, ask for high priority and skip lazy loading. We confirmed both attributes appear in the output:

echo wp_get_attachment_image(
	$attachment_id,
	'large',
	false,
	array(
		'fetchpriority' => 'high',
		'loading'       => 'eager',
	)
);

web.dev says to never lazy-load your LCP image because that adds resource load delay.

WordPress 6.3 and later already handles this. The WordPress 6.3 image performance note says core adds fetchpriority="high" to the likely LCP image. It also skips lazy loading for the first three images that qualify.

On our WordPress 7.1.3 test page, the hero image came out with fetchpriority="high" and no loading attribute. We then forced lazy loading on it, and LCP stayed at about 5.0 seconds in both cases. So do not expect a big win from this setting, but do not break the default either.

A slow first byte limits every later step. The web.dev LCP guide says a high time to first byte can make a 2.5 second LCP hard or even impossible. Our guide to reducing TTFB in WordPress covers caching and hosting fixes. Start there if your server response is the slowest part.

How to Stop Plugins From Loading CSS and JavaScript on Every Page

Some plugins load their CSS and JavaScript on every page, and WooCommerce did on our test site. You can remove those files with wp_dequeue_style() and wp_dequeue_script() on pages that do not need them. On our test site that cut requests from 31 to 21 and LCP from 4.8 to 3.6 seconds.

On a fresh install with WooCommerce, our plain sample page loaded 7 stylesheets and 11 scripts, including jQuery. Lighthouse flagged unused CSS and JavaScript on our lab page.

This snippet removes WooCommerce’s classic store assets from pages that are not store pages. Add it to a small plugin and not to a theme you plan to replace:

add_action( 'wp_enqueue_scripts', function () {
	if ( ! function_exists( 'is_woocommerce' ) ) {
		return;
	}
	if ( is_woocommerce() || is_cart() || is_checkout() || is_account_page() ) {
		return;
	}
	foreach ( array( 'woocommerce-layout', 'woocommerce-smallscreen', 'woocommerce-general', 'woocommerce-blocktheme' ) as $handle ) {
		wp_dequeue_style( $handle );
	}
	foreach ( array( 'wc-add-to-cart', 'wc-jquery-blockui', 'wc-js-cookie', 'woocommerce' ) as $handle ) {
		wp_dequeue_script( $handle );
	}
}, 100 );

Here is what we measured on the sample page, using the median of three Lighthouse mobile runs:

• Requests: 31 before and 21 after.
• Transfer size: About 700 KB before and about 440 KB after.
• LCP: 4.8 seconds before and 3.6 seconds after.
• Performance score: 71 before and 83 after.

Warning: Handles change between plugin versions, and some pages need scripts you did not expect. We left the order attribution scripts in place, because they record where store visitors came from.

After the change, we confirmed the page showed no console errors, the header cart still opened, and the shop and cart pages kept their files. Test your own cart, checkout, and any product pages before you ship it. Our guide on checking for plugin conflicts on WordPress shows a safe way to test.

How to Fix a Slow Interaction to Next Paint on WordPress

Fix INP by shortening the work that runs when someone clicks, taps or types. web.dev says an INP of 200 milliseconds or less is good and over 500 is poor. A click handler that runs a long task delays the next paint. Check filter, slider and tracking scripts first.

First, remove scripts you do not use. Then load the rest so they do not block the page. WordPress 6.3 added a loading strategy for scripts, and it takes one extra argument:

add_action( 'wp_enqueue_scripts', function () {
	wp_enqueue_script(
		'my-widget',
		get_theme_file_uri( 'assets/widget.js' ),
		array(),
		'1.0',
		array(
			'in_footer' => true,
			'strategy'  => 'defer',
		)
	);
} );

On our test site the deferred script printed with the defer attribute. A script registered the old way stayed in the head with no attribute. The same note warns that a script with inline “after” code is treated as blocking. Check the output.

If your own handler is slow, paint a result first and do the heavy part afterward. This pattern gives the browser a chance to update the screen:

button.addEventListener( 'click', async () => {
	results.textContent = '12 results';
	await new Promise( ( resolve ) => setTimeout( resolve, 0 ) );
	runHeavyFilter();
} );

We tested it with a click handler that does 300 ms of work. The interaction took 304 ms when the work ran first, and 24 ms when the page updated first. That is a lab test with a stand-in for slow work.

Note: Yielding moves the work. It does not remove it. The heavy function still runs and can delay the next click. The lasting fix is to run less code.

How to Fix Layout Shifts on WordPress

Fix CLS by reserving space for anything that appears after the first paint. The web.dev CLS guide defines a layout shift score as impact fraction times distance fraction. CLS is the largest burst of shifts, and a burst can last up to five seconds.

Images without dimensions are the classic cause. WordPress adds width and height to images from your Media Library, but hard-coded theme images and some plugin output may not have them.

We removed those attributes from our test image and used Chrome’s slow-network throttling. CLS went from 0.001 to 0.065.

Late banners cause the same problem. We injected a 64 pixel promo bar at the top of the page 800 ms after load.

CLS rose to 0.078, which is 78 percent of the 0.1 budget from one bar. Giving the bar a reserved slot brought it back to 0:

<div id="promo-slot" style="min-height:64px"></div>

Put the bar inside that slot, and keep the slot the same height as the bar. This also applies to cookie notices, sign-up bars, and ad areas.

To find the culprit on your own site, open the Lighthouse report for the page and look at the “Avoid large layout shifts” audit. It lists the elements behind each shift. Fix the top one and test again. Fonts that swap late can shift text too. Check the text blocks as well as the images.

Tip: The same guide says layout shifts within 500 ms of a click or tap do not count. A menu that opens after a click is fine. A bar that appears on its own is not.

When the Server Is the Problem

If time to first byte is high, front-end fixes cannot reach a good LCP. Slow hosting, no page cache, and heavy plugins can each raise it. Check the Time to First Byte shown in PageSpeed Insights before you spend a day on images.

Compare it with the first paint, too. The web.dev LCP guide says a large gap between those two can mean the browser must download many render-blocking files. That points to plugin and theme files instead of the server.

Our guides on WordPress image optimization and speeding up a WooCommerce website go deeper on those parts. For a wider list of causes, read why WordPress is so slow.

If you would rather hand this off, our WordPress speed optimization services cover testing and fixing all three metrics.

How to Check That a Fix Worked

Run the same lab test on the same URL after each change. Compare medians from three runs, because Lighthouse results vary a little from run to run. Change one thing at a time so you can tell which change helped.

If you want to know how to improve website loading speed for good, keep a small log of page, metric, before, and after.

Test the pages that matter most, such as the homepage, a post, and a cart or checkout page. Clear the page cache first, because a cold request can look slower than the real thing. Here are the changes we measured in this guide:

Field data lags behind. PageSpeed Insights reports the previous 28 days, and Search Console help says the report reflects the last 28 days of user data. Expect the status to change weeks after a real fix.

Conclusion

You can fix slow website loading on WordPress by working through the three metrics in order. Measure with field data, find the failing metric with a lab test, and change one thing at a time.

Our tests showed that the biggest wins were the plain ones: a correctly sized image, fewer plugin files, and reserved space for late content. Forget First Input Delay and aim for LCP of 2.5 seconds, INP of 200 ms, and CLS of 0.1.

Frequently Asked Questions (FAQs)