
How to Fix Redirect Chains and Loops for Better SEO
Find every chain and loop on your site, cut each path to a single hop and keep it that way.
Read articleFind the slow part of your Largest Contentful Paint and apply the fix that actually moves it below 2.5 seconds.

This guide gives you nine practical fixes to reduce LCP WordPress sites struggle with, ordered by the part of the load they speed up, plus a method to find which fix your page actually needs. Most slow LCP pages have one or two clear bottlenecks, not ten small ones.
To reduce LCP WordPress pages need a fast server response, an LCP image that is in the initial HTML and not lazy loaded, fetchpriority=”high” on that image, compressed modern image formats, and less render blocking CSS and JavaScript. A good LCP is 2.5 seconds or less at the 75th percentile of real visits.

A good LCP is 2.5 seconds or less for at least 75% of page visits, and anything above 4 seconds is poor. Largest Contentful Paint measures when the biggest image or text block in the viewport finishes rendering, which is usually the hero image, a featured image or the main heading.
web.dev’s guide to optimizing LCP splits the metric into four parts that add up to the total: time to first byte, resource load delay, resource load duration and element render delay. As a rough guide, about 40% each should go to server response and downloading the resource, and less than 10% each to the two delay phases. Knowing which part is too big tells you which fix to apply.
| LCP part | Rough target share | If it is too big, look at |
|---|---|---|
| Time to first byte | About 40% | Hosting, page caching, CDN, redirects |
| Resource load delay | Under 10% | Lazy loaded hero, image set in CSS or JS, no priority hint |
| Resource load duration | About 40% | Image size and format, CDN for images |
| Element render delay | Under 10% | Render blocking CSS and scripts, sliders, font loading |
The nine fixes below cover every LCP part, and on most WordPress sites the first four solve the problem. Measure before and after each one so you know what worked.
LCP is usually higher on mobile because phones have slower processors and networks, and because many WordPress themes send the same large hero image and the same scripts to every device. The field data in Search Console and PageSpeed Insights is split by device, so a page can pass on desktop and fail on mobile.
Common mobile only causes I see in audits:
Test with mobile emulation and network throttling in Chrome DevTools, and look at which element PageSpeed Insights names as the LCP element. On mobile it is often a different element than on desktop. Fix the mobile LCP element first, because Google’s mobile first indexing means the mobile version of your page is the one that counts most, and most visitors on many sites arrive on phones.
Yes, lazy loading hurts LCP when it is applied to the LCP image itself, because the browser waits until layout is done before it even starts downloading that image. Lazy loading images further down the page is still a good idea.
web.dev documented this in its study on the performance effects of too much lazy loading. In HTTP Archive data, the median 75th percentile LCP was 2,922 ms for pages without lazy loading and 3,546 ms for pages with it. In an A/B test on WordPress archive pages, turning lazy loading off for above the fold images improved LCP by 13% on desktop and 15% on mobile. WordPress has since changed core to skip lazy loading for images it expects in the first viewport, but themes and plugins that add their own lazy loading can still undo that.
The quick check: view the page source, find the LCP image and make sure it has no loading=”lazy” and no data-src swap from a lazy load plugin. Most performance plugins have an option to exclude the first one or two images.
Take a WordPress service page with a mobile LCP of 4.2 seconds in a throttled lab test. The breakdown shows time to first byte at 1.3 s, resource load delay at 1.4 s, load duration at 1.1 s and render delay at 0.4 s. The large load delay is the clue: the hero is a CSS background set by the page builder and the lazy load plugin also tags it. Moving the hero into an img element with fetchpriority=”high” and excluding it from lazy loading cuts load delay to about 0.2 s. Converting the 480 KB JPEG to a 110 KB WebP with srcset cuts load duration to about 0.5 s. Turning on page caching brings time to first byte to about 0.6 s. The new total is roughly 0.6 + 0.2 + 0.5 + 0.4 = 1.7 seconds, comfortably under 2.5 seconds.
Keep LCP in your monthly checks using my free SEO audit checklist, and check how your titles look while you are at it with the SERP snippet preview tool. If you want the work done for you, my technical SEO service handles Core Web Vitals fixes, and my WordPress website design builds start with a fast, simple hero by default. Faster pages help users and conversions, but no speed fix on its own guarantees rankings.
It is the largest image or text block visible in the viewport when the page loads. On most WordPress sites it is the hero image, the featured image or the main heading. PageSpeed Insights names the exact element for each device.
Yes. Since WordPress 6.3, core adds fetchpriority=high to the image it judges most likely to be the LCP element. Page builders, sliders and CSS background heroes can bypass this, so always check the final HTML of your key templates.
Not always. A CDN mainly reduces download time and, if it caches HTML, time to first byte. If your hero image is lazy loaded or set in CSS, the delay comes from late discovery, and a CDN will not fix that.
Both are modern formats that are usually much smaller than JPEG or PNG at similar quality. Either is a good choice. Serving the right size for each screen with srcset often saves as much as the format change.
They can, mainly by adding extra CSS and JavaScript, using CSS background images for heroes, and wrapping content in many nested elements. A well configured builder page can still pass, but it takes more care than a lean theme.
Field data uses a rolling 28 day window, so changes appear gradually over about four weeks. PageSpeed Insights lab results show the effect immediately, which helps you confirm a fix works before the field data catches up.
Facts checked against these official pages. Read how I check facts in my editorial policy.

Find every chain and loop on your site, cut each path to a single hop and keep it that way.
Read article
Find every insecure image, script and stylesheet on your HTTPS pages and replace it for good.
Read article
Fix return tag, code and canonical problems so Google shows the right language version to each visitor.
Read articleSend your website and I will reply with a free audit.