We Measured 13 Digital Health Websites: Twelve Ship Too Much JavaScript

Twelve of thirteen digital-health websites we measured ship too much JavaScript. Almost none of them are slow. Those two facts sit together far more often than teams expect, and the second one is why the first never gets fixed.

We build web and mobile products, and part of what we sell is performance work. So we wanted to know what is actually broken on the sites of the companies we talk to. Not what a conference talk says is broken. What is broken on theirs.

We took 13 real digital-health companies from our own prospect list and ran every one through the same pipeline our audit tool uses. Same code, same hour.

Here is what came back.

Every site had a finding, and not one came back clean

Ten of the thirteen had a critical one. Zero scored above 90 out of 100. Four scored below 50.

Twelve of thirteen were carrying too much JavaScript. That is the finding that repeats. One site shipped 146 KB of script, which is fine. The rest ran from half a megabyte to 3.1 MB. One was at 1.77 MB. The middle of the sample sat around 800 KB of script before a single word of content appeared.

And almost none of them were slow

That is the part that surprised us. On the eleven sites where Chrome had real-user data, largest contentful paint ran between 1.15 and 3.11 seconds. If you told those teams their site was slow, they would open their own analytics and prove you wrong.

So a site can be fine on paper and heavy underneath.

Where the weight actually shows up

Not in the browser of the person who runs the site. That browser is a desktop on a fast connection, and the cache is already warm. It shows up on a mid-range Android phone on mobile data, and it shows up in the second after the page paints, when the main thread is still busy with parse and execute, and nothing responds to a tap.

It also shows up in the team. A two-megabyte bundle means slow builds and a refactor nobody wants to start.

The mistake we made first, because it is the mistake most audits make

Our first run used lab data only: Lighthouse on a simulated device with a throttled network. It told us all 13 sites failed on load time, with numbers from 4.7 to 21.9 seconds, and that all 13 had clean server response times of 2 to 260 milliseconds.

Both conclusions were wrong.

We re-ran the same 13 domains against real-user field data. Load time was fine on almost all of them. Server response time was above Google's 800 millisecond bar on 8 of 13. The lab had reversed both answers.

The one column that survived the re-run was script weight. Lab and field agreed to within a tenth of a percent, because bytes are bytes. A simulated timing is a model of a device nobody owns. Bytes shipped over the wire are a fact.

If you take one thing from this, take that. Do not let anyone, us included, tell you your site is slow on the strength of a Lighthouse score. Ask what the field data says. And if there is no field data, that is information too. It usually means the page does not get enough traffic for Chrome to collect any.

What we did on our own site

Same method, our own domain. lomray.com went from 62 to over 90, and largest contentful paint from 6.5 seconds to 1.4. The cause was not the server. It was JavaScript above the fold and hydration running eagerly on everything instead of on what the visitor could actually see. Two pull requests.

If you want the same numbers for your site

We put the pipeline behind a page: audit.lomray.com. Paste a URL and read the report about a minute later. It is free and there is no call attached to it.

And if the report says your bundle is the problem and you would rather someone else fixed it, that is the work we do.