I measured 36 business websites in Sherbrooke

On 16 August 2026 I measured the homepage of 36 Sherbrooke businesses. Here is what they hand to somebody arriving for the first time.

An earlier version of this note rested on a sample I had put together by hand, with no public source behind it. Nobody could check how those sites had been picked, myself included. So I rebuilt the whole thing. The new sample is smaller, and it is worth far more, because you can reconstruct it yourself.

Where the sample comes from

The draw starts from the Répertoire des locaux et entreprises du territoire de Sherbrooke, published by Entreprendre Sherbrooke on Données Québec under a CC0 1.0 licence. The file holds 5,382 rows and downloads freely.

That register covers the territory of Sherbrooke, not the whole of Estrie. Every business measured here is a Sherbrooke business, and nothing on this page describes Magog, Coaticook or Granby.

Exclusions are applied to the full file, before the draw: 588 chains and franchises, 672 vacant units, 581 rows with no NEQ, 354 non-commercial premises, and 586 businesses outside the eight sectors kept. That leaves 2,601 eligible businesses. I drew 61 of them, taking every Nth row inside each sector, with no random seed and no judgement of mine about who made the list.

More than one business in four has no website at all

This is the finding I was not looking for, and it is the most useful thing on the page.

Of the 61 businesses drawn, 38 run a working website of their own. Each was searched by name, then by NEQ where the name was ambiguous. An address counted only if it answered and if the page named that particular business. No domain was ever guessed from a business name.

Of the other 23, 17 have no web presence of their own. Several live on a Facebook page. Some hold a dead domain that no longer resolves, or broken hosting that returns an error, or an online store still sitting at its default installation without a single product in it. The last 6 could not be settled: storefronts on a parent banner's domain, one domain whose secure connection no longer answers, and at least two live sites that only blocked automated checking.

So: at least one business in four, drawn from its own city's official register, has nothing to show the person searching for it by name. If you are weighing a new website against leaving yours alone, that figure matters to you more than any of the kilobytes below.

Two of the 38 drop out before measurement: one business whose own site announces that it has closed for good, and one franchised dealership. What remains is the 36 homepages this note is about.

What I measure, and how

For each site: one request for the page itself, then one request for every script, stylesheet and image the page declares. Everything is requested compressed, the way a browser does. Two measurement choices worth knowing before you read the figures: the HTML is counted at its decoded size, and files served from a third-party domain (external fonts, measurement scripts) are not counted, because they are not the site's to fix.

Images marked loading="lazy" are counted separately and excluded from the total. A browser does not fetch them before the visitor scrolls, and including them would make everyone look heavier than they are.

Any site I built or maintain is dropped automatically. That is the most important exclusion in the method: it removes any way for me to flatter the result.

This is not a full audit. I measure one homepage, from a single point on the network, on a single day. A fast homepage tells you nothing about the rest of a site.

The weight

The median site in the sample makes a visitor download 975 kB before they have moved.

The lightest quarter stays under 487 kB. The heaviest quarter starts at 2,997 kB. The lightest of the 36 is 62 kB; the heaviest is 87 MB.

• 17 of the 36 go past 1 MB on first load.
• 7 of the 36 go past 3 MB.
• 10 of the 36 stay under 500 kB.

The gap between the lightest and the heaviest is not a matter of fine tuning. These are two businesses in one city, serving the same sort of customer over the same network.

Why I am not turning this into seconds

An earlier version of this note divided weight by a throughput to produce seconds of downloading. The throughput was 1.6 Mbps down, the slow-connection assumption Lighthouse applies by default on mobile. It is a modelling convention, not a reading taken off anybody's network, and the result read like a stopwatch when it was a division.

So I am publishing the bytes. If you want the seconds, the division is yours to make, knowing what the throughput you put into it is worth.

Time to first response

The median is 182 milliseconds. That delay covers DNS, the connection and TLS, not just the server's own think time.

7 of the 36 go past 600 milliseconds. Touching the images does nothing to that. The usual causes are the hosting, a chain of redirects, or a page recomputed on every visit instead of being served from a cache.

Worth knowing if you re-run this yourself: the weights reproduce exactly between runs, and the response times do not. Response times depend on the network, mine as much as yours. You will get my kilobytes back. You will not get my milliseconds back.

What is missing from the markup

• 24 of the 36 serve images with no declared width or height. That is the most common cause of text jumping around while a page loads.
• 19 of the 36 carry images and defer none of them.
• 3 of the 36 are not on HTTPS.
• 3 of the 36 serve their page with no compression.
• 1 of the 36 has no mobile viewport tag.

The last three are rare, which is good news. The first two cover most of the sample, and both are fixed by an attribute on a tag.

The two fields Google shows

All 36 sites have a page title. Not one forgot it.

What they do have: 13 of the 36 carry a title over 60 characters, longer than a search result will show. 10 of the 36 have no description in their markup. And 12 of the 36 have no h1, meaning no main heading inside the page itself.

These fields take ten minutes to write. They are the only sentences Google shows to somebody choosing between you and the next result.

The 87 megabytes

The heaviest site in the sample belongs to a renovation contractor. Its homepage declares 876 image tags, not one of them lazy-loaded, pointing at 446 separate files.

It is a gallery of finished jobs, all of it, downloading in full before the visitor has finished looking at the first photo.

None of this is bad taste. Somebody wanted to show their work and the tool they were using said nothing about it. The same content, lazy-loaded and sized properly, would weigh a fraction of that. I did not rebuild the page to check, so I am not giving you a ratio.

Where my own site sits

Measured on 16 August 2026, with the same tool and in the same way as the other 36: 810 kB and 249 milliseconds.

17 of the 36 sites I measured are lighter than mine.

I am leaving that figure alone. Anyone publishing a study about page weight has to publish their own weight beside it, or the study stops being a measurement and becomes a sales pitch. And the figure will move: every image I add to my homepage costs me, in exactly the way it costs you.

I give these figures because they are checkable and someone will eventually check them. The command below works on my site as well as yours.

The limit you should know about

The register is an October 2024 snapshot. A business founded after that date could not be drawn, because it is not in the file. The measurements are current: taken on 16 August 2026, on the sites as they stood that day.

That distinction matters. The sampling frame is as old as it is; the measurements are not that old. The two age separately and have to be read separately.

How to check yours

One command, in a terminal:

curl -s -o /dev/null -w "%{size_download} bytes, %{time_starttransfer}s" -H "Accept-Encoding: br, gzip" https://webryk.ca

Swap the address for your own. It is written with mine because the command gives the same kind of result on both, and because you can start by checking what I claim about my own site.

The first number is the weight of the document alone, without images or code. The second is the time to first response, DNS and connection included. If it is above 0.6, look at the server before touching the images: hosting, redirects, no caching. No amount of image optimisation moves that number.

For the full picture, Google’s PageSpeed Insights is free.

What I would look at first

If your site is over 1 MB, open it and look at the largest image. Across the 17 sites in the sample that go over 1 MB, images make up more than half the weight on 13 of them. I did not re-measure those 17 after a fix, so I cannot tell you how many would have dropped back under the median. That is an hour of work, not a rebuild.

If you have no site at all, you are not an unusual case: that is where at least one business in four from this draw stands. The conversation is a different one, but it starts in the same place. Write to me anyway.

If you want me to look at yours, write to me. I will tell you what I see and where to start, with or without me.

Measured 16 August 2026, homepage only, from a single point on the network. Sampling frame: Répertoire des locaux et entreprises du territoire de Sherbrooke, published by Entreprendre Sherbrooke on Données Québec under a CC0 1.0 licence, an October 2024 snapshot. These are lab measurements: they describe nobody's actual visit and they do not replace field data. A sample of 36 sites, not a census, and every percentage is given with its denominator. Sites change: anyone re-running this in six months will not get exactly the same figures. The weights reproduce to the byte between runs; response times vary with the network. No business is named, and none of my own clients is in the sample.