Understanding the Report: How to Read Every Score, Metric and Waterfall in an Enterramon Test

A practical walkthrough of what each number on your report actually means, what “good” looks like, and what to fix first, and understand what we are testing and how to read the report data.

When you run a test on enterramon.com you get a single page back with a lot on it. Four headline scores, two waterfalls, a pile of performance metrics, a filmstrip of screenshots, an SEO breakdown, SSL and HTTP detail, and the server’s IP and ASN information. It’s a fair amount to take in, especially if you’re not the one who built the site. This article walks through the whole thing top to bottom, explains how the scoring works under the hood, and shows you where to look first when a number isn’t where you want it.

The nice thing is, we can show you all of this on the same page, before and after we actually changed something. Over a couple of weeks in June we ran enterramon.com’s own homepage, made some real changes, we moved our analytics and tracking to Cloudflare Zaraz and tidied up the SEO basics, and then ran it again. Same site, same Cape Town (AF-CPT) region, same broadband-100 connection profile, about seventeen days apart. So this is a genuine before and after, not two unrelated pages, and the differences are real.

Look at those scores and you’d be forgiven for thinking almost nothing happened. Performance stayed pegged at 100, Overall didn’t budge off 96, and only SEO moved. But the desktop load time dropped from 3.1 seconds to 1.4 seconds, and the worst script on the page disappeared from the waterfall. That gap between “the dial didn’t move” and “the page got noticeably faster” is the single most useful lesson in this whole article, and we’ll come back to it. The score is a headline, the detail underneath is where the work is.

One more thing up front. This is the free tools report. The Enterramon Pro product carries more of the data, history, trend lines, scheduled delivery and alerting. A few fields below are measured internally and surfaced more fully in Pro, and we’ll flag those as we go.

At the top of every report you get four dials. The first three are independent pillar scores out of 100. Overall is not their average, it’s a weighted blend, and the weights reflect what we think actually matters for how a site performs and ranks in the real world:

Those four sum to 100, which is the whole score. You’ll notice the free report surfaces dials for SEO, Performance and Security plus the blended Overall. The Caching / Delivery pillar is measured and folded into Overall even though it doesn’t get its own dial in the free view. That’s deliberate, because caching is one of those things that’s easy to measure badly from the outside, so we lean on it inside the blend rather than putting a potentially misleading single number front and centre.

A few principles run through all of the scoring, and they explain some results that look odd at first glance.

We score what we can directly measure, and we don’t invent data. If a certificate’s expiry date can’t be read, the expiry check scores nothing rather than assuming a comfortable default. If the cache test on a heavy page times out before it can measure asset cacheability, we score only what we did observe and cap the result so it visibly reads as incomplete, rather than punishing the site for our measurement falling over. You’ll occasionally see a metric come back partial for exactly this reason. On both runs here, the desktop resource breakdown reported its CSS total as zero, which is a capture quirk on that pass, not the site genuinely serving no stylesheets. Knowing that automated tools do this is part of reading any report sensibly.

Scores clamp between 0 and 100. Several pillars have checks that add up to more than 100 before clamping, which is why a site can fix a couple of real things and still land on the same headline number. It was already bumping the ceiling from another direction.

Performance (35%)

This is aligned to Core Web Vitals and deliberately leans toward mobile, roughly 55% of the weight on the mobile numbers and 45% on desktop, because Google indexes mobile first. Within that, the metrics that lead are LCP (largest contentful paint) and TBT (total blocking time, our lab proxy for INP, the main thread blocking metric), then CLS (layout shift), with FCP (first contentful paint) and TTFB (time to first byte) carrying lighter weight. There are small modifiers on top, a few points for serving modern image formats, and a small penalty if third party requests make up more than half the page’s load. Weighting TBT heavily is what stops a page that paints fast but is janky and slow to respond from quietly scoring top marks.

Security (25%)

HTTPS is the only direct search ranking factor in here, everything else is best practice hardening. The main items are a valid certificate and a trusted certificate chain (these are scored separately, a site with a broken chain still loads in browsers but scores below a clean one), HSTS, a Content-Security-Policy, X-Frame-Options, X-Content-Type-Options (nosniff), and a clean 200 response. CSP is the modern XSS mitigation and scores well. The deprecated X-XSS-Protection only earns a small fallback credit when CSP is absent, on the “some signal beats none” principle. A certificate days from expiry is actively penalised. And to be clear, this is a surface check of hardening that should be table stakes. It is not a penetration test or a deep security audit, and it never will be. That’s deliberately out of scope.

Caching / Delivery (20%)

Driven mainly by how cacheable your static assets are, plus compression (Brotli scores higher than GZIP), with a smaller credit for a cacheable document. A document marked no-cache is treated as neutral, not penalised, because that’s the correct setting for a genuinely dynamic page. When the full asset measurement isn’t available we score only compression and document level caching on a rescaled basis and cap it, so an incomplete measurement can’t masquerade as a perfect one.

SEO (20%)

This is an overview, not a deep SEO audit, just the basic mechanics. A meta description, a single H1, valid structured data (any valid JSON-LD now counts, not just an Organization block), robots.txt, a sitemap, a reasonable word count, enough internal links, a healthy alt text ratio on images, complete Open Graph tags and a Twitter card. There’s a small penalty for a meta keywords tag, because in 2026 it’s a mild keyword stuffing signal that does nothing useful. The deeper SEO work, the kind that actually moves rankings, lives in our dedicated SEO tooling, not here.

This is the pillar that actually moved between our two runs (80 to 95), so it makes a perfect worked example. On the 9 June run, three things were dragging it down. There was no structured data detected (no JSON-LD schema at all), the Open Graph tags were incomplete (the og:title was a broken Home - and there was no og:image), and the page was lighter on content (about 1,160 words). By the 26 June run we’d added a proper Organization schema block, fixed the Open Graph title and added the image, and the content had grown to roughly 2,080 words. That’s the difference between 80 and 95, and you can see every one of those items in the report’s own SEO sections. (It’s still 95 and not 100 mainly because there’s a leftover meta keywords tag costing a couple of points, which rather proves the point about that tag.)

And the one that doesn’t count yet: Accessibility (WCAG)

We already run an accessibility scan (built on axe-core) and we already calculate a standalone WCAG health score, but it is not part of any of the four pillars and it is not in your Overall, and right now it isn’t shown on the free report at all. We’re still completing our testing before we surface it.

When we do, it’s worth understanding what that number will and won’t be. It is a health score, not a compliance percentage. 100 means no automatically detectable WCAG violations on the page that was scanned, which is not the same thing as “this site is legally compliant.” It’s calculated on a decay curve rather than by simple subtraction, weighted by issue severity (critical issues hurt far more than minor ones), and the curve exists for a practical reason. Real pages routinely have dozens of detectable issues, and if we subtracted points linearly almost every site would pin at zero and you’d never see a trend line move. The curve keeps resolution across the whole range, so a page going from 56 issues down to 9 visibly climbs, which is the entire point of tracking it over time. A future update will show that score, the specific issues detected, and recommendations on what’s missing or can be improved. Automated scanning only ever catches a portion of real WCAG problems, so the human review layer remains the part that matters most, but it’s a strong, repeatable starting point.

Dual stack done properly is sometimes the faster, and steadier, path.

Scroll to Server Details and you’ll see the resolved IPv4 and IPv6 addresses, the country, and the ASN (the network the address belongs to). On both runs the addresses resolve to Cloudflare, Inc., ASN 13335, which tells you the site sits behind Cloudflare’s edge rather than exposing its origin directly. You’ll also notice the actual IP differs between the two runs, that’s Cloudflare handing you a different edge address, and it’s completely normal.

Now look at those ping figures across the two runs, because they make a point we keep banging the drum about. The IPv6 latency was 19.85ms on 9 June and 19.886ms on 26 June, essentially identical, rock steady. The IPv4 latency was 21ms one day and 68.7ms the next, same site, wildly different. The headline takeaway is that when dual stack is set up properly, IPv6 is frequently as fast or faster than IPv4, and here it was also the more consistent path. It is not the scary, exotic thing a lot of customers still treat it as. If your report shows an IPv6 address at all, your DNS has the AAAA records in place and you’re on the modern path. If it’s blank, that’s a conversation to have with whoever runs your DNS and hosting, and frankly a question worth asking your ISP about your home or office connection too, but that’s a rant for another article.

This is where you find out what your visitors actually feel, and where the honest story lives.

The report shows desktop and mobile results side by side. Here are both runs laid out together:

Now, here’s the honest reading of that table, because it’s more instructive than a clean sweep would be.

The clear win is desktop load time, 3,106ms down to 1,449ms, roughly halved. Desktop JS execution dropped too (1,529ms to 1,240ms), and desktop LCP improved from 1,428ms to 1,008ms. That’s a genuinely faster page for desktop visitors, and the next section shows exactly which request caused it.

But the mobile load time barely moved (3,055ms to 3,028ms), and a couple of mobile metrics actually got slightly worse. Mobile FCP went from 672ms to 1,064ms, for instance. And here’s one that seems backwards, TTFB was actually lower before (83ms) than after (204ms). So the load time improvement did not come from a faster server response, it came from removing blocking work further down the page. The TTFB difference is just normal variance from landing on a different Cloudflare edge.

That mixed picture is the real lesson. A single test is a snapshot, and snapshots wobble, with edge routing, cache warmth, and whatever else the network was doing that second. One before and after pair is enough to show you a structural change (a heavy script gone), but it is not enough to declare a precise speed delta with a straight face. This is precisely why Enterramon Pro tracks the same page repeatedly and plots a trend line rather than asking you to trust any one run. If you only ever look at single tests, you’ll chase noise. The dial said Performance 100 both times, the truth is that desktop got meaningfully faster, mobile was about the same, and you’d want a few more runs to be sure of the rest.

It’s worth being explicit about why this variance is unavoidable, and it comes down to where the test is run from. Your site and our testing node do not live on the same server, or even the same network. The test is a real browser reaching across the public internet to your site, exactly as a visitor would. That means every run is subject to network latency, routing changes between the two points, how loaded your hosting server happens to be at that moment, and a dozen other things neither of us controls. So a single report will always be a snapshot of one moment, taken over one path, and it will quite happily show you specific, real things worth fixing in that moment. But the shape of how your site behaves only emerges over time. Run it monthly on Pro for three months and the trend line might tell you something a single test never could, that performance reliably dips at certain times of the month, that there are outages clustered at a particular time of day, or a slow, steady downward drift as your hosting provider quietly packs more sites and customers onto the same box you’re on. Those are the patterns that actually change decisions, and you simply cannot see them in one run.

Taking each metric in turn, for reference.

The closest thing to standing behind a real visitor.

Under each set of results you get a strip of screenshots captured at 250ms intervals, 0ms, 250ms, 500ms and so on. This is the most intuitive part of the report and the one to show a client who isn’t technical, because it answers the only question they really care about: what did they see, and when?

Swipe through and you can watch content fill in frame by frame. The visible gap before anything useful appears is your FCP and LCP made tangible. It’s also where you spot a useful subtlety. If the page looks finished at frame five but the load time says three seconds, that tells you the slow tail is scripts and trackers finishing behind a page that’s already usable. That’s exactly what’s happening on our reports, the page is visually done well before the LinkedIn and analytics calls stop firing, so the raw load number is a little harsher than the visitor’s actual experience. Read the filmstrip and the metrics together.

Every request, in order, with its weight on a timeline.

The two waterfalls, desktop and mobile, are the diagnostic heart of the report. Each row is a single request the page made, the document itself, then every stylesheet, script, font, image and tracking call, in order. The columns give you the file, its type, its duration, and a timeline bar showing when in the load it happened and how long it took.

Next to the type you’ll see small tags, and they’re worth learning because they tell you how a resource loaded and where it came from:

So the fast way to read a waterfall is to scan for the long bars, then look at their tags. A long S3 is a synchronous, externally hosted script that’s blocking your page, exactly the kind of thing you want gone, deferred, or moved to the edge.

This is where the change between our two runs is obvious, even though the Performance dial never moved.

On the 9 June (before) run, the standout offender is Google Tag Manager, googletagmanager.com/gtag/js, tagged S3 (a synchronous third party script, the worst case), clocking 1,080ms on desktop and 1,056ms on mobile, a big blocking chunk sitting right in the load. Just as ugly is the LinkedIn tracking call (px.ads.linkedin.com/collect) at a remarkable 1,869ms desktop and 2,114ms on mobile. Add the Google Analytics collect calls, an ahrefs tag and a third party cookie consent widget, and a real slice of the page’s weight is things the page doesn’t need to render at all.

On the 26 June (after) run, Google Tag Manager is gone from the waterfall entirely, replaced by Cloudflare Zaraz’s cdn-cgi/zaraz/s.js loading in around 45 to 53ms. Same job, managing the analytics and tracking, done at the edge instead of by shipping a heavy tag manager script to the browser to execute. That single swap is the clearest cause of the faster desktop load.

That’s the practical use of the waterfall. It doesn’t just tell you a page is slow, it points straight at the rows responsible. Scan for the longest bars, ask “does the page need this to render?”, and you’ve got your fix list in priority order.

Zaraz did the heavy lifting, we’re not finished.

The biggest structural change was moving the analytics and tag management, Google Analytics and Tag Manager especially, off the page and into Cloudflare Zaraz, which loads and manages those tools from Cloudflare’s edge rather than making each visitor’s browser download and run every vendor’s script. The waterfall shows the payoff, a roughly 1,080ms blocking tag manager became a roughly 50ms edge call.

But being honest about what’s still there, because the after report shows it plainly, moving to Zaraz didn’t magically clear everything:

• The LinkedIn Insight tag and its collect call are still loading raw, and they’re still the single worst bar on the page (that mobile collect was still up around 1,895ms on the after run). That’s the next thing to move behind Zaraz or drop.
• ahrefs and a DoubleClick call are still raw, more candidates for the edge or the bin.
• The cookie consent widget is still pulled from a third party CDN at over a second. Consent tooling is compliance furniture, it gets installed and forgotten, but it’s a real cost on every load and worth revisiting.
• Web fonts show up repeatedly in the 300 to 650ms range (Google Fonts and icon fonts). Self hosting, subsetting, or cutting the number of families is a classic quiet win.
• JS execution still sits above a second, so there’s more main thread trimming to do once the third party load is dealt with.

None of this is dramatic. It’s the ordinary, unglamorous work of looking at the waterfall, asking what each heavy row is doing for you, and dealing with it one at a time, which is exactly the loop this report is built to support.

Read it like a triage list, not a report card.

The Overall score is a useful headline, but as our two runs prove, it can sit dead still while the page underneath genuinely improves. The value is in the detail. A practical way through it:

1. Start with the four dials to see which pillar is dragging. For us, that was SEO, while Performance was already maxed even when the page was slower.
2. Confirm the test profile and region so you’re judging the site fairly, and comparing like with like.
3. Read the waterfall and pick out the longest bars that aren’t needed to render the page. That’s your fix list, in priority order, and it’s where the real story was for us, not in the score.
4. Cross check the filmstrip to see how much of the slowness the visitor actually feels versus what’s finishing quietly in the tail.
5. Sweep the SEO, SSL and Files sections for cheap, obvious gaps, a missing schema block, a broken Open Graph title, or a cert getting close to expiry.

And remember this is the free report, a single snapshot of one page at one moment, with all the variance that implies. Enterramon Pro is where this becomes ongoing, with scheduled tests, trend lines so you can see whether a change like our Zaraz migration actually moved the needle over many runs rather than one lucky pair, multi page coverage, alerting when something breaks or a cert is about to lapse, and white labelled delivery if you’re reporting to clients. The accessibility scoring discussed above will land there first as well.

If a number on your own report doesn’t make sense, run it, share the result, and come back to this page with it open alongside, because everything here maps directly onto what you’ll be looking at.

Reports referenced in this article, both for enterramon.com, both tested from the AF-CPT (Cape Town) region on the broadband-100 profile: the 9 June run (before) and the 26 June run (after). Run your own free test at enterramon.com.