The short answer. Same 152 Calgary small business sites from the State of AEO study, second audit. 124 came back with usable speed data. 71% are Slow or Painful. The median Calgary SMB homepage takes 736ms before the server starts responding, ships 33 script tags, and decodes to almost 200 KB of HTML before a single image loads. The slowest site we measured took 11.9 seconds just to send the first byte. The sites failing on AEO are mostly the same sites failing on speed. Whoever fixes both first wins the citation race and the conversion race in one weekend of work.
The State of AEO study answered "are Calgary small businesses set up to be cited by AI search?" The answer was no. But there's a more basic question that comes before that: when a customer does land on the page, how long does the page take to even start loading?
So we measured. Same 152 Calgary SMBs. Different lens.
Two things to be upfront about. This is not a full Lighthouse audit. We did not render JavaScript, we did not measure Largest Contentful Paint, we did not score Core Web Vitals end-to-end. What we measured is the structural debt that decides whether a page can be fast in the first place: time-to-first-byte, payload size, script bloat, compression, and whether the site has adopted the modern web practices that came standard a decade ago. If a site fails this audit, no amount of front-end finesse saves it. If it passes, that's necessary, not sufficient.
We hit the homepage of each of the 152 Calgary SMBs from the AEO study and measured: time-to-first-byte (TTFB), total HTML response time, transfer size, decoded HTML size, compression, protocol, and a handful of structural signals from the HTML itself (script tags, stylesheets, images, viewport meta, lazy-loading attributes, modern image formats, tracker presence, and the underlying website builder when detectable).
124 of the 152 returned a clean audit. The other 28 timed out, blocked our crawler, or returned errors we couldn't resolve. Every site was tested from the same network at the same time, with brotli and gzip explicitly accepted. The audit script is in our repo at tools/bulk-speed-audit.js and the per-site JSON results are at data/calgary-speed-audit/.
71%
of Calgary SMB homepages are Slow or Painful
Of the 124 sites we successfully audited, 88 are in the Slow or Painful tier. Only 8 are Fast. The median time-to-first-byte across the sample is 736ms, against Google's "good" Core Web Vitals threshold of 600ms or less. The 75th percentile is 1,572ms. The 95th percentile is 7,243ms, and the worst site we measured took 11.9 seconds just to begin sending a response.
For paid-ads context: every additional second of page load drops conversions roughly 7%. Every CPM you pay is the same whether the page loads in 1 second or 8. The conversion isn't.
The 124 sites broke down across the four speed tiers like this:
Translation: 88 of 124 Calgary small business homepages take longer than 800ms just to start responding, or ship more than 500 KB of HTML, or load more than 30 script tags. A lot of them check all three boxes.
The audit returned six findings worth calling out by name.
38% of Calgary SMBs have TTFB over 1 second. Customers see nothing for that full second. This is the best case for repeat visitors with warm DNS and warm connection. First-time visitors pay an extra 200 to 500 ms on top.
13% have TTFB over 3 seconds. This is "feels broken" territory. The user thinks the site is down and goes back to Google. Sixteen Calgary SMBs in our sample sit here.
Median 33 script tags on a homepage. Tracking scripts, chat widgets, analytics, A/B test suites, builder bloat. Each one is a network request that has to land before the page is interactive. 33% of audited sites load 50 or more scripts. The worst offender we found: 266 script tags on a single homepage.
Median 194 KB of decoded HTML. Just the HTML, before images, CSS, or JavaScript. A well-built SMB brochure homepage ships 50 to 100 KB of HTML. Eight Calgary sites in the sample decode to over 1 MB of HTML. One decodes to 2 MB. That's a marketing brochure, not a web app.
76% don't use modern image formats (WebP or AVIF). Modern formats are 30 to 50% smaller than JPEG at the same visual quality. Every site without them is shipping a third more image weight than it needs to, on every visit, forever.
7% have no compression at all. Brotli and gzip have been web standards for 15+ years. The 9 Calgary sites in our sample sending uncompressed bytes are paying for 3 to 5x more bandwidth than they should, and their customers are waiting that much longer on slow connections.
Of the 124 audited sites, 47% are on WordPress, 13% on Wix, 6% on Squarespace, 4% on Shopify, 28% on something custom or unrecognized, plus a handful on Duda. Conventional wisdom says WordPress is the slow one. The data says WordPress is in the middle of the pack.
The Squarespace number isn't a typo. Among the eight Calgary Squarespace sites in our sample, the median time-to-first-byte was 7.5 seconds. Even the fastest one in the group came in over 3 seconds. The sample is small, and the issue is almost certainly Squarespace's CDN routing to Canada rather than anything about the platform's design. But if you run a Calgary business and you're choosing a builder, this is part of the bill.
Wix sites ship the heaviest payloads in the data: median 171 KB of HTML transfer and 63 script tags. WordPress sites are slightly slower than custom builds but ship roughly the same HTML weight. Custom or unknown builds are the lightest by a wide margin (median 11 scripts, 16 KB transfer), because they're usually doing one thing instead of supporting a builder UI.
Here's the punch. The Calgary SMBs failing on speed are mostly the same ones failing on AEO.
Of the 10 sites in the Decent AEO tier (the top 8% of Calgary on AI-search readiness), 80% are also Slow or Painful on speed. Of the 68 sites in the Behind AEO tier, 82% are Slow or Painful. The only group with a meaningful fraction of fast sites is the Invisible AEO tier, and that's mostly because some Invisible-tier sites are tiny abandoned pages that fetch fast because there's nothing on them.
What this means in practice: most Calgary SMBs are losing customers twice. Once before the page loads (slow), and again after the page loads when AI engines refuse to cite it (invisible). Same operational team owns both problems. Both are fixable on the same site, in the same sprint, with the same money.
A slow homepage is a tax on every other marketing dollar you spend. Paid ads point at a page that takes 6 seconds to load and most of the click-through never sees the offer. SEO sends organic traffic to a page that visibly stalls and Google's ranking algorithm watches the dwell time go down. Email blasts drive opens to a landing page that breaks on mobile and the unsubscribe rate ticks up. The page is upstream of everything.
It compounds with AEO too. AI engines de-prioritize slow sites in their citation ranking. Google has been clear that Core Web Vitals are a ranking signal. ChatGPT, Perplexity, and Google AI Overviews all read web content and the slow ones get less attention. So a site that fails on speed makes the AEO problem worse, not just standalone-worse.
Three concrete moves, in order of leverage.
loading="lazy" to every image below the fold (one HTML attribute, no JS). Audit your script tags and remove anything you're not actively using (the median Calgary site loads 33; you almost certainly don't need 33). Those four together move a typical Calgary SMB site from Painful to OK in one afternoon.Sample. Same 152 Calgary small business website origins as the State of AEO study, scraped from 13 public Calgary industry listicles published in 2025 and 2026. Of 152 origins, 124 returned a clean speed audit. The other 28 failed at the network layer (DNS, timeout, connection refused, 5xx, or our crawler being blocked). The 18% failure rate is normal for public scraping at scale, and there's no reason to think it skews the sample one way or the other.
Audit tool. Custom Node script at tools/bulk-speed-audit.js. Each site was fetched from the same Calgary-region network, with brotli and gzip explicitly accepted, a 15-second timeout, and a concurrency of 10. TTFB was measured as the time from request open to the first response byte arriving. Total response time was TTFB plus body download. Structural metrics came from parsing the raw HTML, not from executing JavaScript or rendering the page. Builder detection is a simple fingerprint check against common script and class-name patterns (e.g. wp-content/ for WordPress, wixstatic.com for Wix).
Speed tier definitions. Fast = TTFB at most 400 ms AND HTML transfer at most 250 KB AND at most 15 script tags. OK = TTFB at most 800 ms AND HTML transfer at most 500 KB AND at most 30 script tags. Slow = above OK thresholds but TTFB at most 1,500 ms and HTML transfer at most 1 MB. Painful = anything beyond Slow. The thresholds are calibrated against Google's current "good" Core Web Vitals TTFB target (600 ms or less is good, 1,500 ms or less is needs improvement, above 1,500 ms is poor) and reasonable HTML and script budgets for a brochure homepage.
Limitations. This is not a full Lighthouse audit. We did not render the page, we did not measure Largest Contentful Paint or Cumulative Layout Shift or Interaction to Next Paint. The metrics we use are structural inputs to those scores, not the scores themselves. A site with a fast TTFB and a small HTML payload can still have a poor LCP if the hero image is unoptimized or the JavaScript blocks rendering. A site with a slow TTFB cannot have a fast Lighthouse score. So treat this study as identifying necessary conditions for fast pages, not sufficient ones.
Replication. The audit script is open source at tools/bulk-speed-audit.js. Run it against any URL list and you get the same JSON output format we used. Publish your analysis and send us the URL via the contact page. We'll link back from this methodology section.
We'll repeat this audit every year alongside the AEO study, and we're expanding both to the other markets we work in (London Canary Wharf, Lisbon) over the next two quarters. If you're a Calgary marketer, journalist, or business owner who wants the per-site speed JSON, ping us via the contact page and we'll share it.
If you want help moving your Calgary business out of the Slow or Painful tier, our web design and SEO and AEO retainers cover the four free fixes above, plus the deeper hosting, image pipeline, and script-bloat work that keeps a site fast as it grows.
We classified each site into one of four speed tiers using time-to-first-byte (TTFB), HTML transfer size, and script-tag count. Fast = TTFB at most 400ms, HTML transfer at most 250 KB, and at most 15 script tags. OK = TTFB at most 800ms, HTML transfer at most 500 KB, and at most 30 script tags. Slow and Painful are progressively worse. Of 124 successfully audited Calgary SMB sites, 6% are Fast, 23% are OK, 44% are Slow, and 27% are Painful. The thresholds are calibrated against Google's "good" Core Web Vitals targets for TTFB (under 600ms is good).
Time-to-first-byte is the number of milliseconds between the browser requesting the page and the server starting to send the response. It's pure server response time, before any rendering. Google's Core Web Vitals target for TTFB is 600ms or less for a good score. The median Calgary small business homepage is at 736ms. The 75th percentile is 1,572ms. The 95th percentile is 7,243ms. The slowest site we measured took 11.9 seconds just to start responding. Paid ads pointed at that page are paying for clicks that never see content.
Two reasons. First, the Google PageSpeed Insights API rate-limited our unkeyed bulk audit hard, and running 152 local Lighthouse runs would have meant roughly 4 hours of CPU and a Chrome instance per audit. Second, we wanted to isolate the structural debt that determines whether a page can be fast in the first place, separate from front-end render performance. Lighthouse measures the full picture. We measured the inputs: TTFB, payload size, script bloat, compression, modern web adoption. A site that fails this audit cannot have a fast Lighthouse score. A site that passes this audit can still have a slow Lighthouse score, depending on its rendering. So treat our findings as necessary but not sufficient.
Yes, dramatically. Median TTFB by builder across the 124 audited sites: custom or unknown 494ms, Shopify 735ms, WordPress 751ms, Duda 1,162ms, Wix 1,301ms, Squarespace 7,499ms. The Squarespace finding is striking but the sample is small (n=8). It is likely driven by Squarespace's CDN routing to Canada and is not a comment on the platform's design quality. WordPress, which conventional wisdom labels as slow, is actually in the middle of the pack.
Same 152 Calgary small business sites, two audits. The State of AEO measured whether sites are structurally set up to be cited by AI search. This study measured whether the same sites are fast enough for a customer to wait around. The findings overlap: 82% of the Behind-tier AEO sites are also Slow or Painful on speed. 80% of the Decent-tier AEO sites (the top 8% on AEO) are still Slow or Painful. The same operational team owns both problems, and both are fixable with the same effort.
Three things. First, run your site through PageSpeed Insights (free, 10 seconds). If your TTFB is over 800ms or your mobile performance score is under 70, you have work to do. Second, ship the four free fixes: enable brotli or gzip compression on your hosting, convert your hero images to WebP, add loading=lazy to below-the-fold images, and audit your script tags. Most Calgary SMBs are running 33+ scripts; you almost certainly do not need 33. Third, do the speed fix and the AEO fix together. Same site, same team, same weekend. Get both wins.
Where do you stand?
If your Calgary site is in the Slow or Painful tier, we fix speed and AEO together. Same weekend, same team, both wins.
Talk to us