What slow website speed costs: 10 sites, measured
On 26 September 2026 we measured 10 live URLs from a server in Europe: two county councils, a credit union, a builders merchant, two hotel groups, and our own two sites at their apex and www hosts. Hosting did not make the slow pages slow. Files did. One current account page loads 18.9 MB of assets, and a single image on it is 8,953,498 bytes. What follows is the exact set of commands we ran, the cost in euros for a small Irish or UK business, and the work to do before anyone pays for a rebuild.
What was measured, and from where
Start with where the numbers came from. Every one of them was taken from a rented Hetzner cloud server in Germany, wired, no throttling, between 03:36 and 06:10 UTC on 26 September 2026. Chrome 126 on Linux was the user agent, unless we say differently. None of this is what your phone on Irish mobile data sees. It is what the server sends back, how long the server thinks before it sends, and how many bytes arrive.
The list: two county councils, a credit union, a builders merchant, two hotels, and our own two sites at both the apex and the www host. A piece that criticises other people's page weight should show its own numbers beside them.
| Site | Status | HTTP and TLS | TTFB median | TTFB worst of ten | HTML over the wire | Sub-resource bytes fetched |
|---|---|---|---|---|---|---|
| rennwick.com (apex) | 200 | HTTP/2, TLS 1.3 | 0.227 s | 0.702 s | 14,156 bytes | 438,307 bytes |
| www.rennwick.com | 301 to apex | HTTP/2, TLS 1.3 | 0.497 s | 10.469 s | 14,156 bytes | same page |
| factprovenance.org | 200 | HTTP/2, TLS 1.3 | 0.114 s | 0.149 s | 4,928 bytes | 0 files |
| www.factprovenance.org | 200, no redirect | HTTP/2, TLS 1.3 | 0.109 s | 0.136 s | 4,928 bytes | 0 files |
| sligo.ie (county council) | 301 then 200 | HTTP/2, TLS 1.3 | 1.229 s | 6.993 s | 48,736 bytes | 212,065 bytes of CSS |
| leitrimcoco.ie (county council) | 301 then 200 | HTTP/2, TLS 1.2 | 1.297 s | 6.751 s | 37,895 bytes | not crawled |
| sligocu.ie (credit union) | 301 then 200 | HTTP/2, TLS 1.3 | 0.345 s | 0.628 s | 19,145 bytes | 18,890,286 bytes |
| chadwicks.ie (builders merchant) | 200 | HTTP/2, TLS 1.3 | 0.224 s | 0.321 s | 173,692 bytes | 9,868,204 bytes |
| claytonhotels.com (hotel group) | 200 | HTTP/2, TLS 1.3 | 0.083 s | 0.125 s | 32,305 bytes | 9,928,532 bytes |
| sligoparkhotel.com (hotel) | 200 | HTTP/2, TLS 1.3 | 0.083 s | 0.842 s | 40,536 bytes | not crawled |
TTFB is time to first byte: the gap between asking for a page and the server answering, DNS lookup, TCP connect and TLS handshake included. Each URL got 10 runs, and the table carries the median and the worst. One run says nothing. Our own published host ran at a median of 0.497 seconds and a worst of 10.469 on the same machine, minutes apart. The timing columns came from this loop:
for i in $(seq 1 10); do curl -s -L -m 120 \
-A 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36' \
--compressed -o /dev/null \
-w '%{time_namelookup}|%{time_connect}|%{time_appconnect}|%{time_starttransfer}|%{time_total}|%{http_version}|%{num_redirects}|%{size_download}|%{url_effective}\n' \
https://www.chadwicks.ie/ ; doneByte counts hold still. A JPEG that is 8,953,498 bytes today is 8,953,498 bytes tomorrow. We fetched ours twice and compared the MD5 checksums to be sure. Read every timing below as a sample, and every byte count as a property of the file.
Field data does not sit next to the lab numbers in this piece. The PageSpeed Insights API returned HTTP 429 on 26 September 2026, quota exceeded for our key, so no field measurements from real visitors appear here. The commands are further down if you want to run the same method on a site you own. The approach sits behind every piece in the insights archive.
What makes a site slow, measured
Three separate causes were slowing these sites down, and each one wants a different fix. Sorting them apart is most of the work. "The site is slow" is a complaint, not a diagnosis.
The server is slow to think
Two county council sites sat for a long time before sending a byte. sligo.ie had a median time to first byte of 1.229 seconds, and one run took 6.993. leitrimcoco.ie managed 1.297 seconds at the median and 6.751 at worst. Both bounce the first request to another host, so the visitor pays for two connections before a page starts. What finally arrives is small: 48,736 bytes on sligo.ie, 37,895 on leitrimcoco.ie. That payload does not explain a 1.3 second median.
At the other end, claytonhotels.com answered in 83 milliseconds at the median and sligoparkhotel.com matched it. Both sit behind content delivery networks holding a copy near the visitor. Our own site, on Cloudflare, answered in 227 milliseconds at the apex. A small business cannot usually fix a 1.3 second server. Almost all of them can put a CDN in front of one, and on these numbers that is worth about a second per visit.
The user does the work
The home page of sligo.ie declared 108 stylesheets and 105 script files. We pulled 80 of the stylesheets, 212,065 bytes in total, four times the compressed HTML document itself. The largest of them was WordPress' own dashicons stylesheet at 35,721 bytes. Every file is a request, and a request costs a round trip before it costs a byte.
Theme and plugins do this. Hosting does not. Somebody installed what they needed one piece at a time, and nobody ever went back to count the requests.
The payload is heavy
Weight is the third cause, the biggest in our numbers, and the one a rebuild most often leaves alone. The credit union home page delivered 18,890,286 bytes of sub-resources in our crawl. chadwicks.ie delivered 9,868,204. claytonhotels.com delivered 9,928,532. Our own home page came to 438,307, and factprovenance.org came to 4,928 with no sub-resources at all.
A missing plugin does not make a 9 MB page. Someone uploaded photographs straight off a camera or out of a design file, and the site serves them at full size to everyone.
The single worst file we found: an 8.5 MB hero image
One JPEG holds most of the evidence in this study. It sits on the current account services page of the Sligo Credit Union site, which now redirects to the North West Credit Union site. The file is at https://www.sligocu.ie/media/ohfgxrom/currentaccountservices.jpg. We fetched it on 26 September 2026 at 03:36 and again at 04:26 UTC.
| What we asked for | What came back | Bytes | Pixels |
|---|---|---|---|
| Desktop user agent, default accept header | image/jpeg, status 200 | 8,953,498 | 5184 by 3456 |
| iPhone user agent (iOS 17.5 Safari), default accept header | image/jpeg, status 200 | 8,953,498 | 5184 by 3456 |
| Desktop user agent, accept header advertising WebP | image/webp, status 200 | 546,674 | 5184 by 3456 |
| iPhone user agent, accept header advertising WebP | image/webp, status 200 | 546,674 | 5184 by 3456 |
That table carries a claim we had to correct mid-work. The server does negotiate format. Advertise WebP, which Safari on an iPhone and Chrome both do, and the same image returns as a 546,674 byte WebP, 16.38 times smaller. So a phone is not being handed a deliberately crippled file. The narrower, worse reading for a business: there is no size variant at all. The WebP is 5184 by 3456 pixels, the same as the JPEG, because nobody resized the image for either a phone screen or a desktop screen.
A full width hero on a phone screen at 2x pixel density needs about 780 by 520 pixels. The file carries 17,915,904 pixels, 44 times what the screen can show. A browser that takes the JPEG downloads 8.54 MiB, 8.95 MB in decimal, to paint one photograph.
Both fetches of the JPEG returned the same MD5 checksum, 54e241bc6579161d41cb178540338322, so the byte count is stable while the host answers us. One wrinkle: a HEAD request to the same URL that morning reported a content-length of 8,954,186, 688 bytes more than the body we could download. Never quote a header as a file size. Use a GET and read the download size, which is what visitors receive.
Three more files from the same crawl make the pattern clear. One of them is a caution against easy conclusions.
- leitrimcoco.ie's councillors sports plan photograph is 1,969,005 bytes and 5760 by 3840 pixels, byte-identical to both user agents. A press photograph published at camera resolution, 2.25 times the linear width of a 2560 pixel display.
- A hero image on claytonhotels.com is 1,147,177 bytes, served 3840 pixels wide, with resize parameters in the URL (
f_auto,c_auto,w_3840,q_auto,g_auto). This one deserves an honest reading: the site runs an image CDN properly, with automatic format and quality selection, and 3840 pixels is still far too wide for a phone. The parameters work. The number picked for them does not. On sites that have already paid for their image platform, this is the most common version of the problem. - Our own home page carries three of these images, and s1-teardown-dfy-1024x1024.png is 69,195 bytes at 1024 by 1024. The contrast case: it is a PNG we could shrink further, and it is still two orders of magnitude away from the credit union file.
No mobile network was measured, so read the speeds below as illustrations and the byte counts as measured facts.
| Connection speed (assumed) | Time to transfer 8,953,498 bytes | Same transfer as WebP, 546,674 bytes |
|---|---|---|
| 25 Mbit/s | 2.9 seconds | 0.2 seconds |
| 10 Mbit/s | 7.2 seconds | 0.4 seconds |
| 5 Mbit/s | 14.3 seconds | 0.9 seconds |
| 2 Mbit/s | 35.8 seconds | 2.2 seconds |
An image that costs 7.2 seconds of pure transfer sits at the top of the page, and everything else queues behind it, because a browser will not paint around a hole. Note which row you are in. On the office fibre where a business owner checks their own site, the same file arrives in under three seconds and looks fine. The problem survives for years on that gap.
First load and repeat visits: what your cache headers decide
A page weight number describes the first visit only. The second visit is a separate event, and response headers decide it, headers most business owners have never opened. Here is what these 10 sites send for their HTML.
| Site | Cache-Control on the HTML | Validators | What a repeat visitor gets |
|---|---|---|---|
| chadwicks.ie | max-age=0, must-revalidate, no-cache, no-store |
none seen, Age 0 | A full re-download of a 2.71 MB HTML document, then the 80 images |
| factprovenance.org | no-store |
none | A re-download every time, 12,441 bytes uncompressed |
| sligo.ie | no Cache-Control sent | none seen | Whatever the browser decides on its own, which you do not control |
| sligoparkhotel.com | no Cache-Control sent | none seen | Same as above, Age 0 |
| leitrimcoco.ie | private |
none seen | The browser may keep it, but with no freshness lifetime it will usually revalidate |
| sligocu.ie | private |
none seen | Same as leitrimcoco.ie |
| claytonhotels.com | none seen on the HTML | ETag W/"309ec469786f4664d6371107a1e0a3cc", Last-Modified 25 September 2026 09:05:57 GMT, Age 69,833 |
The CDN held the page for 19.4 hours and can answer a revalidation cheaply |
| rennwick.com | no Cache-Control sent | none seen | Our own gap, noted here rather than buried |
The chadwicks.ie row is where the money goes. That site sends no-store, which tells every browser and every cache to keep nothing. The HTML is 2,714,457 bytes uncompressed and 173,692 with brotli, so the first visit is fine. The second pays those bytes again, plus the server rebuilding the page, plus the images. One command shows the header:
curl -s -L -D - -o /dev/null https://www.chadwicks.ie/ | grep -i 'cache-control\|etag\|last-modified\|age:'The claytonhotels.com row shows the good pattern: an ETag and a Last-Modified date let the browser ask whether anything changed and take a short answer instead of the whole document. Its Age header of 69,833 seconds shows the CDN held that HTML for 19.4 hours. We did not test the 304 revalidation response itself, so we report that the mechanism exists, not that we watched it work. The MDN guide to HTTP caching is the plainest explanation we have found.
The cheapest fix here is caching the static files. A long max-age on images, stylesheets and fonts means the 8.5 MB photograph is downloaded once per visitor, then read from their own device. Switching one header does not fix a 9.87 MB page. Nobody should believe that claim from anyone.
Images and fonts: where the bytes actually are
We parsed each home page, pulled out every image, stylesheet, script and font URL, and fetched them one at a time. The bytes were made of this.
| Site | Images | Fonts | CSS | JavaScript | Total fetched |
|---|---|---|---|---|---|
| chadwicks.ie | 9,868,204 bytes in 80 files | none fetched | none fetched | none fetched | 9,868,204 bytes |
| claytonhotels.com | 9,469,457 bytes in 18 files | 53,800 bytes in 2 files | 20,168 bytes in 4 files | 385,107 bytes in 22 files | 9,928,532 bytes |
| sligocu.ie | 9,471,569 bytes in 9 files | 8,112,250 bytes in 24 files | 253,029 bytes in 6 files | 1,053,438 bytes in 17 files | 18,890,286 bytes |
| sligo.ie | no image tags in the HTML | none declared | 212,065 bytes in 80 files | none fetched | 212,065 bytes |
| rennwick.com | 198,786 bytes in 3 files | 226,556 bytes in 10 files | 12,241 bytes in 2 files | 724 bytes in 1 file | 438,307 bytes |
| factprovenance.org | none | none | none | none | 0 bytes |
On chadwicks.ie, images are 100% of the sub-resource weight we fetched. On claytonhotels.com they are 95.4%. On the credit union site, images are 50.1% and fonts 42.9%. On our own home page, fonts are the largest group at 226,556 bytes, 51.7% of the page, more than our images. Nobody is immune, the people writing this included. Three findings, three fixes.
The same banner twice
chadwicks.ie serves 250906-CH-Autumn-1566x424.png and 250906-CH-Autumn-1566x424_1.png at 1,196,881 bytes each. The same banner uploaded twice and referenced twice, 2,393,762 bytes together, 24.3% of all the image weight we fetched from that page. Delete one file.
A giant PNG where a JPEG would do
The largest single file on chadwicks.ie is Chadwicks-Rapid-Build-Solution.png at 1,738,751 bytes. PNG is lossless, so it suits a logo with sharp edges, not a photographic banner with text on it, where a quality 80 JPEG comes in at a fifth to a tenth of the size. A HEAD request to that URL returns no content-length at all, so we measured it with a GET and read the download size.
Fonts as the hidden half
The credit union site declares 89 font URLs, and our crawl pulled 24 files totalling 8,112,250 bytes, all served as TTF, including single files of 1,269,336 and 1,267,308 bytes for two Font Awesome Pro icon families. Two qualifications. Our fetcher asked for the TTF sources the stylesheet offers, and a browser supporting WOFF2 would ask for the smaller WOFF2 source instead, so 8.1 MB is the worst case the server will serve, not a guaranteed figure for every visitor. And a page declaring 89 font URLs has a problem whichever format wins. Our own equivalent is smaller and real: 10 WOFF2 files, 226,556 bytes, one of which took 5.1 seconds to first byte.
Here the cheap compression win stops. Text compresses hard: chadwicks.ie's HTML falls from 2,714,457 bytes to 173,692 with brotli, 15.63 times, and the councils and the credit union get 5.18 to 6.22 times with gzip. Images and fonts are already compressed, so a 1.7 MB PNG stays a 1.7 MB PNG. The MDN page on HTTP compression explains why your host's compression setting never shrank your photographs.
| Site (HTML document) | Encoding served | Bytes transferred | Bytes uncompressed | Ratio |
|---|---|---|---|---|
| chadwicks.ie | brotli | 173,692 | 2,714,457 | 15.63 times |
| claytonhotels.com | brotli | 32,305 | 242,904 | 7.52 times |
| leitrimcoco.ie | gzip | 37,895 | 235,573 | 6.22 times |
| sligocu.ie | gzip | 19,145 | 105,625 | 5.52 times |
| sligo.ie | gzip | 48,736 | 252,498 | 5.18 times |
| rennwick.com | zstd | 14,156 | 50,699 | 3.58 times |
| sligoparkhotel.com | gzip | 40,536 | 121,626 | 3.00 times |
| factprovenance.org | zstd | 4,928 | 12,441 | 2.52 times |
Latency and bandwidth are different problems
Most businesses read a slow site as a bandwidth problem and buy a bigger pipe. Put the two ends of our table side by side. claytonhotels.com answered in 83 milliseconds and then sent 9.93 MB. sligo.ie took 1.229 seconds to answer and then sent about 50 KB of HTML plus 212,065 bytes of stylesheets. One site waits on its server, the other on its files. A faster visitor connection helps the second a little, the first not at all, and a more expensive hosting plan fixes neither.
The round trip is the unit that matters. On our own apex host, the median DNS lookup was 27 milliseconds, TCP connect 50, the TLS handshake 84, so 161 milliseconds passed before the server was asked for a page. Every new connection pays that floor. Request count matters for the same reason: 80 stylesheets at 100 milliseconds each is eight seconds of queueing before anything renders. Nine of the 10 sites used TLS 1.3, one round trip. leitrimcoco.ie still used TLS 1.2, two round trips, on top of its 1.3 second answer.
Google publishes the thresholds to measure against. Largest Contentful Paint, when the biggest element in the viewport finishes painting, should be 2.5 seconds or less, and is poor above 4.0. Interaction to Next Paint should be 200 milliseconds or less, and is poor above 500. Cumulative Layout Shift should be 0.1 or less, and is poor above 0.25. All three are assessed at the 75th percentile of real page views, mobile and desktop separately. The web.dev page on Core Web Vitals carries the current numbers, read 26 September 2026, and Google Search Central's Core Web Vitals guidance states them the same way for search.
Set that beside our measurements. Time to first byte is one component of Largest Contentful Paint. After the first byte, the browser still has to discover the hero image, download it and paint it. A site with a 1.229 second median has spent half the 2.5 second good budget before its largest image is requested, and an 8,953,498 byte image spends the budget several times over. Bytes and first byte times we can measure. A Largest Contentful Paint score needs a browser and a network we did not run.
In the order the measurements support: put a CDN in front of a slow server, cut the requests, compress the text, and stop expecting a bandwidth upgrade to fix any of it.
What a rebuild fixes, and what it does not
This article's position, and our working conclusion, is that a rebuild is the right answer far less often than it is sold, and that the problems we measured survive rewrites almost untouched. The two heaviest pages here are not badly built sites. claytonhotels.com serves brotli-compressed HTML from AmazonS3 through an image CDN with automatic format and quality selection, and still sends 9.93 MB because its CDN parameters ask for 3840 pixel widths. chadwicks.ie sits on Cloudflare, compresses its HTML 15.63 times, and still sends 9.87 MB of images because a banner went up twice and a PNG did a JPEG's job. Both already have the infrastructure a rebuild would sell you.
A rebuild replaces the container. Your content goes into a new theme or platform, and in our experience the images, fonts, icons and third-party scripts come across unchanged. Moving a site is a migration, and nobody re-encodes 80 images during one. The www redirect that costs leitrimcoco.ie and sligo.ie an extra connection is a hosting setting. The no-store header on chadwicks.ie is one line of configuration.
What a rebuild does genuinely fix is a shorter list, and a real one:
- A theme or template that cannot express the layout you need, so each small change turns into a workaround.
- A plugin or module stack beyond pruning, where removing one thing breaks two others.
- A platform that has gone out of support, or cannot run a modern caching layer at all.
- Security and maintenance debt that costs you money every month in patches and fixes.
- An admin experience so awkward that you have stopped updating the site. The real gap there is content, and the platform takes the blame.
- Structural accessibility failures that live in the markup and not the stylesheet, where headings are used for styling and the page order makes no sense to a screen reader.
If two or more of those describe your situation, treat the rebuild as maintenance. If none do, and your pages take a long time to appear on a phone, a rebuild buys the same problem in a new theme at a higher price.
When a rebuild is the right call
This is the decision list we would use, with a test for each item, so you can run it on your own site this week. A rebuild is the right call when two or more of these are true.
| Condition | How to test it |
|---|---|
| The platform is out of support or the vendor has stopped updating it | Check the last release date on the vendor's site. If it is more than 18 months old and the site is not on a maintained platform, patching is a dead end. |
| You cannot add a caching or CDN layer | If your host has no CDN option and no page cache plugin, the slow-answer problem from the council sites is unfixable inside the current setup. |
| More than half your stylesheet and script requests come from plugins or modules you no longer use | Open the browser's network panel, filter by CSS and JS, and count how many filenames you cannot justify. sligo.ie declares 108 stylesheets. If your number is over 40, the stack is the problem. |
| The markup structure blocks the layout you need | Try to move a section above another with CSS only. If it cannot be done without editing templates you cannot safely edit, the structure is the constraint. |
| Security fixes take more time each month than content updates | Count your admin hours for the last three months. If patching wins, the platform is costing you money. |
| Nobody can edit the site without breaking it | If the answer to "can you update your own prices" is no, the platform has failed its main job. |
| You have done the cheap fixes and the page still fails | Re-measure after the fixes below. If the largest image is under 200 KB, the requests are under 40, the text is compressed and cached, and the page still takes more than three seconds to first byte, the server and the platform are the constraint. |
One thing is not on that list: the design looks dated. A dated design can be repainted inside the existing platform for a fraction of a rebuild price, and nothing in our measurements says your visitors care about your colour palette. If the real reason for a rebuild is that you are embarrassed by the look, say so and price it as a design job. Bundle the two and you pay a rebuild price and keep an 8.5 MB hero image.
A 30 day fix order for a one person business
This is the order we would work in if the site were ours and nobody else was around. Smallest first, free first, and none of it needs a developer.
Days 1 to 3: measure, record it, change nothing
Point the commands in the next section at your home page and your three busiest pages. Put the results in a file with the date on it: page weight, the five largest files, time to first byte, the Cache-Control header, and whether the HTML arrives compressed. Then take your own phone, switch the wifi off, open the site, and time how long the home page takes to become usable.
Days 4 to 10: the images
Sort the files on your server by size and work down the list. Delete the duplicate uploads, 2,393,762 bytes of them on one site here. Re-save anything photographic as a JPEG at quality 80, or WebP where your platform supports it, worth 16.38 times on the file we measured. Resize to what the screen shows. A full width phone hero at 2x density needs about 780 pixels, not 5184. Set width and height on every image so the page stops jumping as it loads.
Days 11 to 17: fonts, stylesheets and scripts
Count your font files. Ten WOFF2 files costing 226,556 bytes is our own number, and we are cutting it. 24 files costing 8,112,250 bytes is the worst case we measured. Keep the weights you use, drop the icon families you do not. Count stylesheets and scripts the same way. If your site declares more than 40, most of them are plugin leftovers, and switching an unused plugin off is a performance fix, not housekeeping.
Days 18 to 24: compression, caching and a CDN
Turn on brotli if your host offers it, gzip if it does not. That setting is worth a factor of 15.63 on the HTML we measured. Set long cache lifetimes on images, stylesheets and fonts, and an ETag or Last-Modified date on your HTML so repeat visitors get short answers. Remove no-store from anything you want cached, having first found out why it was there.
Days 25 to 30: re-measure, then decide about the rebuild
Run the day one commands a second time and put the numbers next to the first run. If the page weight has halved and the site feels different on a phone, do not rebuild. Put that money into something that produces enquiries. Do all of this and still see a slow server, an unmaintainable platform or a structure you cannot change, and you have the evidence a rebuild is right and a specification to hold an agency to. Ask any agency for the page weight of the last site they built, measured the same way.
How to measure your own site for free
Every tool here is one you already have. If you have a laptop you have a terminal, and if you do not, your hosting control panel has an equivalent.
# 1. Ten runs: median and worst time to first byte, transfer size, redirects, HTTP version
for i in $(seq 1 10); do curl -s -L -o /dev/null \
-w '%{time_namelookup}|%{time_connect}|%{time_appconnect}|%{time_starttransfer}|%{time_total}|%{http_version}|%{num_redirects}|%{size_download}\n' \
https://your-site.ie/ ; done
# 2. What the HTML weighs compressed, and how much the compression saved
curl -s -L --compressed -o /dev/null -w 'compressed %{size_download}\n' https://your-site.ie/
curl -s -L -H 'Accept-Encoding: identity' -o /dev/null -w 'uncompressed %{size_download}\n' https://your-site.ie/
# 3. The headers that decide repeat visits
curl -s -L -D - -o /dev/null https://your-site.ie/ | grep -i 'cache-control\|etag\|last-modified\|age:\|content-encoding'
# 4. How big one file really is, measured as bytes downloaded (never trust a HEAD header)
curl -s -L -o /dev/null -w '%{size_download} bytes, %{content_type}\n' https://your-site.ie/path/to/hero.jpg
# 5. What a phone gets, as opposed to your laptop
curl -s -L -o /dev/null -w '%{size_download} %{content_type}\n' \
-A 'Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1' \
-H 'Accept: image/avif,image/webp,*/*;q=0.8' https://your-site.ie/path/to/hero.jpgCommand 5 is the one that caught us. Send it once with the accept header shown and once with a plain -H 'Accept: */*', then compare the byte counts. If they differ a lot, as they did by 16.38 times on the credit union image, you have found a saving that costs nothing to switch on. Command 4 builds the other habit worth having: a header can lie, a download cannot. One URL here has a HEAD response reporting 688 bytes more than the file we could download, and we could not explain it, so we published the downloaded size.
For a second opinion, use the free public tools, knowing what each one is. Google PageSpeed Insights runs a lab test in a throttled browser and, where it has enough data for your origin, shows field data from real visitors. Lighthouse in the browser's developer tools runs the same lab test and lets you throttle the connection and pick a mobile device profile, the most useful five minutes you can spend on this. WebPageTest runs from an Irish or UK location. The browser network panel filtered by size gives you your largest files.
The field data these tools show comes from the Chrome UX Report, which reports only on origins with enough real visitors to be statistically usable. Many small business sites have no field data at all, so the Chrome UX Report documentation is worth reading once, and this article is a lab study.
The thresholds you are measuring against
| Metric | What it measures | Good | Poor | Assessed on |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | When the biggest element in the viewport finishes painting | 2.5 seconds or less | Above 4.0 seconds | The 75th percentile of real page views, mobile and desktop separately |
| Interaction to Next Paint (INP) | How quickly the page responds to taps and clicks | 200 milliseconds or less | Above 500 milliseconds | Same |
| Cumulative Layout Shift (CLS) | How much the page moves around while loading | 0.1 or less | Above 0.25 | Same |
The thresholds come from web.dev's Core Web Vitals documentation, read 26 September 2026, and stated the same way in Google Search Central's guidance. Two notes on using them. These are field thresholds assessed at the 75th percentile, so one test on a fast laptop does not tell you whether your site passes. And the Search Central page on page experience says these signals are a small part of a larger ranking picture. Treat speed as a conversion and cost issue first, a search issue second. We do.
What a slow site costs: one cost model
Here is the model, every assumption written out so you can replace ours with yours. It is arithmetic on an assumption set, not a measurement of anyone's business. Google's guidance on why speed matters establishes that slow pages lose users. It does not tell you how much of your trade a slower page costs, and neither can we.
| Assumption | Value we used | Where it comes from |
|---|---|---|
| Visits per month | 1,000 | An assumption, chosen because it is a small business number. Yours may be 200 or 20,000. |
| Share of visits on a phone | 70% | An assumption, in line with what most small business sites see. 700 mobile visits in this model. |
| Visits that turn into an enquiry | 4% | An assumption. 28 enquiries a month before any speed effect. |
| Value of one enquiry | EUR 150 | An assumption, stated as an example. A hotel booking, a boiler service, a bathroom survey and a legal consultation are not the same number, which is why the sensitivity table below exists. |
| Share of mobile visits lost to a slow first load | 10%, 20%, 40% | A scenario, not a measurement. We cannot measure your abandonment, and anyone who quotes you a precise loss figure for your business is guessing. |
The middle scenario, worked through: 1,000 visits multiplied by 70% mobile gives 700 mobile visits. Lose 20% of those to a slow first load and 140 visits are gone. At a 4% enquiry rate those visits would have produced 5.6 enquiries, and at EUR 150 each that is EUR 840 a month, or EUR 10,080 a year.
| Scenario | Visits lost per month | Cost per month | Cost per year |
|---|---|---|---|
| 10% of mobile visits lost | 70 | EUR 420 | EUR 5,040 |
| 20% of mobile visits lost | 140 | EUR 840 | EUR 10,080 |
| 40% of mobile visits lost | 280 | EUR 1,680 | EUR 20,160 |
Now the part that decides the figure: what changes if we were wrong. Keep the 20% loss, change one assumption at a time.
| Change | Cost per month | Cost per year |
|---|---|---|
| Enquiry worth EUR 400 instead of EUR 150 | EUR 2,240 | EUR 26,880 |
| Enquiry worth EUR 60 instead of EUR 150 | EUR 336 | EUR 4,032 |
| 3,000 visits a month instead of 1,000 | EUR 2,520 | EUR 30,240 |
| 250 visits a month instead of 1,000 | EUR 210 | EUR 2,520 |
What survives every version of this table is that the figure deserves a look. What does not survive is a hard number for your business, and you should distrust anyone who gives you one without asking for the four inputs above.
Two more pieces of arithmetic rest on measured bytes, not assumed behaviour. The credit union hero is 8,953,498 bytes, so 700 mobile visitors loading it once each makes the site push 6.27 GB of mobile data in a month. ComReg's Quarterly Key Data Report for Q1 2026 puts average mobile data use at 21 GB per subscriber per month, which gives the scale: one image on one page moves about a third of a single subscriber's whole monthly allowance. The per-visitor figure is smaller, 8.95 MB each, about 0.04% of a 21 GB allowance, which nobody would notice on its own. What they do notice is the time: 7.2 seconds each at 10 Mbit/s, and 1.4 hours of combined waiting across 700 visits.
What we do not know, and what these numbers cannot prove
These are the limits of the measurements, and they matter more than any single figure above.
- No field data. Every timing here is a lab-style measurement from one server. Google's thresholds are written for field data at the 75th percentile of real visits, and lab and field differ because real phones, real radio conditions and real caching behave differently from a wired server in Germany. The PageSpeed Insights API returned HTTP 429, quota exceeded, on 26 September 2026, so we published no field numbers at all.
- No rendered page. We measured time to first byte and bytes transferred. Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift for these sites went unmeasured, because that needs a real browser on a throttled connection. Our statement that a 1.229 second first byte eats half the LCP budget is reasoning from the published definition, not a measurement we made.
- One vantage point, no mobile network. Every number comes from a single wired host. Mobile networks add latency and variability we have not quantified, and a second vantage point could move the timing columns by seconds. The byte columns would hold.
- Timing is noisy, and we kept the noise. The worst of 10 runs against our own published host was 10.469 seconds, against a median of 0.497. We left that in the table instead of dropping it, because a reader deserves to see how much a single run can vary.
- Our strongest claim needed correcting during the work. The 8,953,498 byte hero is not always the file a phone receives. A browser that advertises WebP gets 546,674 bytes. So the claim that mobile is served a desktop-only file is too strong, and the claim that holds is narrower: there is no size variant, because the WebP is still 5184 by 3456 pixels for a screen that needs about 780.
- One site stopped answering us mid-morning. At 06:05 UTC on 26 September 2026 the credit union's destination host resolved in DNS in 24 to 42 milliseconds but never completed a TCP connection, on the home page and on the image, timing out at 15 seconds with status 000. A third-party fetch service retrieved the same home page with a HTTP 200 and 59,359 bytes of text in that window, so the site was up and the failure sat on our path to it. Anyone re-running our image commands may not reproduce the byte counts until that path recovers.
- Some asset totals are lower bounds. Our crawler fetched 9 of the 19 images declared on the credit union home page, so 9,471,569 bytes is a floor. It requested the TTF font sources the stylesheet offers, and a browser supporting WOFF2 would take the smaller files instead, so 8,112,250 bytes of fonts is a ceiling, while the 89 declared font URLs are certainly true.
- An unexplained 688 bytes. A HEAD request to the hero reported a content-length 688 bytes larger than the file we could download. We could not chase it before the host stopped answering. Header values and transferred bytes are different things.
- These sites will change. Every number carries the date 26 September 2026. Files get deleted and headers get edited, so a reader checking in a year may find some of this no longer reproduces.
- We cannot prove a single euro of lost trade. The cost model is arithmetic on stated assumptions. What we prove is that the bytes exist, that they are large, and that they arrive late. What would change our mind: field data for these origins showing the pages pass the published thresholds, or a controlled test showing page weight made no difference to enquiries.
What this means for you
In the order we would do them, smallest and cheapest first, and all of it free except where stated:
- Put your site on your phone with the wifi off and time how long the home page takes to become usable. Thirty seconds of work, and the number that matters most.
- Run the five commands above and put the results in a file with the date.
- Find your five largest files and delete the duplicates. One site in this study wastes 2,393,762 bytes on the same banner, twice.
- Resize and re-save anything photographic. A phone-sized hero needs about 780 pixels wide, not 5184.
- Turn on brotli or gzip. Set long cache lifetimes on images, stylesheets and fonts.
- Count your requests and font files, then switch off every plugin and weight you do not use.
- Re-measure and compare. Only then judge whether the platform itself is the problem.
If you would rather have someone else run the measurements, we do that as a free teardown, and what we do is fix the site you already have instead of selling you a replacement. To do it yourself, the shop has a teardown guide and audit products, priced plainly. Either way, contact us with your URL and we will tell you which of the numbers above applies to your site. If public data interests you more than websites, the same measuring habit is on show in our study of Irish public contracts from 2023 to 2025: 25,151 tenders and awards and EUR 79.7bn awarded as published.
This article describes measurements we took on public websites on 26 September 2026. None of it is professional advice for your business. Your site is not these sites, and the numbers move.
Sources and references
- web.dev, Core Web Vitals, read 26 September 2026. Used for the LCP, INP and CLS thresholds, the 75th percentile rule, and the split between mobile and desktop assessments.
- web.dev, Why does speed matter?, read 26 September 2026. The basis for the claim that slow pages lose users, the assumption the cost model rests on.
- Google Search Central, Core Web Vitals, read 26 September 2026. Used for the same thresholds, applied to search.
- Google Search Central, Page experience, read 26 September 2026. The source for the statement that these signals are one small input among many, and that pages with poor page experience still show relevant content.
- MDN, HTTP compression, read 26 September 2026. How transfer compression works, and why already-compressed files do not shrink.
- MDN, HTTP caching, read 26 September 2026. The meaning of Cache-Control, ETag and Last-Modified on repeat visits.
- Chrome UX Report documentation, read 26 September 2026. The eligibility rules that decide when an origin has field data at all.
- ComReg, Quarterly Key Data Report Q1 2026, published 2026, consulted 26 September 2026. Used for the 21 GB average monthly mobile data figure per subscriber. A second automated fetch of this page was blocked by the site's firewall, so the figure is a page reading, not a curl measurement.
- Every measured site, all fetched 26 September 2026: rennwick.com, factprovenance.org and its www host, sligo.ie, leitrimcoco.ie, sligocu.ie, chadwicks.ie, claytonhotels.com, sligoparkhotel.com, and the 8,953,498 byte hero image. The sites are linked where the text above quotes their timings.
- Our own measurement record, with every figure and the command behind it, sits in a structured file with the draft and can be sent on request. It carries 353 figures, each with the value, the command and the source URL.
Revision log
26 September 2026, first edition. This article merges and replaces two earlier Rennwick posts, "Your website probably doesn't need a rebuild: fix the leaks first" and "The six-second tax: what a slow website quietly costs you", both of which argued from assertion. Every number here was measured on 26 September 2026 and is published with the command that produced it.