Ask ten people how to speed up a website and you will get ten different answers, most of them technically true and almost none of them ranked by impact. Somebody will tell you to minify your CSS. Somebody else will suggest lazy loading. Both help a little. Neither is where your problem lives.
This guide puts the work in order of return. Do the first three things and most sites get dramatically faster. Do the last three only if you are chasing the final tenths of a second.
First, measure the right thing
A single overall performance score is a poor diagnostic. It compresses a dozen different measurements into one number, and it moves for reasons that have nothing to do with your visitors. Look at the underlying metrics instead.
- Time to first byte — how long the server takes to begin responding. This is your hosting and your backend code. Under 200 milliseconds is good; over 600 is a problem you cannot decorate your way out of.
- Largest contentful paint — when the biggest visible element finishes rendering. This is what a human experiences as “the page loaded.” Aim for under 2.5 seconds on mobile.
- Cumulative layout shift — how much the page jumps around while loading. Caused almost entirely by images without dimensions, late-loading fonts, and ad slots that reserve no space.
- Interaction to next paint — how quickly the page responds when someone taps something. Usually a JavaScript problem.
Test on a simulated mid-range phone over a throttled connection, not on your desktop over office fiber. The gap between those two conditions is where most sites quietly lose people.
The three changes that do most of the work
1. Fix your images
On a typical small business site, images account for somewhere between sixty and eighty percent of total page weight. Nothing else on this list comes close. Three fixes, in order:
Resize before uploading. A photograph never needs to be wider than the space it occupies. If your content column is 800 pixels across, a 1600-pixel image covers even high-density screens with room to spare. Uploading a 6000-pixel original and letting the browser shrink it means the visitor downloads every one of those wasted pixels.
Convert to a modern format. WebP typically produces files twenty-five to thirty-five percent smaller than an equivalent JPEG with no visible difference. AVIF goes further still. Every current browser supports WebP, and any decent plugin or build step will generate it automatically.
Set explicit width and height attributes on every image. This costs nothing, takes seconds, and eliminates most layout shift on its own by letting the browser reserve the correct space before the file arrives.
2. Cache aggressively
Every time someone visits a dynamic page, your server rebuilds it from scratch: run the code, query the database, assemble the HTML, send it. For a page that has not changed in three weeks, that is enormous waste repeated thousands of times.
Page caching stores the finished HTML and serves it directly on subsequent visits. It is the single largest server-side improvement available to most sites, and it commonly cuts time to first byte by seventy percent or more. Layer in object caching so repeated database queries are held in memory, and browser caching so returning visitors do not re-download files they already have.
The one thing to configure carefully is exclusions. Cart pages, checkout, logged-in views, and anything personalized must bypass the cache, or visitors will start seeing each other’s content. Every serious caching tool handles this correctly out of the box; just verify it rather than assuming.
3. Put a content delivery network in front of everything
Physical distance is real latency. If your server sits in Virginia and your visitor is in Portland, every single request makes that round trip. A content delivery network keeps copies of your static files on servers around the country and serves each visitor from the nearest one.
Beyond the geography, a good network absorbs traffic spikes, provides free SSL, blocks a meaningful volume of malicious traffic, and reduces load on your origin server. Setup usually means changing your nameservers and waiting an hour. The free tiers of the major providers are more than adequate for most small business sites.
The next tier, worth doing once the basics are done
4. Take control of your fonts
Custom fonts are a common and invisible tax. Each family and weight is a separate file, and while those files load, text is often hidden entirely. Limit yourself to two families and at most four weights, host the files on your own domain to avoid an extra connection to a third-party server, and set the display behavior so text renders immediately in a fallback font and swaps when the custom one arrives.
5. Audit third-party scripts ruthlessly
Analytics, heatmaps, chat widgets, social embeds, review widgets, retargeting pixels, A/B testing tools. Each one arrived for a reason, and most of those reasons expired. Every script is code from a server you do not control, executing on the device of every visitor you have.
List everything currently loading on your site. For each item, name the person who reads the data it produces. Anything without a name attached comes off. This audit routinely removes a third of a site’s JavaScript payload in an afternoon.
6. Trim what is actually running
Most content management systems load every plugin’s stylesheet and script on every page, whether that page uses them or not. Your contact form’s assets do not belong on your blog posts. Conditional loading is fiddly to configure but frequently strips a substantial chunk off pages that were never using the code in the first place.
What people worry about that rarely matters
- Minification. Real, but small. Compression at the server level already handles most of the benefit.
- Chasing a perfect score. The last few points usually require sacrificing something a visitor actually values.
- Reducing total request count. This mattered enormously in the era of HTTP/1.1. Modern protocols multiplex requests, so twelve small files are no longer meaningfully worse than one large one.
- Exotic hosting hardware. Faster processors help a slow site marginally. Caching helps it enormously, and costs nothing.
A realistic weekend plan
- Record your current numbers so you have a genuine baseline to compare against.
- Run a bulk image optimizer across your media library and enable WebP conversion.
- Install and configure a page caching solution, then confirm the exclusions are correct.
- Point your domain through a content delivery network.
- Remove every third-party script nobody can justify.
- Measure again, on the same simulated device and connection as your baseline.
A site loading in six seconds usually lands somewhere near two after that sequence. It is not glamorous work, and none of it requires writing code, but it is the difference between a visitor who reads your page and one who never sees it at all.