Most slow websites are slow for the same handful of reasons: images that are too heavy, fonts and stylesheets that hold back the first paint, too many third-party scripts, and hosting or caching that makes every visit start from zero. Fix them in that order and most sites get noticeably faster without a redesign.
How to tell if your site is actually slow
How the site feels on your own laptop does not tell you how it loads for your visitors. Run your main pages through PageSpeed Insights and look at the field data first, which comes from real visitors over the last 28 days, and only then at the lab test. Google's Core Web Vitals give you three numbers to watch:
- LCP under 2.5 seconds: when the main content of the page shows up.
- INP under 200 milliseconds: how quickly the page reacts to a tap or a click.
- CLS under 0.1: how much the layout jumps around while it loads.
Test the pages people actually land on (the home, your main service pages, the posts that bring traffic) and test them on mobile. The mobile result is the one Google uses, and it is almost always the worse of the two.
Start with the images
On most of the sites we review, images are by far the heaviest part of the page. A photo exported straight from a camera or a stock library can weigh more than everything else on the page combined.
- Serve WebP or AVIF instead of JPG and PNG.
- Resize each image to the size it is displayed at, twice that at most for high-density screens.
- Lazy-load the images below the fold, but never the main image at the top: that one should load first.
- Give every image its width and height, so the page does not jump when it arrives.
Fonts and CSS that hold back the first paint
Before the browser can draw anything, it downloads every stylesheet in the head of the page, including any font stylesheet linked from another server. Each one is a round trip the visitor waits through, looking at a blank screen.
When we launched astropanda.io, PageSpeed flagged it on our own site. The Google Fonts stylesheet alone held back the first paint for about 750 milliseconds on mobile. We now host the fonts on our own server, load only the character sets we use, and ask for the two fonts the first screen needs before anything else.
- Host your web fonts yourself and use
font-display: swap, so text shows up right away in a fallback font. - Use fewer families and fewer weights. Every weight is another file.
- Keep the CSS that loads on every page small, and drop the rules nothing uses anymore.
Too many scripts
A chat widget, a heatmap, three analytics tags, a slider plugin nobody uses anymore. Every script competes for the same thread that has to respond when the visitor taps something, and that delay is exactly what INP measures.
- List every third-party script on the site and who still uses its data.
- Remove the ones nobody reads. Load the rest with
defer, or only after the visitor interacts. - On WordPress, review the plugins: it is common to find one that adds its scripts to every page for a feature used on a single one.
Hosting and caching
If the server takes a second to answer, nothing on the page can start before that second is over. PageSpeed reports it as Time to First Byte (TTFB), and under 0.8 seconds is a good result.
- Use page caching, at the server or with a caching plugin, so pages are not rebuilt on every visit.
- Let browsers keep CSS, JavaScript and fonts for a long time, with a version in the file name so changes still reach everyone.
- Add a CDN if your visitors are far from your server.
- Make sure your hosting plan matches your traffic. A cheap shared plan that answers slowly ends up costing you visits.
Keep it fast after launch
Speed degrades quietly: a new plugin, a tag added for a campaign, a 4 MB photo uploaded to the blog. Check your main pages once a month and after every significant change, and treat a drop in the scores like any other bug. This check is part of what a maintenance plan should cover.