1. Why your website is slow (and how to find out)
Most slow websites have the same problems layered on top of each other: oversized photos make up the largest chunk of what a page has to download on most small business sites, extra features bolted on from plugins and outside tools delay the page from appearing, cheap shared hosting makes the site slow to start responding, the absence of any repeat-visit speed-up forces the site to rebuild every page from scratch on each visit, and having nothing that serves your site from near each visitor means people far from your server wait longer for everything.
Before you start fixing anything, run your site through Google PageSpeed Insights (pagespeed.web.dev). Run the mobile version specifically — mobile scores are almost always significantly lower than desktop, and the mobile version of your site is what Google looks at when it decides your ranking. PageSpeed will rank your issues by impact. Work from the top.
The report lists exactly what's slowing your page down and how much each item costs you, usually photos first, then the page's behind-the-scenes code. It shows you the order things load in: what shows up first, what's waiting on what, and where the longest delays are. You don't need to understand the technical detail — the ranked list of issues is the part that matters.
GTmetrix and WebPageTest.org are also worth using. GTmetrix gives you a clear chart and a summary of what's largest and slowest on your page. WebPageTest lets you test specific connection speeds and device types, which is useful for understanding what the site really feels like for someone on a phone with an average mobile connection (the conditions PageSpeed Insights uses for its mobile scoring).
Once you know what's dragging your scores down, you can fix the right things instead of guessing. The rest of this guide covers every fix in order of likely impact: start from the top and stop when your scores are where you need them.
2. Your photos: the biggest single fix
Photos cause more slowdown on small business sites than everything else combined. A homepage with five oversized photos can easily force a visitor to download 8–12 MB before the page is usable. On a phone connection, that's the difference between a page that feels instant and one that feels broken.
Step one: shrink every photo. Before changing anything else, run every photo on your site through a compression tool. Tools like Squoosh, TinyPNG, or ImageOptim cut file sizes by 60–80% with no visible drop in quality. A 3 MB main photo should come down to 200–400 KB. There's no reason for a decorative image to be heavier than that. Shrink every photo before doing anything else: it's the fastest improvement with the highest return.
Step two: use a modern photo format. A newer image format called WebP looks just as good as a regular JPEG photo but the file is roughly 25–35% smaller. An even newer format goes further (40–50% smaller), though slightly fewer devices can read it. WebP is safe to use everywhere today — every major browser, including Safari, has supported it for years. The cleanest setup hands each visitor the newest format their device can handle and falls back to an older one when needed. If that's more than you want to manage, just convert your photos to WebP and call it done.
Step three: send each device a right-sized photo. If your content area is only so wide on screen, sending a giant full-resolution photo and shrinking it to fit is wasteful. The visitor downloads three times more than they actually see. Set your photos up so phones get a smaller file and big screens get the full one. At minimum, have a phone-sized version and a desktop version — the difference in file size is substantial for large photos, and phone users feel it the most.
Step four: tell the page each photo's size up front. When the page doesn't know how big a photo will be before it arrives, it can't hold space for it. So as photos load in, they shove the text and buttons around, and someone trying to tap a link suddenly taps the wrong thing. That jumping around is one of the things Google measures and penalizes. Telling the page each photo's width and height ahead of time lets it hold the right space, so nothing shifts as the page loads.
Step five: let lower photos load as visitors scroll. Any photo that isn't on screen when the page first opens can wait until the visitor scrolls down near it. That way the page doesn't have to download everything before it's usable — it feels instant. The one critical exception: your main photo at the top of the page should be set to load first and fast, never delayed. It's the biggest thing a visitor sees, so it sets the tone for how quick your whole site feels. Accidentally delaying that top photo is a common mistake that wrecks your speed score.
Sorting out your photos alone commonly cuts what a page has to download by 50–70%. It's the highest-return fix available, it works no matter what your site is built on, and it doesn't require touching your hosting or rebuilding anything.
3. Bloated page code that slows everything down
After photos, the next biggest drag on speed is the behind-the-scenes code that runs your page — the interactive bits, the styling, and everything bolted on by plugins and outside tools. It's harder to fix than photos because it's usually baked deep into your platform. The basic problem is simple: a page can only do one thing at a time, and when it's busy running a pile of heavy code, it can't draw the page or respond to taps.
Start by taking stock. A typical WordPress site running five to ten plugins is loading 15–30 separate code files, and each one is something the page has to fetch and deal with before it's ready. On most plugin-heavy sites, 70–80% of that code isn't even being used on the page a visitor is looking at — it's pure dead weight that's slowing the page down for no benefit.
Push non-essential code to load later. Anything that doesn't need to run before the page appears should be told to wait until after the page has drawn, instead of holding everything up. Things like website analytics, chat widgets, marketing trackers, and social media embeds all fall into this bucket — none of them need to run before a visitor can see and use your page, so letting them load quietly in the background after the main content is a free speed win.
Audit your plugins. Most WordPress sites are running plugins that overlap and have no idea what each other is loading. A contact-form plugin that loads its code on every page of the site, including pages with no form. A homepage slideshow plugin that quietly adds weight to every other page too. A backup plugin that loads something on the public site it never needed to. Each plugin piles on more for the page to download. The discipline is to ask, for every plugin: is what it does worth what it costs me in speed, and is it loading only where it's actually needed?
Trim the styling code. Big bloated styling files full of rules your site never uses add weight and slow the page down. If you're on a page builder or a premium theme, that styling file is probably enormous and covers hundreds of design pieces your site doesn't touch. The clean approach is to load just the small bit of styling needed to paint the top of the page right away, then let the rest load afterward, so visitors see something immediately instead of staring at a blank screen.
On hand-coded sites, none of this is a problem by design. A custom-built site only loads the code that one specific page actually needs. There's no bulky framework to start up, no pile of plugins to manage, no dead code piling up over the years. The speed advantages of clean code add up. Each page is as lean as its content requires, with nothing extra.
4. Hosting and how fast your site responds
How quickly your site starts responding — the gap between someone asking for your page and your server starting to send it back — sets a ceiling on everything else. If your server takes a second and a half just to begin responding, your page can never feel fast no matter how perfectly everything else is tuned, because nothing can happen until the server answers.
Google's recommended target is under eight-tenths of a second to start responding, and under two-tenths is excellent. Slower than that, and it shows up in your PageSpeed report as a specific problem to fix.
Cheap shared hosting is the most common culprit. A cheap shared plan crams your site onto one machine alongside hundreds of others. When a neighbor gets a traffic spike, runs something badly written, or gets hit by bots, your site gets squeezed right along with them. This isn't theoretical. The same site moved off a $6/month shared plan onto a quality hosting plan commonly starts responding two to four tenths of a second faster before any other change. For low-traffic sites, a well-run shared plan from a quality host (A2 Hosting, SiteGround, Kinsta for WordPress) performs reasonably. The problem is the bargain-basement plans that pack as many sites as possible onto one machine.
The engine version your host runs matters more than people realize. The software that runs PHP-based sites like WordPress has gotten dramatically faster over the years — newer versions run two to three times quicker on a lot of common work. If your host is still running an old version (common on older shared plans), you're leaving free speed on the table. You can usually check and upgrade it with one click in your hosting control panel — no code changes needed. If you're not sure, your host's support team can bump it for you in a minute.
Where your server lives affects response time. A server in Dallas takes longer to answer a Seattle visitor than a server in Seattle does. If most of your visitors are in one region, hosting closer to them shaves off a little delay. This matters less once you serve your site from near each visitor (covered in the next section), but it still counts for that very first response, which usually still comes straight from your own server.
5. Stop rebuilding your pages on every visit
Without any speed-up in place, your site rebuilds every page from scratch on each visit: it runs its code, looks things up in its database, assembles the page, and sends it over. That happens on every single visit, even when the page hasn't changed since the last person looked at it. For a site with a few dozen visitors a day on decent hosting, that's manageable. For anything with real traffic, it's wasteful.
The fix is to save a ready-made copy of each page so the next visitor gets the saved copy instead of waiting for a fresh rebuild. The speed difference is dramatic — a saved page can come back almost instantly instead of taking a noticeable beat to assemble.
For WordPress sites. WP Rocket is the most polished option and handles saving ready-made pages, remembering files on repeat visits, pushing non-essential code to load later, and database cleanup, all in one plugin. W3 Total Cache is free and covers the same ground but takes more fiddling. LiteSpeed Cache is excellent if your host supports it (A2 Hosting and certain quality plans do). At minimum, every WordPress site needs this kind of page saving turned on — running without it is a big, needless speed penalty.
Let repeat visitors reuse files they already have. Your site can tell a visitor's device to hang on to files like your styling and photos for a while. If those don't change often, set them to be remembered for a long time (a year or more is reasonable) so people coming back don't re-download things they already have — their second visit loads almost instantly. WordPress speed plugins handle this automatically; on a custom-built site it's a simple setting on the server.
Remembering expensive lookups. On sites that lean heavily on their database, you can also keep the answers to slow, repeated database lookups in fast memory so they don't have to be re-run on every single visit. This matters most for online stores or membership sites with lots of per-customer content, and it's less important for a simple informational site.
6. Serving your site from near each visitor
You can sign up for a service that keeps copies of your site's files (photos, styling, and the rest) on machines all over the world, so that each visitor gets served from one near them instead of from your one home server. For a visitor in Seattle loading a site hosted in Atlanta, that cuts the back-and-forth travel time for each file way down. Multiply that across every file on a typical page and you've saved real, noticeable loading time.
Cloudflare is the default choice for small business sites. Its free plan runs all your traffic through its worldwide network, keeps copies of your files close to visitors everywhere, handles the secure-connection padlock, and throws in basic protection against attacks. Setup is a quick change to the settings that point your domain name at your site — you flip them over to Cloudflare and it's active. For most small business sites the free plan is plenty, and the whole thing takes under an hour.
On Cloudflare's paid plans, you can also keep ready-made copies of full pages out on that worldwide network (not just the files), which nearly wipes out the wait for repeat visitors. That's especially worth it for high-traffic sites or sites whose home server is slow to respond.
This isn't a substitute for fixing your hosting. Cloudflare serves your files from nearby, but your own home server still handles the very first response. A fast worldwide network sitting in front of a slow home server still feels slow on that first hit. Fix your hosting and your page-saving first, then add this on top to handle the worldwide distribution and take load off your server.
One setup mistake worth avoiding: make sure the service isn't accidentally overriding the rules that tell visitors' devices to remember your files. Cloudflare respects those by default, but if you've set anything unusual, double-check it's still working as you intended.
7. Google's page-speed health checks: what they measure
Google has a set of official page-speed health checks it rolled out as ranking factors in 2021 and has kept updating since. They grade three different things about how your page feels to a real visitor. Knowing what each one looks at tells you which fixes are most likely to move it.
How fast your main content shows up. The first check times how long until the biggest thing on screen — usually your main photo, a big headline, or a featured video — actually appears. The target is under two and a half seconds. This is driven mostly by photo size (if the biggest thing is a photo), how fast your server starts responding (a slow server delays everything), and anything getting in the way of the page drawing. If the biggest thing is a photo, make sure it's set to load first and fast, not delayed, and shrunk to the smallest size that still looks good. Do that on a decent server and it'll show up comfortably inside two and a half seconds on any reasonable connection.
How quickly the page reacts when someone taps or clicks. The second check times how fast your page responds when a visitor taps a button, clicks a link, or opens a menu. The target is under two-tenths of a second. When this is slow, it almost always means too much heavy code is running and hogging the page, so taps just sit there for a beat before anything happens — which feels broken and makes people leave. The fix is the same as trimming bloated code in the section above: cut the dead weight, and push non-essential code to load later so it's not in the way when someone wants to interact.
How much the page jumps around as it loads. The third check measures how much your layout shifts while the page is loading. Photos with no size set aside, late-arriving ad slots, fonts that swap in and reflow the text, and content that pops in and shoves everything down all make the page jump. That's the maddening thing where you go to tap a button and it leaps out from under your finger. The most common fix is telling the page each photo's size up front so it can hold the right space, and loading your fonts early so text doesn't get rearranged after it appears.
Your PageSpeed Insights report shows two kinds of scores: real-world numbers gathered from actual people who've visited your site, and a lab-style simulated test. The real-world numbers are what Google uses for ranking. If those are noticeably worse than the simulated test, it means real people on real phones and connections are having a worse time than the simulation predicts. Both matter, but the real-world numbers are the ones to prioritize.
For a deeper dive on each of these checks, what causes each one to fail, and how the platform you build on affects your scores: our page-speed health checks explained in detail →
8. When to fix vs. when to rebuild
Not every slow site can be meaningfully fixed with optimization. Some sites are built on foundations that generate the slowness structurally, and every fix is a workaround around the actual problem.
Sites where optimization works well: WordPress with too many plugins is usually fixable: trim the plugin stack, compress images, configure a caching plugin, upgrade PHP, and migrate to better hosting. Sites with purely image problems (lots of large unoptimized photos) are almost always fixable with just compression and format conversion. Sites on decent hosting with no caching configured see dramatic improvement once caching is set up.
Sites where fixing hits a wall: Wix sites with mobile scores below 50. The heavy code the platform loads on every page is non-negotiable: you cannot remove it, slim it down, or change how it loads. Squarespace is similar, though somewhat less severe. Heavy Elementor or Divi builds where the page builder's own styling and code account for most of the page's weight: you're fighting a system that's bulky on purpose because it needs to control how the page is built. Any site where a mobile PageSpeed score is still below 50 after shrinking all your photos and pushing every bit of non-essential code to load later means the foundation is the bottleneck, not a setting you can change.
The practical question is this: after the highest-impact fixes (shrinking your photos, pushing non-essential code to load later, page-saving, a hosting upgrade), where does the score land? If you're at 65, there's a clear path to 85+ with continued work. If you're at 38 after doing everything you can on the platform, you've hit the ceiling. A custom-built site starts from scratch and loads only what each page actually needs: no bulky framework weighing it down, no plugin junk, no styling for design pieces your site never uses. That's not a sales pitch; it's just what you get when the site is built clean from the ground up.
The economic case for a rebuild is strongest when the current site has ongoing monthly platform costs (builder subscriptions compound over years), when speed is actively affecting sales or ranking, or when the site needs features the current platform handles badly. A custom site at $2,800 is a one-time cost with no ongoing platform fee and no speed ceiling. Over three to five years, the math often favors the rebuild over endlessly fighting a platform that's holding you back.
Key takeaways
- Find the problem before fixing. Run Google PageSpeed Insights on mobile and let it rank your issues by impact. It tells you exactly what's loading and how much each thing is costing you.
- Photos first, always. Oversized photos are the leading cause of slow small business sites. Shrink every photo, use a modern format like WebP, tell the page each photo's size up front, and let lower photos load as visitors scroll. But never delay your main top photo — that wrecks your speed score.
- Push everything non-essential to load later. Analytics, chat widgets, marketing trackers, and social embeds don't need to load before a visitor can see your page. Let them load quietly in the background after the main content.
- Cheap shared hosting has a ceiling. If your site is still slow to start responding even after the page-saving fixes, your hosting is the constraint. Upgrading to a quality plan commonly makes the site respond 50–70% faster before any other change.
- Stop rebuilding pages on every visit. Without page-saving, your site rebuilds every page from scratch on each visit. With it, ready-made pages come back almost instantly. This is the single most impactful behind-the-scenes change for most WordPress sites.
- Serve your site from near each visitor. Cloudflare's free plan is plenty for most small business sites and takes under an hour to set up. It won't fix slow hosting, but it cuts loading time for people far from your server.
- Google's page-speed health checks are ranking factors. There are three: how fast your main content shows up, how quickly the page reacts to taps and clicks, and how much the page jumps around as it loads. Passing all three gives you a documented ranking advantage over sites that fail them. The first is most sensitive to photo size and hosting speed; the second to bloated code; the third to photos with no size set aside and content that pops in late.
- Your platform limits what fixing can achieve. If a mobile PageSpeed score is still below 50 after shrinking photos and pushing non-essential code to load later, you're at the platform's ceiling. At that point the question is whether to accept the limit or rebuild on a foundation with no built-in weight.