Page Speed for Bloggers: Fixing Core Web Vitals Without Becoming a Developer
What LCP, INP and CLS mean in plain language, how to measure them for free, and the ten fixes that solve most speed problems on small blogs.
Page speed matters for two reasons. Slow pages frustrate readers, who leave before they read anything. And Google uses page experience signals, including Core Web Vitals, as part of how it evaluates pages, though content relevance and quality matter far more.
You do not need to be a developer to make a blog fast. Most speed problems on small blogs have the same handful of causes, and most can be fixed in an afternoon.
The three Core Web Vitals in plain language
Largest Contentful Paint (LCP) measures how long it takes for the biggest thing on the screen, usually the main image or headline, to appear. Google's guidance considers 2.5 seconds or less good.
Interaction to Next Paint (INP) measures how quickly the page responds when a reader taps or clicks something. Under 200 milliseconds is considered good. It replaced the older First Input Delay metric in 2024.
Cumulative Layout Shift (CLS) measures how much the page jumps around while loading, such as text moving down when an ad or image appears above it. A score of 0.1 or less is considered good.
How to measure, for free
- PageSpeed Insights (pagespeed.web.dev): enter a URL to see lab measurements and, for pages with enough traffic, real-user data from the Chrome User Experience Report.
- Search Console's Core Web Vitals report: shows groups of URLs on your site that pass or fail, based on real visitors.
- Your browser's developer tools: the Lighthouse panel in Chrome runs the same lab tests locally.
Real-user data (often labelled "field data") is what counts. Lab scores are useful for diagnosing, but do not obsess over reaching a perfect 100.
Test your homepage, a typical post and your most popular post, on mobile. Mobile results are usually worse and matter more.
The ten fixes that solve most problems
1. Resize and compress images
Oversized images are the single most common cause of poor LCP on blogs. Export images at no more than twice the display width, use WebP or AVIF, and aim for most photos under 200 KB.
2. Do not lazy-load the main image
Lazy loading is great for images further down the page, but if your featured image at the top is lazy-loaded, the browser waits to fetch it, hurting LCP. Make sure the first image loads normally. Some themes lazy-load everything by default; check yours.
3. Set image dimensions
Add width and height attributes to images (most platforms do this automatically). Without them, the browser does not know how much space to reserve and the page shifts when images arrive, hurting CLS.
4. Reserve space for ads and embeds
If you run ads, embed videos or show newsletter boxes that load late, give their container a fixed minimum height so content does not jump.
5. Cut plugins and third-party scripts
Every social sharing widget, chat bubble, analytics tag, heatmap tool and font loader adds weight and can slow interactions. Audit them ruthlessly. For each one, ask: "Have I looked at the data or used this feature in the last three months?" If not, remove it.
6. Use a lightweight theme
Multipurpose themes with page builders often load a lot of code for features you never use. A lean theme focused on reading is usually dramatically faster.
7. Limit web fonts
Each font family and weight is another file. Two families and three or four weights is plenty for most blogs. Self-host fonts where possible and use font-display: swap so text appears immediately in a fallback font.
8. Enable caching and a CDN
Page caching serves pre-built pages rather than generating them for every visitor. A content delivery network (CDN) serves files from servers close to your readers. Many hosts include both; a free CDN tier is available from several providers.
9. Defer non-essential JavaScript
Scripts that are not needed to show the content, such as comment systems, can usually be loaded after the main content or only when a reader scrolls to them. Many caching plugins offer a "delay JavaScript" option. Test carefully, because deferring the wrong script can break features.
10. Choose decent hosting
Very cheap shared hosting can make every other fix pointless if the server takes over a second to respond. Look at "Time to First Byte" in your test results. If it is consistently slow, consider better hosting.
Diagnosing which fix you need
| Symptom | Likely culprit | First fix |
|---|---|---|
| Poor LCP | Large or lazy-loaded hero image; slow server | Fix 1, 2, 10 |
| Poor CLS | Images without dimensions; late ads/embeds; font swaps | Fix 3, 4, 7 |
| Poor INP | Heavy JavaScript; too many third-party scripts | Fix 5, 6, 9 |
What not to chase
- A perfect score. Going from 85 to 100 in a lab test rarely changes anything for readers or rankings.
- Every Lighthouse suggestion. Some suggestions offer tiny gains for large effort. Prioritise the ones flagged as large savings.
- Speed at the expense of content. Removing all images to get a faster page is a bad trade. The goal is a fast page that is still worth reading.
A realistic target
For a typical blog, aim for:
- Main post pages passing all three Core Web Vitals in field data on mobile.
- Total page weight under about 1.5 MB for a long post with images.
- Fewer than a dozen third-party requests.
Keeping it fast
Speed degrades as you add plugins, embeds and widgets over time. Put a quarterly reminder in your calendar to run your three test pages through PageSpeed Insights and check the Core Web Vitals report. Catching a regression early is far easier than diagnosing a site that has slowly become sluggish over two years.
Current Core Web Vitals thresholds
Google's documentation describes "good" thresholds, measured at the 75th percentile of page loads:
- Largest Contentful Paint (LCP): 2.5 seconds or less
- Interaction to Next Paint (INP): 200 milliseconds or less (INP replaced First Input Delay in March 2024)
- Cumulative Layout Shift (CLS): 0.1 or less
