We Rebuilt Our Own Photo Library. 76 of Our 155 Photos Are Still Over the Limit We Tell You to Hit.

There is a plumbing company somewhere in the South Coast that has been in the same building since before I was born. Not a specific one. A composite of the kind that exists in Fall River and Somerset and Westport and Tiverton: two trucks, a landline that gets answered by a person, a son or a daughter now running the schedule, and a customer list built entirely out of forty years of showing up on a Sunday in February when somebody's basement was filling.

That company does not have a marketing problem. It has forty years of the hardest asset in business to buy, which is people who already believe you.

And when a shop like that finally decides to expand properly onto the internet, the first real decision it makes is not about words. It is about photographs. The trucks. The crew. The boiler room after. Somebody's phone has four hundred of them and nobody has ever done anything with them, and the moment they go onto a website they become the single heaviest thing that website will ever carry.

We know that because we did it to ourselves, badly, and then rebuilt it.

What we rebuilt#

Avalon publishes articles with photographs of Fall River in them. Those photographs started life as a camera roll: 272 raw iPhone JPEGs, most of them portrait, shot at 1536x2048, one to two megabytes each.

Shipping those directly would have been the most self-defeating thing this business could do. Our entire pitch to a local shop is that its website is slow because nobody compressed its images. So we wrote a pipeline that takes the roll and produces a library.

It runs three quality gates before it touches a single byte. It rejects anything below an edge-variance focus score of 450, which is what removes the out-of-focus railing shots and the frames with a thumb over the lens. It rejects anything with a mean luminance under 45 or over 235, which catches the pocket shots and the blown-out ones. Then it drops near-duplicates using a 64-bit perceptual hash at a Hamming distance of 8 or less, because twelve consecutive photographs of the same flower bed will otherwise show up in the feed eight days running.

272 photographs went in. 155 came out. 117 were thrown away, which is 43 percent of the roll, and the rejections are printed rather than hidden so anyone can disagree with them.

Each survivor is written out four times: a full at 1300px on the long edge with the aspect ratio preserved, a thumb at 800px, a wide cropped to 1200x630 because that is what a link preview demands, and a square cropped to 1080x1080 because that is what Instagram demands. WebP, quality 80. 620 files.

Before and after#

Here is the actual rebuild, and it is a small, boring, entirely typical one.

The first build used 1600px on the long edge for the full size. That version is gone, but the note we left in our own pipeline when we changed it records what it cost: at 1600px the full-size images came out at 295 KB per hero. The comment in the code says, verbatim, that this was "heavier than Avalon has any business shipping while publishing articles about other people's oversized images."

So we dropped the long edge to 1300px. The reasoning is in the same comment and it is worth stealing: the reading column on this site is about 768 CSS pixels wide, so 1300px covers a 1.6x device pixel ratio comfortably and a 2x screen acceptably. Anything beyond that is bytes the reader downloads and never sees.

I measured the result on disk this morning, 3 August 2026. Every number below is a file size taken from the repository, not an estimate.

295 KB per hero down to a 196.1 KB median. That is the before and after, and by itself it looks like a win.

The part that is still wrong#

We tell people, in writing, in articles anyone can read: compress your images, save them as WebP, target under 200 KB each.

We miss our own rule on 76 of 155 full-size photographs. That is 49 percent. The largest is 475.9 KB, which is more than double the number we hand out as the target. The square variants are just as bad: 76 over the line and a 465.1 KB maximum, and the square is the exact file Instagram serves.

Here is the actual cause, because "we were sloppy" is not a diagnosis.

The pipeline sets dimensions and lets the bytes land wherever they land. Long edge 1300, quality 80, save. That is a fixed input, not a fixed output. The lightest full-size file in the library is a photograph of the waterfront boardwalk at golden hour: 44.4 KB. The heaviest is a tree-lined residential street, which is thousands of small edges in every direction: 475.9 KB. Same pipeline, same settings, both processed exactly as designed. Only one of them is under the limit.

The fix is not a smaller number. It is a byte budget: re-encode at a lower quality, or a shorter edge, until the file is actually under the target, and fail loudly on the ones that will not get there. That is maybe thirty lines of code. It has not been written. As you read this, those 76 files are still on the server.

We published a rule and never enforced it in code. That is the whole bug, and it is the most common shape of failure I see in other people's websites too: the standard exists in someone's head and nowhere in the system.

What we could not measure#

The total megabytes saved. The pipeline prints a source-versus-optimised figure when it runs. Nobody kept the output, and the original 272-image camera roll is not in the repository, so that number is gone. I am not going to reconstruct it from the "one to two megabytes each" in our own docstring and present the result as a measurement.

An "after" for this website. On 31 July we published our own site's audit and promised to re-run the identical measurement once the fixes shipped. The blog index was 4.1 seconds on mobile, which Google rates poor, and 930 KiB. That re-run has not happened and this article is not it. The promise stands and the second number will be published next to the first whether it moved or not.

Delivery, as opposed to disk. Every figure above is a file size on a hard drive. What a visitor actually pulls down depends on their browser and the CDN in front of it. It is a good proxy. It is not the same thing.

Now the plumbing shop#

Here is why any of this should matter to somebody running two trucks out of a yard off Route 6.

On 13 July we measured every plumbing business Google Places returns for "plumber in Fall River, MA", excluding franchises and chains. Sixteen businesses. Between them they hold 2,991 Google reviews at a weighted average of 4.89 stars. The lowest-rated one in the entire set is a 4.3.

Google's threshold, not ours: a Largest Contentful Paint of 2.5 seconds or less is good, and anything over 4.0 seconds is poor. Eleven of the twelve plumbers we could measure missed the good threshold. Seven were rated poor. One site took 48.0 seconds to show its main content on a phone. Two of the sixteen had no website at all.

Nine of the thirteen live plumber sites had no contact form. Five had no tappable phone number, meaning the number is printed as text and a thumb cannot dial it.

Read those two paragraphs together. Nearly three thousand people took the trouble to go and write down that these companies did right by them. And a share of the people who go looking as a result never see the page.

Ultimately, any business with a Google Business Profile can gain huge value by analyzing user-generated content—both reviews and Q&A. By incorporating that language into your website, you're no longer just saying, We're great because we say so. Instead, you're proving, We're great because our customers keep saying it. And that's what truly sets a business apart.

Gifford is right, and the inversion is the part that stings for a trade business. The proof is already written. It is sitting in 2,991 reviews describing a plumber who turned up on a holiday weekend. Nobody has to invent it, or write it, or pay for it. It just has to load.

Google's own mobile playbook puts a number on what happens when it does not: "a one-second delay in mobile load times can impact conversion rates by up to 20%." That is Google describing its own data, in the Mobile Site Speed Playbook. A median of 9.4 seconds is not one second.

And the thing that makes it 9.4 seconds is almost never the words. It is the photographs of the trucks.

What to do Monday, cheapest first#

1. Measure. Free. Ten minutes. Go to pagespeed.web.dev, paste your address, choose Mobile, read the LCP number. Same tool that produced every speed figure above. Do not fix anything yet. Just learn the number, because you cannot argue with a web guy about a problem you cannot name.

2. The free one: compress the photographs on your homepage. Free. One afternoon. This is the fix I would most like you to take from this article, and it is the one we ourselves half-did. Open squoosh.app in your browser. It runs on your own computer and uploads nothing. Drag in each photo, set the format to WebP, quality around 80, resize the longest edge to 1300 pixels, and check the file size it reports before you download. Target under 200 KB. If a picture will not get under 200 KB at quality 80, drop the quality to 70 and look at it. On a photograph of a truck you will not be able to tell.

That last step is the one our own pipeline skips, which is exactly how we ended up 49 percent out of compliance with our own advice. Check the number on the way out, not just on the way in.

3. Make your phone number tappable. Free. Five minutes. Five of the thirteen live plumber sites we measured fail this. On a phone, a number that is plain text is a number nobody calls. Whoever maintains your site changes it to a link in one line; on Wix or Squarespace it is a setting in the link panel. Highest-value five minutes on this list.

4. Put a contact form on the page. Free to about $10 a month. Nine of thirteen had none. Not everyone with a leak wants to talk to a human at 11pm, and the ones who do not are currently going to whoever gives them a box to type into.

5. If you have no website at all, buy the domain this week. Two of sixteen. One of them holds a 4.8-star average. A single page with the trucks, the hours, the towns you cover, a tappable number and a form beats nothing by an enormous distance, and it can go up in a weekend.

Do one and two this week. They cost nothing and they are the two most likely to make the phone ring.

Why we published this#

Because an audit is worth nothing from someone who has never been on the receiving end of one. We built a photo pipeline specifically so that we would not be hypocrites about image weight, and it still lets 49 percent of our full-size images past the limit we publish. Finding that took one command and about a minute. Nobody made us look.

If you would rather work with somebody who only shows you the 196.1 KB median and never mentions the 475.9 KB maximum, they are not hard to find.

If you run a shop around here and you want your actual numbers before anyone tries to sell you anything, I will run the same audit on your site, speed and mobile and schema and your Google listing and the tappable-phone check, and send you what it says. No charge, no obligation. If the answer is that your website is fine, I will tell you that and you will never hear from me again.

774.559.8992 · Joshua.Amado@AvalonPartner.com

---

Method: photo library figures are file sizes read directly from public/images/photos on 3 August 2026, 155 photographs at four variants each, 620 files. Sizes are decimal kilobytes of 1,000 bytes, which is the unit Squoosh and most file managers report, so a reader repeating this gets the same numbers. The 295 KB per-hero figure for the previous build is quoted from the comment left in our own pipeline at the time of the change and is not a measurement taken today. Trade website figures come from Avalon audit briefs dated 13 July 2026 (plumbers and HVAC, Fall River) and 15 July 2026 (HVAC, Fairhaven). Speed is mobile Largest Contentful Paint via the Google PageSpeed Insights API; where Google has enough real traffic to report field data we use it and where it does not we fall back to a lab estimate, and field data was available for only 2 of the 12 plumber sites. Thresholds are Google's, not ours. Businesses that blocked our checker are recorded as unmeasured, never as "no website". Anything we could not measure is excluded rather than counted as zero. Every one of these numbers can be re-run by anyone with pagespeed.web.dev.