If your website feels slow, you lose visitors before they read a word. This guide shows you how to diagnose the real cause of slowness, prioritise the fixes that matter, and measure progress using Google’s Core Web Vitals. You will finish with a concrete checklist you can apply today.
Why Page Speed Is a Cause, Not a Symptom
Slow pages are rarely one big problem. They are the sum of many small decisions: an oversized hero image, a font that blocks rendering, a third-party script that runs before your content. Each one adds a fraction of a second. Together they push a page past the point where visitors wait.
Speed also compounds. A slow first load delays every script that follows. So the goal is not to shave milliseconds everywhere, but to find the one or two things that block the page from becoming usable.
Measure With Core Web Vitals First
Google’s Core Web Vitals give you three real, named metrics instead of a vague “it feels slow.”
Largest Contentful Paint (LCP)
How long until the biggest visible element (usually a hero image or headline) appears. Aim for under 2.5 seconds. Slow LCP almost always means a heavy image or a server that responds late.
Interaction to Next Paint (INP)
How quickly the page responds when someone taps or clicks. Long tasks from JavaScript are the usual culprit.
Cumulative Layout Shift (CLS)
How much the layout jumps as things load. Caused by images without set dimensions, or content injected above what the reader is already looking at.
Use Google Lighthouse (built into Chrome DevTools) and PageSpeed Insights to read these. WebPageTest gives a frame-by-frame filmstrip that shows exactly when your page becomes usable.
Fix the Biggest Cost First: Images
On most sites, images are the heaviest thing on the page. In my experience auditing small business sites, resizing and compressing images alone often cuts load time in half.
- Serve images at the size they are displayed, not the size they were uploaded.
- Use modern formats like WebP or AVIF where your platform supports them.
- Always set width and height attributes so the browser reserves space and avoids layout shift.
- Lazy-load images below the fold so they don’t compete with the first screen.
Tame Fonts and Third-Party Scripts
Custom fonts can block text from showing. Add font-display: swap so text appears immediately in a fallback font, then swaps in. Limit yourself to the weights you actually use.
Third-party scripts (chat widgets, analytics, ad tags, social embeds) are often the hidden cause of poor INP. Each one runs code you don’t control. Audit them honestly: remove what you don’t use, and load the rest after the main content.
A Real Example
A small bakery site took roughly seven seconds to become usable. The homepage loaded a 4 MB banner photo, three separate font families, and a live social feed widget. We resized the banner to a compressed 180 KB WebP, dropped to one font with two weights, and deferred the social feed until after the page rendered. LCP fell from over five seconds to about 1.9. No redesign, no new hosting; just removing weight the page never needed.
Common Mistakes and How to Fix Them
- Testing only on your own fast connection. Test on a throttled mobile profile in Lighthouse, where most visitors actually are.
- Chasing a perfect score. A 100 in Lighthouse is not the goal. A page that feels instant to real users is. Fix the metric that is failing, not every warning.
- Adding a caching plugin and stopping. Caching helps repeat visits but does nothing for the oversized image on first load. Fix the assets themselves.
- Ignoring the server response time. If the server takes 1.5 seconds to send the first byte, no front-end trick will save you. Check hosting quality and database queries.
Action Checklist
- Run PageSpeed Insights and note which of LCP, INP, CLS is failing.
- Compress and correctly size every image on the first screen.
- Set explicit width and height on all images.
- Reduce font families and add font-display: swap.
- Audit third-party scripts; remove or defer non-essential ones.
- Re-test on a throttled mobile profile and compare before and after.
Conclusion and Next Step
Speed is won by removing weight and blocking work, not by adding tools. Start with one page, fix the single failing metric, and measure the difference. Once you see LCP drop, apply the same checklist across your key pages.
FAQ
How fast should my website be?
Aim for Largest Contentful Paint under 2.5 seconds on mobile. That is Google’s “good” threshold and a reasonable target for most sites.
Do I need a developer to improve speed?
Often no. Image compression, font limits, and removing unused scripts are things most site owners can do through their platform settings or a plugin.
Does page speed affect SEO?
Core Web Vitals are a confirmed Google ranking signal, though a small one. The bigger benefit is that faster pages keep visitors from leaving.
Why is my score different each time I test?
Lab tests vary with server load and network conditions. Run a test several times and look at the trend, not a single number.
References
- Google Core Web Vitals and PageSpeed Insights (web.dev)
- Google Lighthouse, built into Chrome DevTools
- WebPageTest