Your Blog Cover Is Probably Your LCP

You can see it for yourself in about ten seconds. Open any of your posts in PageSpeed Insights, find the diagnostics, and read the element it labels as the Largest Contentful Paint. On a blog post, it is almost always the cover. Your featured image is not just the thing readers see first - it is the thing the browser works hardest to paint, and the thing Google puts a stopwatch on. That makes the cover a performance decision, not only a design one.

LCP is one of the three Core Web Vitals, and it is the one your cover owns. The good news is that the fix is small and mostly lives where you already work - in the file you export.

Why the cover owns your LCP

Largest Contentful Paint measures how long the biggest piece of content in the viewport takes to render, and on most pages that piece is an image. On a blog post it is the cover: top of the page, wider than anything else on the screen. So the clock LCP keeps is, in practice, the clock on your cover. A good LCP is 2.5 seconds or less, Core Web Vitals are a Google ranking signal, and featured images already pull weight in search - so a heavy, late cover is not just slow, it is a quiet tax on every post.

Here is the part that should sting: plenty of sites slow their cover down on purpose without meaning to. Roughly one page in six lazy-loads its LCP image - the single image it most needs to rush, told to wait. The fix is not exotic. It splits cleanly into two halves: the half that lives in the image file, which Lede makes right at the source, and the half that lives in three attributes on the cover’s <img> tag, which you set once.

The half Lede owns: weight and dimensions

An image paints faster when there are fewer bytes to fetch and decode, and the two biggest wins are both export settings.

The first is dimensions. The most common cause of a slow cover is shipping one far larger than the slot it lands in - a 4000-pixel export poured into a 1200-pixel column, so the browser downloads roughly ten times the pixels it will ever show, then makes LCP wait for all of them before throwing most away. Export at the size the slot actually renders, at 2x for retina sharpness and no more.

The second is format and weight. WebP or AVIF over JPG or PNG, at a sane quality, lands a full-width cover well under 150KB with no visible drop - often a fraction of the original. Compressing the cover is the cheapest LCP win there is. Lede exports WebP at the dimensions you pick, so the file you download is already small and already the right size: the bytes half of LCP, done before the image reaches your CMS.

The half you paste: three attributes

A small, right-sized file still loads late if the page tells it to wait. Three attributes fix that, and none of them are Lede’s to add - they live in your theme or your post, and you set them once.

• fetchpriority="high" on the cover image. Browsers guess at what to load first, and they often guess wrong about the hero. Marking it high moves it to the front of the queue. When fetchpriority was set on the Google Flights LCP image in a published test, it dropped from 2.6 seconds to 1.9 - a 0.7-second win from one attribute.
• Never loading="lazy" on the cover. Lazy-loading is the right call for images far down the post and the wrong call for the one at the top. Lazy-loading the LCP image guarantees a delay. If your CMS adds loading="lazy" to every image by default, and many do, the cover is the one place to take it back off.
• Set width and height (or aspect-ratio). This one does not speed the cover up; it stops it from shoving the page around. With no dimensions declared, the browser leaves no room, so text jumps when the cover finally lands - that jump is Cumulative Layout Shift, the third Core Web Vital. The width and height Lede shows you at export are the two numbers to drop in the tag.

Lede makes the cover small enough and sharp enough to win the race. Those three attributes make sure it is actually in the race.

One trap to name: if your cover is painted as a CSS background instead of a real <img>, the browser discovers it late and LCP suffers. A plain <img> near the top of the post is almost always the better call; when the hero genuinely has to come from CSS, preload it so discovery is not the bottleneck.

Where the lines go

Lede cannot reach into your <head> or set your server’s headers - it makes the file. Where the markup goes depends on your stack. WordPress core (6.3+) already adds fetchpriority="high" to the image it detects as the LCP element, usually the featured image, so on a current install that part is often handled for you - your job is to confirm it and make sure the image is not lazy-loaded. Ghost sizes the feature image and builds its srcset for you, but the stock theme does not set fetchpriority, so check, and add it if it is missing, on top of uploading a right-sized file. On a static site or a hand-rolled template you control the <img> directly, so add the three attributes yourself. Wherever it lives, the rule is the same: the cover loads first, eagerly, with its box declared.

A quick checklist

• Find your LCP - run a post through PageSpeed Insights and confirm the cover is the flagged element. It usually is.
• Right-size it - export at the slot’s width, 2x for retina, not a pixel more.
• Compress it - WebP or AVIF, aim well under 150KB.
• Rush it - fetchpriority="high" on the cover image.
• Never lazy-load it - strip loading="lazy" from the cover specifically.
• Pin its box - set width and height so the page does not jump.

A fast cover is mostly a small, correctly-sized file with one attribute set right, and the file is the part you can fix today. The cover above is one such file: a full-width WebP that lands under 150KB, sized for its slot. Open the editor to export yours the same way - light enough to win its own race - or start from a gallery template. Make it beautiful, then make it first.