Why Most Local Business Websites Are Slower Than They Should Be

Run a Wix or Squarespace home page through Chrome's network inspector and watch what gets shipped to a phone before the user sees a button. The total payload is routinely well above 10 megabytes once the platform runtime, fonts, tracking pixels, and uncompressed hero photo all land. That number sounds made up until you watch the network tab fill in real time. The page looks finished but the spinner keeps going, and on a four-year-old phone on cellular it can take six or seven seconds before anything is tappable. That same site loads in under a second on the owner's office Wi-Fi, which is exactly why nobody at the company has noticed.

This is the gap between how a local-business website feels to the people who built it and how it actually performs for the people you're trying to reach. According to the 2025 Web Almanac, only 48% of mobile pages on the web pass all three of Google's Core Web Vitals. For sites built on page builders like Wix, Squarespace, GoDaddy, or stock WordPress themes, the share of passing pages is much lower than that. The reasons aren't really about your design choices. They're about the stack underneath.

Why is my website slow if it looks simple?

Most modern site builders ship a single-page JavaScript application that has to download, parse, and run a large bundle of code in the browser before the page becomes usable. That's true even for a five-section home page that "looks simple." The visitor's phone is doing the work the server should have done at build time, and that work happens on every single visit, on every device, every time.

The technical name for this pattern is client-side hydration. The platform's marketing language calls it "modern" or "interactive," but in practice it means the visitor's browser becomes the rendering engine. A modest five-page service site running on a popular builder will routinely ship between two and five megabytes of JavaScript before any content paints. Add the chat widget, the analytics tags, the booking embed, the review carousel, and the Facebook pixel, and the total payload climbs fast.

Compare that to a statically pre-rendered site. The HTML is built once when the page is published, served from a CDN (Content Delivery Network, a global network of servers that holds copies of your page near every region) close to the visitor, and rendered before any JavaScript even loads. The same content, structured the same way, delivered without making the user's phone do the heavy lifting.

How site builders ship megabytes you never asked for

The 2025 Web Almanac puts the median mobile home page at 2.6 MB, up from 2.4 MB the year before. That's the median across the entire web. Page-builder sites typically run heavier than that median because of the platform runtime they ship on top of the actual content. DebugBear's website-builder performance review finds Squarespace sites averaging just 30 on mobile Lighthouse and Wix averaging 62, both below where modern static stacks land. The TruLight SLC site, when it lived on a hosted AI builder, was shipping 35.3 MB before its rebuild dropped that to 10 MB.

Here's where it comes from in a typical local-business site:

• The platform runtime. A page builder ships its own framework: layout engine, animation library, form handler, drag-and-drop scaffolding, A/B test harness. Most of it does nothing on a published page but it gets sent anyway.
• Unused fonts. Designer picks four typefaces. Builder ships every weight of each, plus italic variants, plus the language sets you don't need.
• Image dumps. A 4000-pixel hero photo from the photographer, dropped in unmodified. The browser scales it down for display but downloads the full file every visit.
• Third-party widgets. Chat tool, review carousel, booking embed, social-feed pull. Each is its own framework. Each phones home on every load.
• Tracking pixels. Google Tag Manager, Meta Pixel, TikTok pixel, Microsoft UET, Hotjar, FullStory. Eight of these on one page is normal. Each one delays interactivity.

None of these are individually catastrophic. The problem is they compound. A clean Next.js home page on Vercel lands at around 800 KB to 1 MB total. The same content on a stock Squarespace template typically weighs 6 to 8 MB. That's a 6x to 10x cellular-data tax on every visitor, every visit, paid by people you spent money to attract.

Do site speed and Google rankings actually correlate in 2026?

Yes, and the relationship has been confirmed by Google directly. Core Web Vitals (Google's three official speed metrics) became part of the search ranking signals in June 2021 and have stayed there. The current thresholds:

• LCP (Largest Contentful Paint). Under 2.5 seconds. This is how long it takes for the biggest visible thing on your page, usually a hero photo or main headline, to finish loading.
• INP (Interaction to Next Paint). Under 200 milliseconds. This is how long the page takes to visibly respond when someone taps a button.
• CLS (Cumulative Layout Shift). Under 0.1, on a unitless scale where smaller is better. This is how much stuff jumps around while the page is loading. You know when you go to tap a button and an ad loads and pushes it down right as you tap? That's CLS.

These are measured at the 75th percentile of real user visits, meaning out of every 100 people who load your page, 75 of them have to hit those numbers or better. A few fast loads on your office Wi-Fi don't paper over the slow ones in the field. Pages that fail one or more of these metrics are penalized in mobile-first ranking, which is Google's term for grading sites based on what a phone visitor sees rather than a desktop visitor. That's been the dominant ranking mode since Google fully completed the mobile-first index switch.

The complicating fact is that content quality still outranks speed. A genuinely better page on a slow site will often beat a thinner page on a fast one. But that's not really good news for local-business owners. The reason: in a category like "plumber Cottonwood Heights" or "roofing contractor Austin," your competitors usually have similar content quality. Your reviews are similar. Your service areas overlap. The tiebreaker becomes the technical layer, and the technical layer is where most local sites are hemorrhaging.

The Web Almanac data backs this up. Only 62% of mobile pages achieve a good LCP score in 2025, making it the hardest of the three Core Web Vitals to pass and the one most directly tied to how fast a site feels. If your LCP is over 2.5 seconds and your direct competitor's is under 1.5, that gap is showing up in your local pack rankings whether anyone has told you or not.

What "static" means and why it almost always wins

"Static" used to mean limited. Old static sites were a folder of HTML files with no real interactivity, no forms, no dynamic content. That's not what modern static means.

A modern static site is built once at publish time. The framework (Next.js, Astro, Remix in static mode) runs through every page in the project, fetches whatever data each one needs, and writes out finished HTML. That HTML gets pushed to a CDN, which is a global network of servers. When a visitor in Florida loads your Salt Lake City home page, the request hits the closest CDN node, often in their same metro, and the finished HTML comes back in under 50 milliseconds. No database query. No server process. No JavaScript execution required to see content.

The site can still have forms, interactivity, dynamic search, real-time chat, anything you want. Those features run in small targeted bundles that load only on the pages that need them, after the content has already painted. The rest of the site stays light.

This pattern is called the Jamstack, or sometimes just "modern static." Vercel, Netlify, and Cloudflare Pages are the dominant hosts. Next.js is the dominant framework. It's how Stripe, Notion, GitHub, OpenAI, and most modern SaaS marketing sites are built. It's also how every Front Door Digital build ships.

What can I do without rebuilding the whole site?

If your site lives on a builder you can't easily leave, the fixes that move the most speed for the least work are image compression, deferred third-party scripts, and removing whatever widgets aren't earning their keep. Most local-business sites can pull two to three seconds off their mobile load time with those three changes alone, without touching a line of code.

Specifically, here's what to look at:

1. Compress and resize every image. Hero images should be no larger than 1600 pixels wide. Service-page photos should be under 1200 pixels. Use WebP or AVIF format if your builder supports it. A single uncompressed photo can outweigh the rest of the page.
2. Defer or remove third-party scripts. The chat widget should load only after the user has been on the page for two seconds, or only when they click a button. The same applies to review carousels, social feeds, and booking embeds. Most builders have a "lazy load" or "delay" toggle buried in the settings.
3. Audit your tag stack. Open the page in Chrome DevTools, look at the network tab, and count the third-party requests. If you're seeing more than six, half of them probably aren't doing anything for you.
4. Replace stock fonts with system fonts. Or at minimum, drop the font weights you don't use. Each weight is roughly 50-100 KB.
5. Get a real CDN in front of your site. Cloudflare's free plan in front of a slow host frequently cuts your server's response time in half (the technical name for that wait is TTFB, Time To First Byte: how long the visitor's browser sits there after asking for the page before it gets the first byte back).

These fixes will help. They will not get a Wix site to compete with a Next.js site on speed. The platform itself is the ceiling. At some point you've optimized everything optimizable and you're still at 3.5 seconds because the framework runtime alone is 800 KB. That's when a rebuild starts to pay for itself.

The receipts: what a real rebuild looks like

I rebuilt my own permanent-lighting site (TruLight SLC) on Next.js. The site had been on Lovable.app, an AI website builder that's a typical example of that same client-side hydration pattern from earlier. It looked fine. It loaded fine on my MacBook. It was failing in the field.

Here's what changed when we rebuilt the same content on Next.js running on Vercel's edge:

Metric	Old (Lovable.app)	New (Next.js + Vercel)	Change
Total load time	4,155 ms	745 ms	5.6x faster
Time to first byte	585 ms	37 ms	15.8x faster
First contentful paint	1,920 ms	313 ms	6.1x faster
Largest contentful paint	1,920 ms	391 ms	4.9x faster
Page weight	35.3 MB	10.0 MB	3.5x lighter

Three cold runs each, same machine, same Playwright setup on both sites. The full breakdown lives at our TruLight SLC case study. Same content, same offers, same domain. The only thing that changed was the substrate underneath.

The result: the new site sits in Google's "good" Core Web Vitals band on every page. The old site sat in the "needs improvement" band on most. The architecture-level changes (static pre-rendering, edge serving, no client-side hydration) are exactly what Google rewards in mobile-first ranking, and they're the kind of changes you cannot make from inside a hosted page builder.

How to know if this applies to your site

You don't need an audit to find out. Open Google's free PageSpeed Insights, paste your home-page URL, and run the mobile test. The number that matters most is the LCP under "Core Web Vitals Assessment." If it's green and under 2.5 seconds, you're in good shape. If it's yellow or red, your site is in the same trap most local-business sites are.

Specifically, check:

• Mobile LCP. Anything over 2.5 seconds means the visitor sees a blank or partial page longer than they should.
• Total Blocking Time. The 2025 Web Almanac puts the median at 1,916 milliseconds, up 58% in a single year. If yours is over a second, your page is sitting frozen while JavaScript executes.
• Total page size. The "Diagnostics" section will tell you. Anything over 3 MB on mobile is a problem worth fixing.

Frequently asked questions

How fast does my site actually need to be?

Aim for an LCP under 1.5 seconds and a total mobile page weight under 2 MB. That's well inside Google's "good" thresholds and roughly twice as fast as the median local-business site. Visitors notice the difference, search engines reward it, and you stop losing leads to faster competitors who happen to rank above you for the same searches.

Will switching site builders (Wix to Squarespace, etc) fix this?

Usually no. Wix, Squarespace, GoDaddy, Weebly, and stock WordPress all share the same fundamental architecture: a hosted runtime that hydrates JavaScript in the browser on every page load. Their median performance numbers are within roughly 30% of each other. If you want a real step-change in speed, the move is off the page-builder category entirely, onto a statically rendered modern stack.

Why don't most agencies do this?

Two reasons. The first is that page builders are easier to sell and easier to staff because the skill bar is lower. The second is that most agencies make recurring revenue from monthly maintenance plans tied to slow platforms. A static Next.js site on Vercel needs roughly an hour of monthly attention. That's bad for a $500-a-month maintenance contract.

What's the fastest stack for a local-business site right now?

Next.js or Astro hosted on Vercel, Netlify, or Cloudflare Pages, with content stored in a managed database like Supabase or as flat files in the repo. That combination produces sub-second load times on cellular for most local-business sites, costs $0 to $20 a month at the traffic levels small businesses see, and ships every page as pre-rendered HTML served from the edge. It's the same stack the largest SaaS companies use for their marketing sites.

If you've gotten this far, you're probably already running PageSpeed on your own site in another tab. Good. The first step in fixing this is finding out where you actually stand, and the second is deciding whether the gap is wide enough to be worth a real rebuild. We can help with both.