Noise & Silence

Abstract

Automated performance tools such as Google PageSpeed Insights are screening instruments: they are engineered for sensitivity, and consequently they fail in two directions at once. They produce noise — flags that are false, immaterial, or unfixable for the specific site — and they produce silence — real, user-experienced bottlenecks that appear nowhere in the report. The Noise & Silence framework treats the automated report itself, not the web page, as the primary object of the audit. Its method is the Four Verdicts: every flag the tool raises is adjudicated, with documented evidence, as Real, Wrong, Trivial, or Locked. The adjudication yields two falsifiable quantities — the Noise Rate (the share of flags that should receive no engineering effort) and the Silent Bottleneck (the binding field constraint absent from the flag list) — and every surviving recommendation must then pass a three-step verification ladder: predict, prove, confirm. The framework imports its foundations from screening theory, signal detection, medical alarm-fatigue research, and the actionability literature of automated static analysis; its application to web-performance reporting is, to our knowledge, novel.

1. Two wrong responses to the same report

Web performance remains materially unsolved: in the most recent HTTP Archive Web Almanac, only 48% of mobile origins and 56% of desktop origins achieved “good” Core Web Vitals (Jariyal et al., 2025), while the business stakes are well documented — a Google-commissioned study conducted by Deloitte and 55 across 37 brand sites found that a 0.1-second improvement in mobile speed metrics was associated with, among other effects, an 8.4% increase in retail conversions (Deloitte, 2020). We have quantified that stake for a single page in our own research on the cost of a millisecond.

Into this gap Google ships a free, authoritative diagnostic: PageSpeed Insights (PSI), which wraps Lighthouse lab analysis and Chrome User Experience Report (CrUX) field data. Practitioner responses to its output are strikingly bimodal. One camp treats the report as a work order and burns engineering quarters chasing a 100/100 score. The other camp, exhausted by recommendations that never seem to move anything, concludes the tool should be disregarded altogether — an entire genre of practitioner literature exists to argue that the score “does not matter” or “does not reflect reality” (Lyrical Host, n.d.; HelpfulCrowd, n.d.). The software-engineering research community observed the same two poles over a decade ago with static analysis tools: developers either drown in warnings or abandon the tool, with false positives and warning overload chief among the reasons they cite (Johnson et al., 2013).

Both responses share the same mistake: they assign the report a truth status — all true or all worthless — instead of assigning each claim in it a verdict. A screening instrument's output is neither a work order nor garbage. It is input for a confirmatory diagnosis that has not yet happened.

The Noise & Silence framework is that confirmatory step, made explicit, procedural, and measurable.

2. Foundations: screening instruments and their two errors

None of the framework's ingredients is new. That is deliberate: each pillar is imported from a field that has already spent decades — in one case, nearly a century — learning the lesson web performance has not yet institutionalized.

Screening is not diagnosis. Since Wilson and Jungner's canonical WHO monograph, medicine has separated the high-sensitivity screening test from the confirmatory diagnostic work-up that must follow it — and made the availability of follow-up diagnosis an explicit precondition for screening at all (Wilson and Jungner, 1968). A screening instrument is designed to over-flag: for its maker, a false alarm costs little, while a miss is catastrophic. PSI has exactly this economic structure — a false alarm costs the site owner's time, not Google's — so its over-flagging is a design property, not a defect.

Every detector commits two errors. Statistical decision theory formalized the trade-off: a test can raise a false alarm (Type I error) or miss a real signal (Type II error), and tuning a detector toward sensitivity necessarily buys more of the first (Neyman and Pearson, 1933; Green and Swets, 1966). Noise and silence are these two errors, in plain language, applied to a performance report. The framework's contribution is to insist that an audit must measure both — and the literature on diagnostic testing adds a warning that transfers directly: a positive result's usefulness — its predictive value — collapses when the condition it flags is rare in the population under test, which is why a flag's existence is never evidence of its importance (Altman and Bland, 1994).

Unmanaged noise destroys the operator, not the instrument. Medicine calls the failure mode alarm fatigue: between 72% and 99% of clinical alarms are false, clinicians desensitize under the load, and patient deaths have been attributed to the resulting missed alarms (Sendelbach and Funk, 2013). Security operations centers rediscovered the phenomenon at industrial scale, with a finding that matters enormously for this framework: the seminal qualitative study of SOC analysts — titled “99% False Positives” — found that most alarms practitioners dismiss are not technically incorrect but are “true alarms, explained by legitimate behavior”: right about the event, worthless about the action (Alahmadi, Axon and Martinovic, 2022). Web teams that have “fixed everything PageSpeed said” twice and seen nothing move are exhibiting the same syndrome — not laziness, but a rational loss of trust in an unadjudicated alarm stream.

Actionability, not correctness, is the operative standard. The deepest import comes from Google's own static-analysis program. The team that built Tricorder, Google's internal analysis platform, measures what they call effective false positives: “We consider an issue to be an ‘effective false positive’ if developers did not take positive action after seeing the issue” — regardless of whether the flag is technically correct (Sadowski et al., 2018). A decade earlier, a systematic literature review had already consolidated “actionable alert identification” as its own research problem: separating, out of everything an automated analyzer raises, the subset a rational engineer should act on (Heckman and Williams, 2011). The Four Verdicts are a domain-specific actionability classifier in exactly this tradition — applied to a class of report, the web-performance audit, where no such discipline currently exists.

One more import deserves credit. The insight that page-load time is governed by a dependency structure — a critical path, such that optimizing off-path activities yields zero improvement — was established for web pages by the WProf work at the University of Washington (Wang et al., 2013). It grounds the framework's treatment of the binding constraint (Section 5.3), which is the theory-of-constraints principle that a system improves only when its constraint improves (Goldratt and Cox, 1984).

3. The instrument: where the noise comes from

Calling PSI's output noisy is not a criticism of Google's engineering; it is a description of structural properties that Google itself documents. Adjudication is possible precisely because the falsifying evidence is usually in the report's own data. Six mechanisms account for most of the noise we adjudicate in practice.

(a) The score is not the experience. The Lighthouse performance score weights Total Blocking Time at 30% and Speed Index at 10% (Chrome Developers, n.d. a). Neither is a Core Web Vital; neither exists in field data. Only half the score's weight (LCP 25% + CLS 25%) rests on metrics Google's own Search guidance treats as user-experience ground truth — and INP, a Core Web Vital since March 2024 (Google Search Central, 2023), is absent from the score entirely. A red lab score over green field vitals is therefore not a contradiction to be fixed but an artifact of metric weighting — and it is the single most expensive trap in the genre, because teams plan roadmaps around a number no user experiences.

(b) Simulated savings are upper bounds, not predictions. Lighthouse's default throttling is simulated: a modeling engine, Lantern, replays the observed network activity under modeled constraints. Google's own design documentation quantifies the cost — “Lantern is ~6-13% more inaccurate than DevTools throttling” — and frames this as acceptable because it is comparable to run-to-run variance (GoogleChrome Lighthouse, n.d.). Opportunity “savings” estimated this way do not compose, and can exceed physical reality; we have recorded a “reduce render-blocking resources: save 2,330 ms” opportunity on a page whose real users' 75th-percentile LCP was 2,784 ms — an implied post-fix LCP near 450 ms that no fix would ever deliver. Whether these promised savings materialize at all is an empirical question, and we have tested it directly: on clean, controlled pages the predicted milliseconds did appear, and were if anything conservative — which makes the wild over-estimates above all the more diagnostic of a broken chain.

(c) The tool refutes some of its own flags. Since Lighthouse attached machine-readable metricSavings estimates to audits (visible in the PageSpeed Insights API; Google, n.d. b), a flag can arrive carrying Google's own evidence of its immateriality. We have recorded “Reduce unused JavaScript — 909 KiB” raised with the tool's own estimated savings at zero on the metrics it modeled: the audit fired on byte count, while the modeling engine simultaneously reported that removing the bytes moves nothing. A verdict, in such cases, requires no outside evidence at all — only the discipline of reading the tool's second opinion of itself.

(d) One synthetic run generalizes poorly. Google's guidance is explicit that scores fluctuate with underlying conditions and that “it might be more useful to think of your site performance as a distribution of scores, rather than a single number” (Chrome Developers, n.d. a). We have recorded the same URL scoring 73 and 55 minutes apart, with no deploy in between. Any adjudication discipline must therefore refuse to treat two single lab runs as before/after proof — including, symmetrically, our own; we have quantified how many runs it actually takes to prove a change and built a required-runs calculator so the number is not guessed.

(e) The lab cannot know intent. Load-time coverage counts interaction-, route-, consent-, and security-path code as “unused”; the 909 KiB in the example above was substantially reCAPTCHA — code whose entire purpose is served after load, on a form the lab never submits. The same intent-blindness flags font-display: block on icon fonts (where blocking is the correct behavior), correctly art-directed responsive images as “improperly sized”, and legally mandated consent tooling as removable third-party cost. The flag is technically well-formed; the verdict requires knowing what the resource is for — which is exactly the judgment layer Sadowski et al. (2018) found automated analyzers cannot supply for themselves.

(f) Lab CLS is not field CLS. The lab loads a cold cache, cold fonts, and whatever page variant a datacenter IP receives; real users' layout shifts happen on interaction, on scroll, after consent choices. We have recorded a lab CLS of 0.122 flagged as failing on a page whose field 75th-percentile CLS was 0.00 — a false alarm falsified by the field data printed in the same report.

4. The silence: what the report cannot say

The second failure direction is structural absence — and it is more dangerous than noise, because an absence cannot annoy anyone into skepticism. Google's own documentation states the division plainly: “The lab data is based on a simulated load of a page on a single device and fixed set of network conditions”, and lab data “may not capture real-world bottlenecks” (Google, n.d. a). Four silences recur.

Origin-proximity blindness. The lab fetches from datacenter infrastructure that is frequently network-adjacent to the site's origin. We have recorded lab TTFB near 1 ms — the server-response-time audit passing with a perfect score — on an origin whose real users' 75th-percentile TTFB was 1.6 seconds: double the 0.8-second guideline Google's own documentation sets for server response (web.dev, n.d. b). On that site, the number-one field bottleneck appeared nowhere in the flag list. No amount of diligence applied to the 21 flags that were present could have found the problem, because the report's silence is not visible inside the report.

Interactivity blindness. INP, the responsiveness Core Web Vital, is measurable only when interactions occur; Google's documentation notes that lab tools observing “the loading of a page without any interactions” will not report INP, and offers TBT as “a reasonable proxy metric for INP, but... not a substitute” (web.dev, n.d. a). A site failing INP in the field can present a clean lab interactivity story, and vice versa — we have recorded a simulated “Time to Interactive: 19.4 s” on a page whose real-user INP was a near-good 219 ms. When lab and field diverge like this is itself a researchable question, and we have mapped when lab actually predicts field.

Population blindness. CrUX field data itself samples only opted-in Chrome users on desktop and Android; Chrome on iOS, WebViews, and all other browsers are excluded (Chrome Developers, n.d. b). For a Safari-heavy audience, even the “ground truth” half of the report is silent about most of the audience — a limitation the adjudicator must carry into every field-anchored verdict rather than discovering once and forgetting.

Variant blindness. The lab audits one URL, once, from one place, in one state: logged out, no consent choices made (or a bot-served variant of the page entirely), no A/B assignment, one geography. Whatever real users experience across templates, regions, consent states, and sessions is aggregated invisibly into field percentiles the lab run cannot decompose. The bot-served-variant case is not hypothetical — we measured how many sites serve PageSpeed a different page than their users, and you can check your own with the free PageSpeed cloaking test.

Noise wastes the effort you spend; silence wastes the effort you don't know you should be spending. A framework that only de-noised the report would still fail its user. This is why the framework has two words in its name.

5. The framework

5.1 The stance: audit the report

The unit of analysis shifts. A conventional audit examines the page and produces a second report beside Google's; the Noise & Silence audit examines Google's report about the page and produces verdicts on it — then goes looking, separately and field-first, for what the report omitted. PSI's output is neither competitor nor gospel: it is the case file. And the case file deserves respect without deference: PSI applies the same heuristics on every run — including the same wrong-for-this-site heuristics, every time. Consistency is not validity.

5.2 The Four Verdicts

Every flag the instrument raises leaves the audit with exactly one stamp. The verdicts are reached in a fixed order of tests, so that any two competent adjudicators confront the same decisions in the same sequence:

Real flags — typically a minority — are the only ones that proceed to root-cause analysis, a platform-native fix, and an impact prediction. Wrong flags are published with their falsifying evidence, because an unexplained dismissal teaches the reader nothing and would not survive scrutiny. Trivial flags are, wherever possible, refuted in Google's own numbers — quoting a flag's metricSavings: 0 back at it is the shortest proof in the genre. Locked flags convert wasted effort into redirected effort: the verdict names the controllable equivalent (for a fully hosted platform, the merchant-side lever) or explicitly licenses the reader to stop trying.

Three rules of evidence bind every verdict. First, verbatim evidence: the actual header, the actual byte count, the actual markup — a verdict with no artifact is not a verdict. Second, a documented falsification attempt: before a claim is asserted, the adjudicator records the check that could have disproved it and did not — the audit's epistemology is conjecture under attempted refutation, not accumulation of confirmations (Popper, 1959). Third, a confidence grade: findings that survive weak refutation attempts are published as hypotheses with a concrete next test, never as conclusions.

The kinship with security-operations triage is intentional and acknowledged: the SOC literature's central finding is that most dismissed alarms are “true alarms, explained by legitimate behavior” — unactionable rather than incorrect (Alahmadi, Axon and Martinovic, 2022). Trivial and Locked are the performance-audit names for exactly that category — true, yet owed no effort — and they are the two verdicts conventional web audits do not have words for.

5.3 The two metrics

The adjudication table compresses into two numbers, each falsifiable by re-running the same procedure.

Noise Rate. For a report whose adjudicated flags number F, of which W are Wrong, T Trivial, and L Locked:

NR = (W + T + L) / F

— the share of the report that should receive no engineering effort. It is a per-site, per-run quantity: the same flag can be Real on one site and Trivial on the next, which is precisely why site-blind flag lists cannot be work orders. A claim-weighted variant weights each flag by the tool's own estimated savings, measuring how much of the report's promised improvement evaporates under adjudication. NR is the effective-false-positive rate of Sadowski et al. (2018), computed for a performance report — and the comparison carries a sting: Google's own bar for shipping a static-analysis check to developers is an effective false-positive rate under 10% (Sadowski et al., 2018). Performance reports face no such gate. The Noise Rate measures what one would.

The Silent Bottleneck. Independently of the flag list, the audit determines the binding constraint of the failing field metric — the phase or factor that dominates the user-experienced number, in the critical-path sense of Wang et al. (2013) and the constraint sense of Goldratt and Cox (1984). The Silent Bottleneck is the finding that this constraint is not in the flag list: the report's Type II error, named. Its canonical instance is the passing server-response-time audit over a 1.6-second field TTFB; its verdict-line form is one sentence: “PSI raised 21 flags — and the number-one field bottleneck appears in none of them.”

A report can be mostly noise and still miss the point; the two metrics are deliberately of opposite polarity so that neither can masquerade as the other.

5.4 The procedure

1. Resolve the subject. Follow redirects to the final URL; confirm the fetched page is what users receive (bot walls, geo variants, consent walls disqualify the evidence). Every downstream claim is keyed to the final URL.
2. Collect the case file. One PSI run per strategy (mobile first), capturing the lab audit list, the tool's own per-flag savings estimates, and CrUX field percentiles at page and origin level.
3. Anchor on field truth. Field 75th-percentile LCP/INP/CLS decide what is broken. If no field data exists, say so and cap every user-impact claim's confidence accordingly.
4. Adjudicate every flag through the four tests of Section 5.2, with evidence, falsification note, and confidence on each row. No flag may be omitted: an unadjudicated flag is future noise.
5. Hunt the silence. Decompose the failing field metric into its binding constraint and check it against the flag list. Divergence between lab and field on any metric is itself evidence about where the silence lies.
6. Compute and report the Noise Rate and any Silent Bottleneck alongside the verdict table.
7. Carry only Real flags and silent findings forward into root causes, platform-native fixes, and predicted impact ranges.

5.5 The verification ladder: predict, prove, confirm

Every recommendation that survives adjudication owes the reader three successively stronger tests.

Predict. State the expected movement as an arithmetic range against field data — bytes over plausible bandwidth, round trips over measured latency — never as the simulator's point estimate (Section 3b). Ranges carry confidence grades. A performance-budget calculator and a speed-to-revenue calculator turn those arithmetic ranges into budgets and dollars.

Prove. Before deployment, demonstrate the delta in a controlled lab A/B — the page with and without the change, medians of repeated runs, because single runs differ by double-digit point swings under pure variance (Section 3d).

Confirm. After deployment, confirm in field percentiles — subject to the 28-day ramp rule: field data aggregates a rolling 28-day window (Google, n.d. a), so a real improvement surfaces as a four-week ramp, never a step. Declaring a fix failed two weeks after deploy is misreading the instrument's clock; so is claiming victory from a lab re-run alone. Lab proof and field confirmation answer different questions, and neither substitutes for the other.

Each dot: one measured fix from the calibration pilot — what it delivered, as a share of what was promised. All 8 at or above 100%.

6. A worked example

The table below is an illustrative composite assembled from adjudications recorded during the framework's development; it compresses the recurring row types into one view. (Individual client reports carry the full table with verbatim evidence per row.)

The verdict distribution of the example below — only the green segment receives engineering effort.

And then the row that is not in the table — because it was never a flag:

Silent Bottleneck. Initial server response time: passing (lab TTFB ~1 ms from the datacenter). Field p75 TTFB: 1.6 s — double Google's 0.8 s guideline. The number-one field problem produced zero flags. It is found by decomposing the field metric, not by reading the report harder.

Aggregated to the verdict line a client sees first: “PSI raised 21 flags: 4 Real, 7 Wrong, 8 Trivial, 2 Locked — a Noise Rate of 81% — and the number-one field bottleneck (TTFB, p75 1.6 s) appears in none of them.” Adjudication compresses the roadmap: what arrived as 21 tickets of equal apparent urgency leaves as four fixes worth shipping, one discovered bottleneck worth escalating, and seventeen documented permissions to do nothing — each carrying the evidence a stakeholder needs to believe it.

8. What the framework is not

It is not “ignore PageSpeed Insights.” It is the opposite pole from both camps of Section 1: the report is treated as a competent screening instrument used correctly — as input to diagnosis, with follow-up, exactly as screening theory has always required (Wilson and Jungner, 1968).

It is not a new score. The framework produces verdicts about reports, not a rival number about pages. Field Core Web Vitals remain the ground truth of user experience; nothing here replaces them.

It is not fully automatable. Some verdicts mechanize cleanly (a flag whose own savings estimate is zero refutes itself). But the tests that matter most — intent, ownership, materiality at the margin — are judgments about what a resource is for and who controls it, which is precisely the layer automated analyzers cannot supply (Sadowski et al., 2018). The framework's discipline is not automation; it is rules of evidence binding the judge.

It is not vendor-specific. It is stated here for PSI because PSI is the screening instrument of record for the open web, but the two failure directions and the four verdicts apply unchanged to any automated performance report — a Lighthouse CI gate, a commercial scanner, an in-house dashboard.

9. Limitations

Four limitations bound the framework's claims, and stating them is part of the method.

Verdicts are judgments. Two competent adjudicators can disagree at the materiality margin. The mitigation is procedural, not rhetorical: verbatim evidence, a recorded falsification attempt, and a confidence grade on every row make any disagreement inspectable — a reader can re-run the same tests against the same artifacts.

Field truth is itself sampled. CrUX excludes iOS Chrome, WebViews, and non-Chrome browsers, and requires opt-in (Chrome Developers, n.d. b); its window is a trailing 28 days (Google, n.d. a). Field-anchored verdicts inherit these boundaries, and for Safari-heavy audiences the framework requires saying so rather than treating CrUX as the whole population. Where no field data exists at all, every user-impact claim is capped at medium confidence and labeled lab-derived.

Noise Rate is a per-site, per-run quantity. It is not a property of the tool in general, and any aggregate published across sites must disclose its sampling frame. Our own audit base skews toward sites that suspected a problem — a selection bias any future “noise index” must carry on its face.

Silence detection is bounded by the auditor. The framework finds the silences its decomposition looks for. It cannot certify the absence of problems that both the instrument and the auditor miss; it can only make the search for them explicit, field-first, and repeatable.

10. Questions we are asked

11. Why these names

Noise and silence are the classical Type I and Type II errors of detection theory (Neyman and Pearson, 1933), in words a site owner already owns: the report says too much that does not matter, and nothing about what does. Verdict — rather than “finding” or “recommendation” — because a verdict closes a case: every flag leaves adjudicated, none is left ambient to become next quarter's wasted sprint. The debts are acknowledged deliberately: screening medicine contributed the stance, signal detection the error structure, alarm-fatigue research the cost of ignoring it, and Google's own static-analysis program the standard — actionability, not technical correctness — by which flags deserve to be judged. What is new is where the instrument points: the audit of the report about the page.

Every audit we deliver is this framework executed end to end: every flag adjudicated, both metrics computed, every surviving fix predicted, proven, and confirmed on the field data's own clock.

References

1. Alahmadi, B.A., Axon, L. and Martinovic, I. (2022) ‘99% false positives: a qualitative study of SOC analysts' perspectives on security alarms’, Proceedings of the 31st USENIX Security Symposium. Boston, MA: USENIX Association. Available at: usenix.org (Accessed: 19 July 2026).
2. Altman, D.G. and Bland, J.M. (1994) ‘Statistics Notes: Diagnostic tests 2: predictive values’, BMJ, 309(6947), p. 102. Available at: doi.org (Accessed: 20 July 2026).
3. Chrome Developers (n.d. a) Lighthouse performance scoring. Available at: developer.chrome.com (Accessed: 19 July 2026).
4. Chrome Developers (n.d. b) Chrome UX Report: methodology. Available at: developer.chrome.com (Accessed: 19 July 2026).
5. Deloitte (2020) Milliseconds make millions: a study on how improvements in mobile site speed positively affect a brand's bottom line. Available at: thinkwithgoogle.com (Accessed: 19 July 2026).
6. Goldratt, E.M. and Cox, J. (1984) The goal: a process of ongoing improvement. Great Barrington, MA: North River Press.
7. Google (n.d. a) About PageSpeed Insights. Available at: developers.google.com (Accessed: 19 July 2026).
8. Google (n.d. b) PageSpeed Insights API: pagespeedapi method reference. Available at: googleapis.github.io (Accessed: 19 July 2026).
9. Google Search Central (2023) Introducing INP to Core Web Vitals. Available at: developers.google.com (Accessed: 19 July 2026).
10. Google Search Central (n.d.) Understanding page experience in Google Search results. Available at: developers.google.com (Accessed: 19 July 2026).
11. GoogleChrome Lighthouse (n.d.) Lantern [design documentation]. Available at: github.com (Accessed: 19 July 2026).
12. Green, D.M. and Swets, J.A. (1966) Signal detection theory and psychophysics. New York: Wiley.
13. Heckman, S. and Williams, L. (2011) ‘A systematic literature review of actionable alert identification techniques for automated static code analysis’, Information and Software Technology, 53(4). Available at: doi.org (Accessed: 20 July 2026).
14. HelpfulCrowd (n.d.) Why Google PageSpeed Insights don't reflect reality. Available at: helpfulcrowd.com (Accessed: 19 July 2026).
15. Jariyal, H., Rasam, P., Humaira and Grogg, A.T. (2025) ‘Performance’, in The 2025 Web Almanac. HTTP Archive. Available at: almanac.httparchive.org (Accessed: 19 July 2026).
16. Johnson, B., Song, Y., Murphy-Hill, E. and Bowdidge, R. (2013) ‘Why don't software developers use static analysis tools to find bugs?’, Proceedings of the 35th International Conference on Software Engineering (ICSE '13). San Francisco, CA: IEEE. Available at: doi.org (Accessed: 20 July 2026).
17. Lyrical Host (n.d.) Why you should ignore Google PageSpeed Insights. Available at: lyricalhost.com (Accessed: 19 July 2026).
18. Neyman, J. and Pearson, E.S. (1933) ‘On the problem of the most efficient tests of statistical hypotheses’, Philosophical Transactions of the Royal Society of London, Series A, 231, pp. 289–337. Available at: doi.org (Accessed: 20 July 2026).
19. Popper, K.R. (1959) The logic of scientific discovery. London: Hutchinson.
20. Sadowski, C., Aftandilian, E., Eagle, A., Miller-Cushon, L. and Jaspan, C. (2018) ‘Lessons from building static analysis tools at Google’, Communications of the ACM, 61(4), pp. 58–66. Available at: doi.org (Accessed: 20 July 2026).
21. Sendelbach, S. and Funk, M. (2013) ‘Alarm fatigue: a patient safety concern’, AACN Advanced Critical Care, 24(4), pp. 378–386. Available at: doi.org (Accessed: 20 July 2026).
22. Wang, X.S., Balasubramanian, A., Krishnamurthy, A. and Wetherall, D. (2013) ‘Demystifying page load performance with WProf’, Proceedings of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI '13). Lombard, IL: USENIX Association. Available at: usenix.org (Accessed: 20 July 2026).
23. web.dev (n.d. a) Interaction to Next Paint (INP). Available at: web.dev (Accessed: 19 July 2026).
24. web.dev (n.d. b) Time to First Byte (TTFB). Available at: web.dev (Accessed: 19 July 2026).
25. Wilson, J.M.G. and Jungner, G. (1968) Principles and practice of screening for disease. Public Health Papers No. 34. Geneva: World Health Organization. Available at: iris.who.int (Accessed: 20 July 2026).