Core Web Vitals fixes you can ship this afternoon.
Core Web Vitals fixes don't all require a developer. Here are the changes you can make this afternoon to improve LCP, CLS, and INP without touching your codebase.
You can improve your Core Web Vitals scores today without hiring a developer or rewriting your site. Some of the most common failures come from fixable image settings, missing size attributes, and third-party scripts loaded in the wrong order — none of which require a rebuild.
Before you touch anything, run your site through PageSpeed Insights. It gives you a field-data score based on real users, a lab score for comparison, and a prioritised list of what to fix. Save a screenshot. You will want the before-and-after when you talk to a developer or a client.
If you want to understand what these three numbers actually measure and why Google weights them the way it does, Core Web Vitals: the three numbers that decide if Google bothers covers the full picture. This post is about the fixes themselves.
How do you fix a slow Largest Contentful Paint (LCP)?
LCP measures how long it takes the largest visible element on the page to load — usually a hero image or a large heading. A good score is under 2.5 seconds. Most failing sites land between 4 and 8 seconds, and the cause is almost always an uncompressed image or a render-blocking resource.
Check your hero image first. Open the page on desktop, right-click the hero image, and choose "Inspect." Look at the file size in the Network tab. If it is over 200KB, that is your problem. A hero image for a professional services homepage does not need to be more than 80–120KB. Tools like Squoosh let you compress and convert to WebP in a browser tab — no software install needed. Drop the image, set quality to 75–80%, export as WebP, and re-upload.
Add the fetchpriority="high" attribute to that image. Most CMS platforms let you edit the HTML of a hero section. Adding fetchpriority="high" tells the browser to load this image before anything else. One attribute. Two minutes. Real impact on LCP.
Check for render-blocking scripts. PageSpeed will flag these directly. If you see a Google Tag Manager container, a chat widget, or an analytics script loading in the <head> without a defer or async attribute, it is holding up the paint. Most tag management setups allow you to move non-critical tags to fire after the page loads. If you use Google Tag Manager, check that your container snippet is placed just after the opening <body> tag, not in the <head>.
Enable server-side caching. If your site runs on WordPress, a caching plugin like WP Super Cache or W3 Total Cache adds static file delivery in under an hour. This alone can drop LCP by a full second for repeat visitors. Check with your host first — many managed WordPress hosts (like WP Engine or Kinsta) handle caching at the server level, which means you do not need a plugin at all.
How do you fix Cumulative Layout Shift (CLS)?
CLS measures visual stability — how much the page jumps around while it loads. A good score is under 0.1. The most common cause is images and embeds without declared dimensions.
Add width and height attributes to every image. When a browser does not know the size of an image before it loads, it holds no space for it. The image pops in, everything shifts down, and your CLS score climbs. Open your page's HTML source and look for <img> tags missing width and height. Add them. Most page builders have image settings panels where you can enter these values without touching code.
Reserve space for late-loading embeds. If you have a Google Map, a video embed, or a form loading via an iframe, give it a fixed height in CSS. Something as simple as style="min-height: 400px" on the container prevents the surrounding content from jumping when the embed loads.
Watch for web fonts causing layout shift. When a browser falls back to a system font before your custom font loads, text reflows — letters are different widths, lines break differently, and the whole block shifts. Add font-display: swap to your @font-face declarations. In Google Fonts, append &display=swap to the URL. This tells the browser to show the fallback font immediately and swap silently once the custom font is ready. The shift is smaller and faster.
Check cookie banners and notification bars. Elements that inject at the top of the page after load are a known CLS culprit. If your cookie consent tool pushes content down when it appears, configure it to overlay content rather than push it. Most consent management platforms have a setting for this.
How do you fix Interaction to Next Paint (INP)?
INP replaced First Input Delay in March 2024. It measures the time between a user interaction — a click, a tap, a keypress — and the next visible response from the page. A good score is under 200 milliseconds. High INP almost always comes from too much JavaScript executing on the main thread.
Audit your third-party scripts. Open Chrome DevTools, go to the Performance tab, record a page load, and look at the main thread activity. Long tasks — blocks over 50ms — show in red. Third-party scripts from ad networks, live chat tools, and social media widgets are common offenders. If a script is not directly tied to revenue or a client interaction, consider removing it or loading it conditionally.
Defer non-critical JavaScript. Any script that does not need to run on initial page load should carry a defer attribute. This moves execution to after the HTML has parsed. In WordPress, plugins like Asset CleanUp or Perfmatters let you defer scripts per page without editing code.
Reduce the number of plugins. Every active plugin on a WordPress site adds JavaScript. A contact page with seven plugins loading scripts — most of which are not used on that page — will produce high INP. Run a plugin audit. Disable plugins one at a time and re-test in PageSpeed. You will often find two or three plugins that double up on the same function.
If your INP score is very high — over 500ms — that usually points to a heavier front-end problem: a poorly coded theme, an unoptimised page builder, or a JavaScript framework running tasks the page does not need. That requires a developer conversation, not an afternoon fix.
What does a realistic afternoon look like?
Here is a working order for a single afternoon, assuming you have access to your CMS and basic image editing.
- Run PageSpeed Insights on your homepage and your highest-traffic landing page. Save the scores.
- Download the hero image from each page. Compress to WebP at 75–80% quality using Squoosh. Re-upload and replace.
- Add
fetchpriority="high"to the hero image tag on each page. - Check all
<img>tags on both pages. Add missingwidthandheightattributes. - Open Google Tag Manager (or your site's
<head>). Move any non-critical scripts to fire after page load. Adddeferto any inline script tags. - If you are on WordPress, activate a caching plugin or confirm server-level caching is on.
- Re-run PageSpeed Insights. Save the new scores.
A San Diego medical practice that runs this sequence on their appointment-booking page will typically see LCP drop by 1–2 seconds and CLS drop by 0.05–0.15. Not a perfect score — but a measurably better one.
Where this breaks down
These fixes address the most common causes of poor Core Web Vitals scores. They do not address everything. If your site is built on a page builder that generates bloated HTML, or your hosting server is underpowered, or you are loading forty third-party scripts for tools no one has logged into since 2021 — the afternoon fixes will help at the margin. They will not get you to green.
When McShanes Solicitors came to us, the site's technical problems went deeper than image compression. The foundation needed rebuilding before any content work could stick. That is the difference between a surface fix and a structural one.
For a full view of what is holding your site back, Search Foundations is where that work starts — a structured audit that separates the quick wins from the problems that need real attention.
And if you want the business case for why this matters beyond a Google score, Why your slow site is a sales problem, not an IT problem makes the connection plain.
Fix the images. Declare the dimensions. Move the scripts. Then check the scores again. That is a productive afternoon.
Things readers usually ask.
- Which Core Web Vital is easiest to fix without a developer?
- Cumulative Layout Shift (CLS) is the most accessible fix without developer help. Adding width and height attributes to images and reserving space for embeds can be done inside most CMS platforms in under an hour.
- Will these fixes guarantee a passing Core Web Vitals score?
- No. These fixes address the most common causes of failing scores — uncompressed images, missing dimensions, and render-blocking scripts — but a passing score also depends on your hosting speed, theme quality, and JavaScript load. A full technical audit will tell you what else is in the way.
- Does Core Web Vitals score affect Google rankings directly?
- Yes, Core Web Vitals are a confirmed ranking signal under Google's Page Experience update. A poor score does not disqualify a page from ranking, but it is a disadvantage when other signals are close between competing pages.
- How long does it take to see score improvements after making changes?
- Lab scores in PageSpeed Insights update immediately. Field data — the score based on real users — typically takes 28 days to reflect changes, since Google aggregates real user data over a rolling 28-day window.
- Should I fix Core Web Vitals before or after improving my SEO content?
- Fix the technical foundation first. Content improvements will not reach their full potential if the page loads slowly or shifts on interaction — Google measures both the content and the experience it arrives in.
Want us to look at your site?
A 20-minute call. No pitch. We'll tell you what we'd fix first.
CONTACT US →