Why your website is slow (and how to find out)
Common slowdowns stack: oversized photos dominate downloads; plugin/external features delay display; cheap shared hosting delays responses; uncached pages rebuild every visit; and absent nearby distribution makes distant visitors wait longer.
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 ranks delays and their cost, usually photos then code. Its loading sequence shows what appears first, dependencies, and longest waits. Focus on the ranked issues; technical expertise isn't necessary.
GTmetrix charts the largest, slowest resources. WebPageTest.org tests particular devices and connection speeds, including average mobile conditions like those PageSpeed Insights simulates.
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.
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: compress every photo. Squoosh (opens in new tab), TinyPNG, and ImageOptim cut 60–80% without visible loss. Reduce a 3 MB hero to 200–400 KB; decorative images needn't exceed that. This is the fastest, highest-return fix.
Step two: modern formats. WebP preserves JPEG quality at roughly 25–35% smaller sizes; a newer format saves 40–50% with slightly less device support. All major browsers, including Safari, support WebP. Ideally serve the newest supported format with fallbacks; simply converting to WebP also works.
Step three: size photos per device. Sending full-resolution images for narrow content can download three times what's visible. Provide at least phone and desktop versions; large-photo savings especially benefit mobile visitors.
Step four: declare photo dimensions. Width and height reserve space before images arrive. Without them, photos shift text/buttons and cause mistaken taps. Google measures and penalizes this jumping; reserved space prevents it.
Step five: defer lower photos until scrolling. Load offscreen images near their scroll position so pages become usable quickly. Always prioritize the main top photo: the largest visible element defines perceived speed. Accidentally deferring it ruins speed scores.
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.
Bloated page code that slows everything down
After photos, interactive/styling code and plugin/external additions cause the biggest delays. Platform integration makes them harder to fix: while heavy code runs, the page cannot draw or respond to taps.
Audit loading: five to ten WordPress plugins commonly fetch 15–30 code files. On plugin-heavy pages, 70–80% often goes unused, consuming download and processing time without benefit.
Defer nonessential code. Analytics, chat widgets, marketing trackers, and social embeds needn't block display or interaction. Load them quietly after main content appears for a free speed improvement.
Audit plugins. Overlapping WordPress plugins often load indiscriminately: contact forms on formless pages, homepage slideshows everywhere, backup code publicly. For each, weigh functionality against speed cost and ensure it loads only where needed.
Trim styling. Builders/premium themes ship huge files covering hundreds of unused design pieces. Load only styling needed for the page top immediately, deferring the rest so visitors see content instead of a blank screen.
Hand-coded pages load only their required code: no bulky framework startup, plugin management, or accumulating dead code. Clean-code speed benefits compound while pages remain as lean as their content permits.
Hosting and how fast your site responds
Initial server response sets the speed ceiling. If sending the page starts a second and a half after the request, other optimizations cannot make it feel fast; everything waits.
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 common culprit. Hundreds of sites share resources; neighbors' traffic, bad code, or bots squeeze yours. Leaving a $6/month plan commonly saves two to four tenths of a second before other changes. Quality shared hosting suits low traffic: A2 Hosting, SiteGround, or Kinsta for WordPress.
Check your host's PHP version. Newer versions run many tasks two to three times faster. Older shared plans often retain outdated software. Usually a control-panel click upgrades it without code changes; host support can do it in a minute.
Host near your audience. Seattle visitors wait longer for Dallas servers than Seattle ones. Nearby distribution reduces this effect, but the first response usually still comes from your origin server.
Stop rebuilding your pages on every visit
Without caching, every visit reruns code, queries the database, assembles, and sends even unchanged pages. Decent hosting handles a few dozen daily visitors; rebuilding wastes resources as traffic grows.
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.
WordPress needs page caching. WP Rocket combines saved pages, repeat-file caching, code deferral, and database cleanup. Free W3 Total Cache needs more configuration. LiteSpeed Cache excels on supporting hosts, including A2 Hosting. Skipping caching heavily penalizes speed.
Cache repeat-visit files. Tell devices to retain rarely-changing styles/photos for a year or more, avoiding redownloads and making return visits nearly instant. WordPress speed plugins automate this; custom sites need a server setting.
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.
Serving your site from near each visitor
Worldwide file-copy services distribute photos, styling, and other assets from servers near visitors. Seattle users accessing Atlanta-hosted sites save travel time on every file, noticeably speeding typical pages.
Cloudflare is the small-business default. Its usually sufficient free plan routes traffic globally, caches files near visitors, handles secure connections, and adds basic attack protection. Change domain settings to Cloudflare; setup 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.
Fix hosting first. Cloudflare distributes nearby files, but the origin still handles initial responses. Slow origins remain slow. Improve hosting and page caching, then add global distribution to reduce server load.
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.
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 visitor. Knowing what each one looks at tells you which fixes are most likely to move it.
Main-content appearance. Measure the largest visible photo, headline, or video against a two-and-a-half-second target. Image size, server response, and drawing blockers dominate. Prioritize the main photo, never defer it, and compress without visible loss. On decent hosting/reasonable connections it should arrive comfortably within two and a half seconds.
Tap/click response. Buttons, links, and menus should react within two-tenths of a second. Heavy code usually causes delays that feel broken and drive visitors away. Remove unused code and defer nonessential processing to free the page for interaction.
Layout stability. Unreserved photos, late ads, swapping fonts, and inserted content shift pages, moving buttons mid-tap. Declare image dimensions to reserve space and load fonts early to prevent text reflow.
PageSpeed Insights reports real visitor data and simulated lab scores. Google ranks using real-world results; worse field scores mean actual phones/connections underperform the simulation. Consider both, prioritizing field data.
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: my page-speed health checks explained in detail →
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.
Good optimization candidates: WordPress improves through plugin trimming, photo compression, caching, PHP upgrades, and better hosting. Image-only problems usually need compression/format conversion; decent uncached hosting improves dramatically with caching.
Platform limits: Wix's mandatory code resists optimization, especially below 50 mobile. Squarespace has similar, milder limits. Heavy Elementor/Divi builds carry unavoidable builder styles/code. Remaining below 50 after compressing images and deferring all nonessential code identifies a foundational bottleneck, not a setting.
After compression, deferral, caching, and hosting upgrades, assess results: 65 has a path to 85+; 38 after exhausting options signals a platform ceiling. Custom pages load only what's needed, without bulky frameworks, plugin leftovers, or unused design styling, because they're built cleanly from scratch.
Rebuild economics favor sites paying ongoing subscriptions, losing sales/rankings to speed, or needing poorly supported features. Custom at $2,800 is one-time, without platform fees or speed ceilings; over three to five years it often beats continued platform workarounds.
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.
Related guides
Common questions
How do I check how fast my website is?
Start with free Google PageSpeed Insights at pagespeed.web.dev: overall scores and ranked fixes align with Google's ranking checks. Test desktop/mobile; mobile usually scores much lower and determines ranking. GTmetrix explains bottlenecks; WebPageTest.org adds location/device testing.
Will speeding up my website improve my Google ranking?
Yes, twice. Google's content-display, interaction, and layout-stability checks are confirmed ranking factors; passing all three provides an edge, all else equal. Faster pages also retain visitors, increase browsing/conversions, and reduce immediate returns to search, which Google reads as dissatisfaction. Content remains most important, but speed breaks ties between otherwise equal local competitors.
Can I fix my Wix or Squarespace site's speed?
Partly: compress photos, limit external add-ons (especially blocking chat/marketing tools), and reduce custom fonts. You cannot control hosting or mandatory platform code. Wix carries substantial unavoidable weight; Squarespace is lighter but still bulky. Below 50 mobile after compression and add-on removal indicates a platform bottleneck.
Why does "how fast my site starts responding" matter so much?
Initial response measures request-to-first-server-data time. Google recommends under eight-tenths of a second; under two-tenths is excellent. Overloaded hosting, slow database queries, absent caching, or distance delay everything; over a second cannot feel fast despite optimized assets. Upgrade hosting, cache pages instead of rebuilding, or distribute content near visitors.
How much does website speed optimization cost?
Photo compression, caching, and code deferral often take hours. WordPress plugin/code audits take longer to evaluate, replace/work around, and test. Hosting moves take half to a full day. Wix or heavyweight WordPress builders impose limits; rebuilding may cost less over two-to-three years. Diagnose before budgeting fixes.
What's a good PageSpeed Insights score?
90+ is green; 50–89 orange means functional but improvable; below 50 is red and treated differently in rankings. Optimized desktops readily reach 90–100. Mobile networks, caches, and CPUs lower scores. Aim for 90+ desktop, 75+ mobile. Above 75 mobile is competitive; above 90 is rare for WordPress/builders. Mobile matters most because Google indexes/ranks that version.
Does serving my site from near each visitor help a small business?
Yes, primarily for distance, not small sites' modest traffic. Serving Seattle visitors Dallas-hosted files requires repeated long trips; worldwide nearby copies nearly eliminate that delay. Cloudflare's free plan suits most small sites, adds attack protection, and takes under an hour. Any public site benefits.
Why is my website fast on desktop but slow on mobile?
Phone code runs two to four times slower, on less reliable connections. PageSpeed Insights simulates average mobile, not new iPhone/home WiFi conditions. General fixes apply, but device-sized images and deferred heavy code best close the mobile-desktop gap.