docs(evidence): re-verify render-blocking finding b8f6046e942a against current main and live - #69
Conversation
…t current main and live The code-side fix (PR #20) and CI enforcement (PR #23) for dogfood finding b8f6046e942a ("Render-blocking resources on home") are merged in origin/main; this lane re-verified the guarantee on the current head (536b3c9, 2026-08-10) after the commits that landed since the 2026-08-09 closeout (sitemap, preferred source pages, Agent Desk de-index, tap targets, CI runners): - npm run check:render-blocking passes on all six pages (real Chromium, production CSP, css2 delayed 2500ms): css2 non-blocking, first paint never waits for it, no render-blocking resources other than the site's own same-origin stylesheets, promoted sheet applied. - Fresh live measurement of the deployed pages confirms the same: css2 non-blocking on all six pages, only same-origin stylesheets render-block, fonts still load and apply under the production CSP. - Full npm test (82 tests) passes on this head. The receipt now records the re-verification on the current head so the tracker item can close.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 21 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Comment |
What
Dogfood finding [b8f6046e942a] Render-blocking resources on home (audit
20260808T074205Z-msk2fl3n) was already fixed on the code side (PR #20), CI-enforced (PR #23), and closed out with evidence (PR #35) — but the tracker still lists the item. This lane re-verified the guarantee against the currentorigin/mainhead (536b3c9, 2026-08-10) so the finding can close on the current head rather than the 2026-08-09 one the receipt previously referenced.Commits landed since the last closeout and their exposure to the guarantee:
cd9184csitemap (no page resources),95d2248preferred source pages (llms.txt/offer.md only),c5e2f2bAgent Desk de-index (head meta/JSON-LD text, no new resources),ac05bectap targets (CSS padding only), CI-runner commits (no public assets).Verification (all on 536b3c9 working tree)
npm run check:render-blocking— all six pages PASS (real Chromium, production CSP, css2 intercepted + delayed 2500ms, stubbed response): css2 non-blocking, first paint never waits for it, only same-origin stylesheets render-block, promoted sheet applied.npm test— full suite passes (82 tests, 0 failures).Change
docs/evidence/render-blocking-fonts-2026-08-08.md: appended "Closeout re-verification (added 2026-08-10)" section with the current-head browser result, the live measurement table, and the FCP-vs-css2-end timing note (unthrottled preload can finish before FCP — the delayed-css2 run is the deterministic non-blocking proof).No production code changes; the fix shape itself (preload + same-origin
fonts.jspromotion + noscript fallback) is untouched and still guarded by static checks and the CI browser step.