What 97 Ottawa Small-business Websites Taught Us About Web-font Performance

I fix slow websites for a living. My agency is in Ottawa, and most of my clients are trades and home services: plumbers, electricians, HVAC, roofers, cleaners. Early in 2026 I got tired of guessing what slow means in this market, so I measured it.

The dataset

In March 2026 I ran Google PageSpeed mobile audits on 97 Ottawa-area service business websites. The set was sourced from public directories, so it represents businesses that list publicly rather than a formal census of the city. Every vertical I serve was in there: plumbing, electrical, HVAC, roofing, landscaping, painting, tree work, cleaning.

The median mobile score was 66 out of 100. Five sites finished at a perfect 100, and ten of the 97 reached 90 or better. At the other end, two sites scored 13 and 0. The median Largest Contentful Paint across the census was 6.3 seconds. Every score is published here: https://peakspire.ca/ottawa-website-benchmarks/

Two slices matter for this post. The five plumber homepages in the set scored 43, 46, 53, 67 and 73, a median of 53. And in October 2026 I re-ran the exercise for Ottawa pest control companies: seven local sites, mobile scores from 20 to 83, median 65, with two of the seven below 50.

A median of 66 is not a scandal, it is a description. Half of these sites load like it is 2015 on a phone.

What the waterfalls kept showing

One honest caveat first: the census tracks PageSpeed scores and opportunity flags, not font statistics specifically. I will not invent a percentage of sites with font sins. What I can tell you is what I see when I open the network waterfall on the slow half of this set, over and over.

Fonts hiding at the end of the waterfall. The browser has to fetch the HTML, fetch the stylesheet, parse the stylesheet, only then discover the WOFF2 URL, and fetch that too. That is two extra round trips on a phone network before real text renders. A preload link removes both.

Missing font-display descriptors. Plenty of hand-rolled @font-face rules set no font-display value at all. The default behavior holds text back while the font downloads. On a throttled mobile connection that is seconds of invisible headings staring back at a homeowner with a burst pipe.

The flash, handled badly. When the fallback stack does not match the web font's metrics, text renders twice: fallback first, then a visible shift when the real font lands. It is ugly, and it moves layout after someone has already started reading.

Remote Google Fonts where local WOFF2 would do. That is two more origins to resolve and negotiate TLS with, usually without a preconnect hint. There is also a 2022 German regional court ruling that embedding Google Fonts without consent can breach GDPR, which matters if you sell into Europe, or if you simply dislike shipping a visitor's IP address to a third party for a font you could self-host. WordPress themes that bundle their own CSS still point at fonts.googleapis.com more often than you would think.

To be clear about scale: in the audit exports, 50 of the 97 sites were flagged for unused JavaScript and 48 carried redirect chains. Fonts are rarely the whole problem. But they are the part that paints your words, they are cheap to fix, and they are usually fixed wrong.

The fix pattern

When I fix a site, fonts get four steps, in order.

1. Self-host the WOFF2 files you actually use. Subset to the weights and styles the design really calls for. Most service business sites need two files, maybe three.
2. Preload exactly those files. The preload URL must match the URL inside @font-face, with the crossorigin attribute set, or the browser downloads the font twice. And cap it: preload is a promise to spend bandwidth, and past a few files you are paying for nothing. I cap at four.
3. Declare font-display: swap on every @font-face rule. If a design truly cannot tolerate a swap flash, use optional and accept the fallback on cold loads. What you should not do is leave the descriptor out and let the browser decide to hide your text.
4. Measure before and after. Lab scores move from run to run. When I re-verified one pest control site in the October set, five runs scored 42, 44, 44, 44 and 52. Single-run numbers lie. Medians do not.

What I shipped

Doing this by hand on client after client got repetitive, so I packaged the pattern as a free WordPress plugin, Font Speed Fix. It is on GitHub: https://github.com/sirajahmadzai/font-speed-fix

It does four things. It scans your enqueued stylesheets for WOFF2 files hosted on your own domain and preloads them, capped at four. It adds font-display: swap to inline @font-face rules that are missing a descriptor, and deliberately touches nothing that already declares optional, block, fallback or auto. It can dequeue fonts.googleapis.com requests once you have finished self-hosting. And it can drop the dashicons stylesheet for logged-out visitors, a render-blocking request most themes never use on the front end.

Two deliberate limits say more about the plugin than the features do. It preloads only same-host fonts, because a cross-origin preload that does not match the stylesheet fetch wastes bandwidth instead of saving time. And it skips fonts declared inline in the HTML head, because I measured a 0.9 second LCP regression on one theme when preloading those: the browser already discovers inline declarations while parsing, so the preload was pure duplicate work. The plugin is tested on Twenty Twenty-Four, runs on PHP 7.4, changes only front-end output, and behaves alongside caching plugins like WP Rocket and LiteSpeed.

The honest conclusion

Web fonts are a real, recurring tax on Ottawa service sites, and the fix is boring, well understood, and about an hour of work. What the census actually taught me is that fonts sit inside a bigger problem. The median site in my market paints its main content in 6.3 seconds, half the set carries unused JavaScript, and roughly half lose time to redirect chains before anything renders at all. Fixing fonts on a site like that helps at the margins and feels like progress, but the sites scoring 13 and 0 need their page builders and plugin stacks dealt with first.

So measure, fix fonts properly, then keep going down the waterfall. If you want the full dataset, every score is published at https://peakspire.ca/ottawa-website-benchmarks/. If you want to see what slow mobile load times do to a local business's lead economics, I built a calculator for that: https://peakspire.ca/map-pack-value-calculator/. And if you just want the font fix, the plugin is free: https://github.com/sirajahmadzai/font-speed-fix