Most slow websites are slow for a small number of reasons, and fixing those reasons doesn't require rewriting anything. You don't need to shave milliseconds off a loop. You need to stop sending the browser more than it needs.
Measure before you change anything
Guessing at performance wastes time. Run the page through a tool like Lighthouse in your browser's developer tools, or an online test that reports load time, and do it on a simulated phone with a slower connection rather than your office laptop.
Two numbers to watch, both part of what search engines call Core Web Vitals: how long until the largest thing on screen appears, and how much the layout jumps around while loading. Note where you're starting so you can tell whether a change actually helped.
Images are usually the biggest problem
On a typical content site, images are most of the page weight, and they're often far larger than they need to be.
- Serve the right dimensions. A photo displayed at 800 pixels wide shouldn't be a 4000-pixel file scaled down by the browser. Resize it first.
- Use modern formats. WebP and AVIF produce much smaller files than old JPEG and PNG at the same visual quality. Most build tools can convert automatically.
- Compress. Even after resizing, run images through a compressor. The difference is often large and hard to see with the eye.
- Use
srcsetso phones get a small version and large screens get a bigger one. - Lazy-load images below the fold with
loading="lazy"so the browser only fetches them as the reader scrolls toward them.
Fonts add weight quietly
Custom fonts are easy to overuse. Every weight and style is a separate file to download.
Limit yourself to the two or three weights you actually use. Add font-display: swap so text shows in a fallback font immediately instead of staying invisible while the custom font loads. If you're loading fonts from a third party, add a preconnect hint, or self-host the files to cut out the extra connection.
Ship less JavaScript
JavaScript is expensive twice: the browser downloads it, then it has to parse and run it, and that work blocks everything else.
- Add
deferto script tags so they don't hold up the page render. - Split your code so each page only loads what it needs, rather than one giant bundle for the whole site.
- Audit third-party scripts honestly. Analytics, chat widgets, ad tags, social embeds, and A/B testing tools each add weight and often make their own network requests. Ask whether each one earns its place. Removing two you don't really use can beat days of hand-tuning your own code.
Stop the layout from jumping
That frustrating moment when you go to tap a link and the page shifts, so you tap an ad instead, is layout shift, and it's measurable and fixable.
- Always set
widthandheightattributes on images and videos, so the browser reserves the right space before the file arrives. - Give ad slots and embedded widgets a fixed minimum height.
- Avoid inserting banners or notices above content that's already visible; push them in a way that doesn't shove everything down.
Cache and use a CDN
Caching tells browsers and servers to hold onto files they've already fetched. Set long cache lifetimes for things that rarely change, like logos, fonts, and CSS, and use a filename that changes when the file changes so updates still get through.
A content delivery network stores copies of your files on servers around the world, so a visitor loads them from somewhere nearby instead of from a single origin server that might be on another continent. For a global audience this is one of the larger wins available.
Check your server's response time
If the browser sends a request and waits a long time before the first byte comes back, no amount of front-end tuning will save you. Slow database queries, an overloaded shared host, or rebuilding a page from scratch on every request are common causes. Caching the rendered page, upgrading the hosting, or generating static pages ahead of time all help here.
Trim redirects and preload the essentials
Each redirect is a full round trip before the real page even starts loading. A chain of them, an old link that points to a URL that points to another URL, adds up on a slow connection. Clean up the ones you control so links land on the final address directly.
For the handful of resources the page truly can't render without, a font used in the headline, the hero image, a critical stylesheet, a preload hint tells the browser to start fetching them right away instead of discovering them partway through. Use it sparingly; preloading everything just recreates the traffic jam.
Don't over-engineer it
A content site that's mostly articles and images doesn't need a heavy single-page framework and the JavaScript that comes with it. Plain HTML with a little CSS and a small amount of script loads fast almost by default. Reach for bigger tools when the project genuinely needs them, not out of habit.
Re-test after each change
Performance work can backfire. A plugin added to compress images might add its own script; a caching layer might serve stale pages. After each change, run the same measurement you started with, on the same simulated device, so you know whether the number moved in the right direction.
Takeaway
Test on a real phone, fix your images first, cut the scripts you don't need, lock down the layout so it stops shifting, and let caching and a CDN do the rest. That handful of changes covers most of what makes a site feel slow.