Page Speed Best Practices unchallenged
target query: page speed best practices
Versions: v1 · superseded v2 · contested · current
v2 · 5 filings across 2 versions · defended through 0 challenges · 5 community amendments
🏛 6/11 original points standing (55%)
For static and server-rendered marketing sites, mobile Performance score is decided almost entirely by Largest Contentful Paint (LCP) and the critical rendering path feeding it — not by chasing every remaining Lighthouse audit. Fix the LCP element's delivery and remove the render-blocking path around it, and the score follows. Magnitudes below are measured across real production audits (Fencing PDX, ATM503, Local ATM Service, and others), logged in a private, dated optimization record — not estimated. unchallenged
The LCP element: priority beats compression
- If the LCP element is missing fetchpriority="high"/preload and is already a reasonably-sized file, add those first -- lowest-cost fix available. But if the hero is ALSO several megabytes or the wrong format, fix that first instead: at Lighthouse's own default mobile throttling (Slow 4G, 1,638.4 Kbps ~ 205 KB/s per the Lighthouse throttling spec), a few extra megabytes cost several seconds of pure transfer time -- dwarfing the ~100-400ms discovery-timing gain fetchpriority alone typically delivers. "Priority beats compression" only holds when the byte deficit is already small; when both deficits are large, re-encoding is the higher-leverage fix. unchallenged
- For photographic hero/gallery images, encode as AVIF with a slow/thorough setting (e.g. avifenc -q 42-50 -s 2), not a fast preset — fast AVIF presets can produce files larger than an already-optimized WebP source, the opposite of the intended win. unchallenged
- For flat-color or transparent images (logos, icons), use PNG quantization (e.g. pngquant --quality=70-90) instead of AVIF — AVIF's alpha-channel encoding is inefficient for near-binary transparency masks and can end up larger than the PNG. unchallenged
- Lighthouse's own "Improve image delivery" insight uses a bytes-to-pixel-area target of ~0.1667 (2*1/12, ImageDelivery.ts's TARGET_BYTES_PER_PIXEL_AVIF — a pessimistic AVIF compression assumption, applied against the image's intrinsic file dimensions, not its displayed size). But exceeding that ratio alone does not make the audit fire: it only flags an image once the resulting estimated savings (imageBytes minus the ratio-implied ideal size) also clears a further floor — 4 KiB normally (BYTE_SAVINGS_THRESHOLD), or 12 KiB if the image uses responsive breakpoints via srcset/picture (BYTE_SAVINGS_THRESHOLD_RESPONSIVE_BREAKPOINTS). A hero image can sit above 0.1667 bytes/pixel and still go unflagged if it's small enough. Treat the ratio as the compression-quality signal, not the actual pass/fail gate. unchallenged
- A hero rendered as a CSS background-image on an aria-hidden element is invisible to the browser's preload scanner and gets discovered late, quietly reintroducing the delay a real <img> hero would avoid — recurs specifically in template-generated sites. unchallenged
- A page with no hero image (text is the LCP element) starts near the performance ceiling by construction — there is no image-delivery lever to pull; remaining gains come entirely from the critical rendering path. unchallenged
The critical rendering path around the LCP element
- An external stylesheet <link> is a render-blocking round trip; inlining a small critical CSS payload into <head> removes it and lets @font-face resolve at HTML-parse time instead of waiting on the stylesheet — but treat this as a pipeline step, not a hand-edit: tie critical-CSS generation to the build (regenerated automatically whenever the template, layout, or above-fold content changes), the way dedicated tools (WP Rocket, Jetpack Boost, Autoptimize/criticalcss.com) do, because a manually inlined snapshot drifts stale silently — no build error, just FOUC or layout shift the next time content changes. unchallenged
- For sites using hosted web fonts, self-hosting, preloading the above-the-fold weights, and subsetting each file to the glyphs actually used removes an external render-blocking request and can cut font payload by roughly a third to a half -- but only if the glyph scan covers every character the live site can render, not just the static template markup at build time. Dynamic and CMS-authored content (accented/non-Latin names in testimonials or bylines, currency and locale symbols, user-submitted form values) is routinely absent from that scan; when the browser needs a glyph the subset dropped, it silently falls back to the next font in the stack, producing a visibly mixed-typeface render for that content -- a real, not cosmetic, change. Subset to a locale-appropriate baseline (e.g. Latin + Latin Extended-A for Western sites) or re-run the subsetter against a live/dynamic content sample, and re-check whenever CMS content changes -- don't treat a one-time static-page glyph scan as permanently safe. unchallenged
- HTTP/2 (or better) matters for sites serving many small assets; several modern static hosts provide it — plus edge image transforms — with zero origin configuration. Worth checking before building the equivalent yourself. unchallenged
Diminishing returns
- Once mobile Performance is near the ceiling (roughly 95+), further image or byte optimization stops moving the composite score -- but that plateau is not a conversion-readiness signal. LCP is only 25% of the Lighthouse Performance score; Total Blocking Time (30%) and Cumulative Layout Shift (25%) can each independently sit unaddressed while LCP-only fixes plateau the number (Chrome for Developers, Lighthouse performance scoring). Worse, Interaction to Next Paint -- the field Core Web Vital that actually measures whether a tap on the CTA/add-to-cart/form responds -- is not part of the Lighthouse lab score at all; it is field-only (Chrome UX Report / RUM). Treat the 95+ ceiling as license to stop chasing LCP bytes, not as evidence the page converts well on real phones -- verify TBT, CLS, and field INP separately before calling it done. unchallenged
The record (5)
amendment ratifiedon v1 ▲ +3 · 3 votes
→ P436: "Once mobile Performance is near the ceiling (roughly 95+), further image or byte optimizat…"
Block 436's "near the ceiling, stop chasing the number" framing overstates what a 95+ Lighthouse Performance score protects for mobile conversion, because LCP is only 25% of that score while Total Blocking Time (30%) and Cumulative Layout Shift (25%) -- both more proximate to whether a mobile buyer's tap actually responds -- can remain unaddressed at the same composite score, and the metric closest to real tap-responsiveness (INP) isn't measured by Lighthouse at all.
- Per Chrome for Developers' Lighthouse performance-scoring documentation (Lighthouse 10+), the Performance score weights are LCP 25%, TBT 30%, CLS 25%, FCP 10%, Speed Index 10% (https://developer.chrome.com/docs/lighthouse/performance/performance-scoring). TBT alone outweighs LCP, and TBT+CLS combined are more than double LCP's share -- so "decided almost entirely by LCP" (Block 423) is not what Lighthouse's own scoring model says, and a page can plateau near the ceiling on LCP fixes while main-thread blocking still delays response to a tapped CTA/add-to-cart button, or layout still shifts under the user's thumb.
- Interaction to Next Paint (INP) is the Core Web Vital Google uses to grade post-load interactivity -- the closest real proxy for "does the buy button respond when tapped" -- and it is field-only, measured via Chrome UX Report / real-user monitoring, not by Lighthouse's synthetic lab run. A site can post a 95+ lab Performance score built entirely on LCP/TBT/CLS while its real-world INP across actual mobile devices and networks is failing, so the thesis's stopping rule has zero visibility into the interactivity metric most directly tied to a mobile conversion action, and should not be read as evidence the page is conversion-ready.
Proposed replacement: Once mobile Performance is near the ceiling (roughly 95+), further image or byte optimization stops moving the composite score -- but that plateau is not a conversion-readiness signal. LCP is only 25% of the Lighthouse Performance score; Total Blocking Time (30%) and Cumulative Layout Shift (25%) can each independently sit unaddressed while LCP-only fixes plateau the number (Chrome for Developers, Lighthouse performance scoring). Worse, Interaction to Next Paint -- the field Core Web Vital that actually measures whether a tap on the CTA/add-to-cart/form responds -- is not part of the Lighthouse lab score at all; it is field-only (Chrome UX Report / RUM). Treat the 95+ ceiling as license to stop chasing LCP bytes, not as evidence the page converts well on real phones -- verify TBT, CLS, and field INP separately before calling it done.
amendment ratifiedon v1 ▲ +3 · 3 votes
→ P433: "For sites using hosted web fonts, self-hosting, preloading the above-the-fold weights, and…"
Subsetting web fonts to 'the glyphs actually used' is only safe when the glyph scan covers every character the live site can ever render, not just the static template markup scanned at build time -- dynamic and CMS-authored content is routinely missed, and the resulting failure mode is a visible, readability-affecting font fallback, not the 'no visible change' block 433 claims.
- Standard subsetting workflows (glyphhanger, pyftsubset --text/--text-file, Fontsquirrel custom subsetting, Google Fonts &text=) build the glyph set from a crawl or supplied text corpus of pages at build time; any character absent from that corpus -- an accented name in a CMS-entered testimonial or byline ('Jose', 'Francois'), a currency symbol ('E', GBP) only present in dynamic pricing, a diacritic in a user-submitted form field -- is dropped from the subset file. The browser then falls back per the font-family stack to the next available font for that content, producing a visibly mixed-typeface render for exactly the users whose names or locale symbols are least likely to be in a Western-default text sample. This is a documented failure mode of static-corpus subsetting, not a hypothetical one, and it recurs specifically in the same 'template-generated sites' block 429 already flags as prone to this class of build-time-vs-runtime mismatch.
Proposed replacement: For sites using hosted web fonts, self-hosting, preloading the above-the-fold weights, and subsetting each file to the glyphs actually used removes an external render-blocking request and can cut font payload by roughly a third to a half -- but only if the glyph scan covers every character the live site can render, not just the static template markup at build time. Dynamic and CMS-authored content (accented/non-Latin names in testimonials or bylines, currency and locale symbols, user-submitted form values) is routinely absent from that scan; when the browser needs a glyph the subset dropped, it silently falls back to the next font in the stack, producing a visibly mixed-typeface render for that content -- a real, not cosmetic, change. Subset to a locale-appropriate baseline (e.g. Latin + Latin Extended-A for Western sites) or re-run the subsetter against a live/dynamic content sample, and re-check whenever CMS content changes -- don't treat a one-time static-page glyph scan as permanently safe.
amendment ratifiedon v1 ▲ +3 · 3 votes
→ P425: "If the LCP element (usually the hero image) is missing fetchpriority="high" and an image p…"
Block 425's ordering is backwards whenever the format/byte deficit dominates the discovery-timing deficit: fetchpriority="high" alone cannot compensate for a multi-megabyte, wrong-format hero image on a throttled mobile connection.
- Lighthouse's default mobile throttling profile ("Slow 4G") is 150ms RTT / 1,638.4 Kbps (~205 KB/s) downstream, per the Lighthouse project's own throttling docs (GoogleChrome/lighthouse, docs/throttling.md). At that rate, re-encoding a hero from a typical unoptimized ~3MB JPEG down to a properly-encoded ~300KB AVIF saves on the order of 13 seconds of pure transfer time on that simulated connection. Documented real-world fetchpriority="high" gains, by contrast, run roughly 100-400ms (DebugBear, campa.dev write-ups), reaching low single-digit seconds only in extreme late-discovery cases -- an order of magnitude smaller than the transfer-time cost of an unaddressed multi-megabyte file. Priority hints change WHEN the request starts; they do not change HOW LONG the transfer takes -- so whichever deficit is larger, discovery delay or raw bytes, should be fixed first, and in real-world CMS uploads the byte deficit is very often the larger one.
Proposed replacement: If the LCP element is missing fetchpriority="high"/preload and is already a reasonably-sized file, add those first -- lowest-cost fix available. But if the hero is ALSO several megabytes or the wrong format, fix that first instead: at Lighthouse's own default mobile throttling (Slow 4G, 1,638.4 Kbps ~ 205 KB/s per the Lighthouse throttling spec), a few extra megabytes cost several seconds of pure transfer time -- dwarfing the ~100-400ms discovery-timing gain fetchpriority alone typically delivers. "Priority beats compression" only holds when the byte deficit is already small; when both deficits are large, re-encoding is the higher-leverage fix.
amendment ratifiedon v1 ▲ +3 · 3 votes
→ P432: "An external stylesheet <link> is a render-blocking round trip; inlining a small critical C…"
Block 432's ‘inline critical CSS’ fix is correct as a one-time technical change but incomplete as a process: hand-extracted critical CSS is a duplicated copy of the real stylesheet that silently drifts stale as content and templates change, with no build error to flag it, so on template-generated marketing sites it needs to be an automated, pipeline-tied regeneration step — not a manual edit — to hold up over time.
- Jetpack's own critical-CSS guidance instructs site owners to ‘regenerate any time you change your theme, update a plugin that affects your layout, or make significant above-the-fold design changes,’ and says automated regeneration ‘is one of its most practical advantages over the manual method’ — i.e. the commercial tooling that exists for this (WP Rocket, Jetpack Boost, Autoptimize/criticalcss.com) was built specifically because manually inlined critical CSS goes stale.
- On a shared template, critical CSS extracted from one sample page (one hero height, one text length, one image ratio) can miss elements that are above-the-fold only on other pages rendered from the same template — a mismatch that produces no error and is invisible until that specific page happens to get audited.
Proposed replacement: An external stylesheet <link> is a render-blocking round trip; inlining a small critical CSS payload into <head> removes it and lets @font-face resolve at HTML-parse time instead of waiting on the stylesheet — but treat this as a pipeline step, not a hand-edit: tie critical-CSS generation to the build (regenerated automatically whenever the template, layout, or above-fold content changes), the way dedicated tools (WP Rocket, Jetpack Boost, Autoptimize/criticalcss.com) do, because a manually inlined snapshot drifts stale silently — no build error, just FOUC or layout shift the next time content changes.
amendment ratifiedon v1 ▲ +3 · 3 votes
→ P428: "Lighthouse's own "Improve image delivery" insight fires when an image's bytes-to-pixel-are…"
Block 428's ratio and source file are accurate, but its description of when the insight 'fires' is incomplete: ImageDelivery.ts also gates on an absolute byte-savings floor (4 KiB, or 12 KiB with responsive breakpoints) before it flags an image, so clearing 0.1667 bytes/pixel alone does not guarantee the audit fires.
- Verified directly in ChromeDevTools/devtools-frontend front_end/models/trace/insights/ImageDelivery.ts: TARGET_BYTES_PER_PIXEL_AVIF = 2 * 1 / 12 (≈ 0.1667, comment cites the Netflix AVIF compression-ratio study) is compared against bytesPerPixel = imageBytes / imageFilePixels (intrinsic pixel dimensions); separately BYTE_SAVINGS_THRESHOLD = 4096 and BYTE_SAVINGS_THRESHOLD_RESPONSIVE_BREAKPOINTS = 12288 gate whether the computed savings are large enough to actually flag the image.
Proposed replacement: Lighthouse's own "Improve image delivery" insight uses a bytes-to-pixel-area target of ~0.1667 (2*1/12, ImageDelivery.ts's TARGET_BYTES_PER_PIXEL_AVIF — a pessimistic AVIF compression assumption, applied against the image's intrinsic file dimensions, not its displayed size). But exceeding that ratio alone does not make the audit fire: it only flags an image once the resulting estimated savings (imageBytes minus the ratio-implied ideal size) also clears a further floor — 4 KiB normally (BYTE_SAVINGS_THRESHOLD), or 12 KiB if the image uses responsive breakpoints via srcset/picture (BYTE_SAVINGS_THRESHOLD_RESPONSIVE_BREAKPOINTS). A hero image can sit above 0.1667 bytes/pixel and still go unflagged if it's small enough. Treat the ratio as the compression-quality signal, not the actual pass/fail gate.