We ran two free speed tests on 12 South Coast print shop sites. One said 0.2 seconds. The other said 21.

A print shop is one of the last businesses on the South Coast where the product is physically handed over. Someone walks in with a logo scribbled on a napkin and walks out three days later with four hundred shirts for a fundraiser, a banner for a wake, a wedding invitation in a stock the couple chose by touching it. That work is exacting and the people who do it are, in my experience, some of the most precise operators in the region. The proofs go back and forth until the colour is right.

Which is what makes the following uncomfortable to write.

I tested twelve real print shop and commercial printing websites on the South Coast. Not a survey, not a scrape of somebody else's report. I loaded each site myself, three different ways, and wrote down what each method said. The methods disagreed with each other by as much as a factor of 116.

That is not a rounding error. That is one tool telling a shop owner everything is fine while their customers stare at a white screen.

What I tested, and how#

Twelve print shop, sign and commercial printing websites across the South Coast, drawn from our July directory sweep of the New Bedford area. They are anonymised here as Site A through Site L. They did not volunteer for this and they are not going to be named. If you recognise your own numbers, call me and I will walk you through them privately.

For each business I measured the URL it publishes on its Google listing, which is a homepage in eleven cases and a contact page in one. Each was measured three ways on 10 August 2026:

Method 1: HTML fetch time. Request the page, time how long until the HTML document has finished downloading. Best of three runs, so the method gets every benefit of the doubt. This is essentially what the free "test your website speed" widgets and most cheap monitoring tools report.

Method 2: Lab mobile LCP. Google PageSpeed Insights, mobile strategy, Largest Contentful Paint. Google renders the page on a simulated mid-tier Android phone on a throttled connection and records the moment the biggest piece of content actually appears. This is a simulation, and I will say so every time I quote it.

Method 3: Field data. Real Chrome users, real phones, 75th percentile, trailing 28 days. What actually happened to actual human beings.

Anyone can repeat all of this. Method 1 is a stopwatch. Methods 2 and 3 both come from pasting a URL into pagespeed.web.dev, free, no account.

Every site passed. Eleven of eleven failed.#

Here are the eleven sites where the lab measurement completed:

Read the first two columns against each other. By the HTML fetch method, twelve out of twelve are excellent. The median is four tenths of a second. The slowest of them, Site D, still comes in at 2.49 seconds, and even that squeaks under Google's 2.5 second bar. If that is the only number a shop owner has ever seen, they have every reason to believe their website is fast, and every reason to be annoyed at anyone who suggests otherwise.

By the lab method, eleven of eleven fail Google's "good" threshold. Ten of eleven are rated poor. The median site takes 15.2 seconds to paint its main content on a phone.

Why the two numbers disagree so violently#

The HTML document is the recipe. It is not the meal.

When your server hands over that file in 0.18 seconds, all it has proven is that your host is awake. The browser then reads the recipe and discovers it needs eleven fonts, a slider library, a tag manager, four tracking pixels and a hero photograph straight off a camera. It goes and gets all of them, over a phone connection, in a parking lot in New Bedford. Only then does anything appear.

Look at the last column. The median page in this sample weighs 2,617 KB. The heaviest, Site D, is 8,392 KB. That is more than eight megabytes to show somebody your hours and a photo of a banner.

Now look at Site I: 339 KB, and the only site in the group under 4 seconds. It is not fast because it is clever. It is fast because it is small.

The gap column is the number I would put on a wall. Site C delivers its HTML 116 times faster than it delivers its page. Every free checker in the world will congratulate Site C. Not one customer will.

The tool nobody on this list can use#

Method 3, the real-user field data, is the one that actually matters. Google says so plainly on its own page written for business owners:

Core Web Vitals are measured by the real users of your website, and different users will have different results. They are not "what Google thinks" nor "what googlebot thinks", but what your website's actual users have experienced.

Here is the finding I did not expect, and it changes the recommendation.

Field data was available for zero of the twelve sites. Not one. Google needs a minimum volume of real Chrome traffic before it will report field metrics, and no print shop in this sample clears it.

So the best measurement tool available is, for every single business in this study, unavailable. That is the real story of small business web performance on the South Coast. The gold standard is out of reach not because these shops did anything wrong, but because they are small.

The verdict#

A Reckoning is supposed to pick a winner, so here it is.

Use PageSpeed Insights on mobile, and read the LCP number. Ignore every free "site speed checker" that returns an answer instantly.

If a speed tool gives you a result in under a second, it did not load your website. It downloaded a text file. It cannot have measured your images, because it never asked for them. The instant answer is the tell.

The lab number has a genuine weakness and I am not going to pretend otherwise. It is a simulation of one mid-range phone on a throttled connection, run once. Your customer on new hardware and good WiFi will do better than 15.2 seconds. That is a fair objection, and it is why Google prefers field data.

But it is the wrong objection for a business this size, because the field data does not exist for you. Given a choice between a pessimistic simulation and no information at all, take the simulation. A tool that is directionally right beats a tool that is confidently, cheerfully wrong by a factor of 116.

The fix you can do today, for free#

Find your heaviest image and shrink it. That is it. That is the whole assignment.

On this sample, page weight and LCP tracked each other closely, and the lightest site in the group was also the fastest by a wide margin. Images are almost always the bulk of it, because the photo of your wide format printer came off a phone at 4,000 pixels wide and got uploaded exactly as it was, to be displayed in a box 800 pixels across.

Three steps, about twenty minutes, no money:

1. Paste your homepage into pagespeed.web.dev and choose Mobile. Write down the LCP number. This is your before.
2. Scroll to "Opportunities" and find "Properly size images" or "Efficiently encode images". Google will name the exact files and tell you how many KB each one is wasting.
3. Take the worst offender, run it through squoosh.app (free, made by Google, runs in your browser, nothing is uploaded anywhere), export it as WebP at around 1600 pixels wide, and swap it in.

Then re-run step one. On a site carrying an 8 MB homepage, that single swap is often worth several seconds.

What a South Coast print shop should do Monday#

You sell precision. A colour proof goes back and forth until it is exactly right, because you know the customer will notice. Your website is currently shipping at a tolerance you would never accept on a press.

The good news is that the failure here is not a design failure. Every site in this sample was reachable and served its HTML quickly. The bones are fine. These are weight problems, and weight problems are the cheapest class of problem there is.

So, Monday morning, before you unlock the front door:

1. Measure the honest number. pagespeed.web.dev, Mobile, your homepage. Ten seconds of work. If it comes back over 4.0, you now know something you did not know Friday.
2. Shrink one image. The steps are above. Free.
3. Check what your web person is quoting you. If anyone has shown you a green "0.4 second load time" dashboard, ask them specifically for the mobile LCP from PageSpeed Insights. The answer to that question tells you a great deal about who you are working with.

If your number comes back at fifteen seconds, you are in the median of your own industry on the South Coast. That is not an insult. It is an opportunity, because your competitors down Acushnet Ave are sitting at fifteen seconds too, and the first one to get to three seconds is going to be the one whose site loads while the customer is still interested.

If you want the honest number for your own site without doing it yourself, or you want to know what is actually causing your fifteen seconds, call me. No charge for the measurement, and I will tell you if the answer is that you do not need me.

Joshua Amado, Avalon Partner · 774.559.8992 · Joshua.Amado@AvalonPartner.com

---

Method notes: 12 South Coast print shop, sign and commercial printing websites, measured 10 August 2026. For each business we measured the URL it publishes on its Google listing: eleven homepages and one contact page. Ten of the twelve end on HTTPS once redirects are followed; two still serve over plain HTTP. HTML fetch is best of three runs from a US datacentre with a mobile user agent. Lab LCP is Google PageSpeed Insights, mobile strategy, single run. Field data is CrUX 75th percentile mobile, trailing 28 days, and was unavailable for all 12. One site's lab run failed and is reported as not measured rather than estimated. Google's thresholds are Google's own: LCP at or under 2.5s is good, over 4.0s is poor. Every number here can be reproduced by pasting a URL into pagespeed.web.dev.