Page speed stopped being a "nice to have" the moment Google started using Core Web Vitals as a ranking signal. But the bigger cost is not rankings. It is the visitors who leave a slow page before it finishes loading, and the leads that never arrive because the contact form appeared two seconds too late.
The good news: on most business websites, a small number of fixes account for most of the improvement. This article walks through seven of them, ordered by how much they usually move the numbers. Each one comes with the reason it works, so you can judge whether it applies to your site.
First, what you are optimizing
Core Web Vitals are three metrics that Google collects from real Chrome users and reports in Search Console. Each has a "good" threshold that 75% of your visitors need to hit.
- LCP (Largest Contentful Paint) measures how long the biggest visible element, usually a hero image or headline, takes to appear.
- INP (Interaction to Next Paint) measures how quickly the page responds when someone taps a button or opens a menu.
- CLS (Cumulative Layout Shift) measures how much content jumps around while the page loads.
Run your site through PageSpeed Insights before you change anything. The "field data" section tells you which of the three needs attention. Fix that one first.
1. Compress and resize images
Images are the single largest cause of slow LCP on marketing sites. A 4000-pixel photo exported straight from a camera can weigh 3 MB; the same image at 1600 pixels in WebP or AVIF format weighs 100 KB and looks identical on screen.
What to do:
- Export images no wider than they will ever be displayed. For a full-width hero that is 1600 to 1920 pixels. For a card thumbnail, 600 to 800 pixels.
- Serve WebP or AVIF with a JPEG fallback. Modern frameworks and CDNs do this conversion automatically.
- Mark the hero image as high priority so the browser fetches it first, and lazy-load everything below the fold.
This one fix routinely takes LCP from "poor" to "good" on its own.
2. Serve pages from a CDN cache
When a page is rendered on your server for every visitor, the time to first byte depends on how busy the server is and how far away the visitor sits. A content delivery network keeps a copy of the finished page at edge locations around the world and serves it in tens of milliseconds.
The trick is knowing when to refresh the cached copy. Static generation with on-demand revalidation solves this: pages are built once, served from the edge, and rebuilt only when the content changes in the CMS. Visitors get the fast path almost every time, and editors still see updates within seconds.
3. Cut third-party scripts
Chat widgets, heat maps, A/B testing tools, multiple analytics tags, social embeds. Each one loads its own JavaScript, often hundreds of kilobytes, and runs it on the main thread while your visitor is trying to tap a button. This is the most common cause of poor INP.
Audit every script on the page and ask two questions: who looks at the data it produces, and what decision changed because of it in the last quarter? Remove the ones without a good answer. Load the rest after the page becomes interactive, or through a tag manager that delays non-essential tags.
4. Reserve space for images, embeds and ads
Layout shift happens when something loads late and pushes the content below it. The visitor goes to tap a link, the page jumps, and they tap something else. CLS punishes exactly this.
The fix is simple: every image, video embed and ad slot should have its width and height declared, or a CSS aspect ratio, so the browser reserves the space before the asset arrives. Cookie banners and notification bars should overlay the page rather than push it down.
5. Load web fonts without the flash
Custom fonts are worth keeping, but they are often loaded in a way that blocks text rendering or causes a visible swap that shifts the layout. Three settings solve most of it:
- Use
font-display: swapso text appears immediately in a fallback font. - Preload the one or two font files used above the fold.
- Self-host the fonts instead of pulling them from a third-party domain, which saves a DNS lookup and a connection.
Next.js and similar frameworks handle all three automatically when fonts are configured through their font loader.
6. Ship less JavaScript
Every kilobyte of JavaScript has to be downloaded, parsed and executed before the page is fully interactive. Marketing sites frequently ship 500 KB or more because a heavy component library, a carousel plugin and a date picker were added for one page each.
Check your bundle for large dependencies that serve a small purpose. Split code by route so the home page does not pay for the pricing calculator. Render as much as possible on the server so the browser receives finished HTML instead of instructions for building it.
7. Measure with real-user data, not only lab tests
Lab tools like Lighthouse are useful for finding problems, but they run on a simulated device and network. Your visitors use a mix of old phones on mobile data and fast laptops on fiber. The Core Web Vitals report in Search Console and the field data in PageSpeed Insights reflect that mix, and it is what Google actually ranks on.
Set up a monthly check of the field data. Performance regresses quietly: a new plugin here, a bigger hero image there. Catching it early is much cheaper than a rescue project later.
Putting it together
If you only have a day, do the first three items. Images, caching and third-party scripts are where the biggest wins hide, and they require no redesign. The remaining four turn a fast site into a consistently fast one.
At Codality we run this checklist on every site we build or take over, and we are happy to run it on yours. Send us the URL and we will tell you which of the seven would make the biggest difference.