docs(evidence): re-verify render-blocking finding b8f6046e942a against current main and live (2026-08-11) - #115
Conversation
…t current main and live
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
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.
📝 WalkthroughWalkthroughThe PR adds a closeout verification receipt for Google Fonts loading. It records passing CI results, delayed stylesheet measurements, live Chromium results for six pages, and production CSP compatibility. ChangesFont loading verification
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b00065f041
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| On the unthrottled live run the preloaded css2 (a non-blocking style preload, | ||
| fetched at preload priority from the first byte) can finish before | ||
| first-contentful-paint lands on the homepage (388ms FCP vs 473ms css2 end) — | ||
| the same ordering the 2026-08-09 and 2026-08-10 runs showed (692 vs 491 and | ||
| 1036 vs 631 on home). That is timing, not blocking: the deterministic |
There was a problem hiding this comment.
The stated ordering contradicts both the new measurement and the cited earlier runs: on 2026-08-11, FCP at 388 ms occurs before the css2 response ends at 473 ms, while the earlier 692/491 and 1036/631 measurements show css2 finishing before FCP. As written, the evidence receipt interprets the new numbers backward and incorrectly calls these opposite orderings the same, so either the table values or this explanation needs correction.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/evidence/render-blocking-fonts-2026-08-08.md`:
- Around line 263-269: Update the live timing explanation in the evidence
document to accurately state that the homepage FCP at 388ms occurred 85ms before
css2 completed at 473ms, contrasting it with the later runs where css2 completed
before FCP. Preserve the conclusion that the delayed-css2 run demonstrates css2
is non-blocking.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 6a3a1f51-04fb-41b5-ae9a-844719e0a42e
📒 Files selected for processing (1)
docs/evidence/render-blocking-fonts-2026-08-08.md
| On the unthrottled live run the preloaded css2 (a non-blocking style preload, | ||
| fetched at preload priority from the first byte) can finish before | ||
| first-contentful-paint lands on the homepage (388ms FCP vs 473ms css2 end) — | ||
| the same ordering the 2026-08-09 and 2026-08-10 runs showed (692 vs 491 and | ||
| 1036 vs 631 on home). That is timing, not blocking: the deterministic | ||
| delayed-css2 run above paints ~2.3s before the css2 response arrives, so | ||
| first paint cannot be waiting on it. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Correct the live timing explanation.
388ms FCP < 473ms css2 responseEnd, so the homepage painted 85ms before css2 completed. This is the opposite ordering from the earlier runs (692 > 491 and 1036 > 631). Update this text so it matches the measured values. The delayed-css2 run supports the non-blocking conclusion.
Proposed wording
- On the unthrottled live run the preloaded css2 ... can finish before
- first-contentful-paint lands on the homepage (388ms FCP vs 473ms css2 end) —
- the same ordering the 2026-08-09 and 2026-08-10 runs showed ...
+ On the unthrottled live run, the homepage reached first-contentful-paint
+ 85ms before css2 completed (388ms FCP vs 473ms css2 end), unlike the
+ 2026-08-09 and 2026-08-10 runs. That timing is not evidence of blocking;
+ the deterministic delayed-css2 run above establishes the non-blocking behavior.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| On the unthrottled live run the preloaded css2 (a non-blocking style preload, | |
| fetched at preload priority from the first byte) can finish before | |
| first-contentful-paint lands on the homepage (388ms FCP vs 473ms css2 end) — | |
| the same ordering the 2026-08-09 and 2026-08-10 runs showed (692 vs 491 and | |
| 1036 vs 631 on home). That is timing, not blocking: the deterministic | |
| delayed-css2 run above paints ~2.3s before the css2 response arrives, so | |
| first paint cannot be waiting on it. | |
| On the unthrottled live run, the homepage reached first-contentful-paint | |
| 85ms before css2 completed (388ms FCP vs 473ms css2 end), unlike the | |
| 2026-08-09 and 2026-08-10 runs. That timing is not evidence of blocking; | |
| the deterministic delayed-css2 run above establishes the non-blocking behavior. |
🧰 Tools
🪛 LanguageTool
[grammar] ~265-~265: Ensure spelling is correct
Context: ...contentful-paint lands on the homepage (388ms FCP vs 473ms css2 end) — the same order...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/evidence/render-blocking-fonts-2026-08-08.md` around lines 263 - 269,
Update the live timing explanation in the evidence document to accurately state
that the homepage FCP at 388ms occurred 85ms before css2 completed at 473ms,
contrasting it with the later runs where css2 completed before FCP. Preserve the
conclusion that the delayed-css2 run demonstrates css2 is non-blocking.
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.
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.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a4a56330e9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Re-verified against the current origin/main head (9302611, "fix(public): serve | ||
| rel=icon favicon on every page so browsers stop 404ing /favicon.ico", merged | ||
| 2026-08-11) after the commits that landed since the 2026-08-10 closeout — |
There was a problem hiding this comment.
This receipt calls 9302611 the current origin/main head, but the reviewed commit is based on 883e106, which already contains nine later commits. In particular, 18128e8 changes brief-requested.html, one of the six measured pages, and later commits change audit.html; therefore the recorded browser and live measurements do not verify the code this commit is documenting as the current head. Re-run the checks against the actual base or explicitly limit the conclusion to 9302611.
Useful? React with 👍 / 👎.
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.
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.
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.
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.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4114349b0e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| render-blocking shape; the full test suite passes on this head (`npm test`, | ||
| 92 tests across heading hierarchy, sitemap, worker contract, UI contract and | ||
| product contract, plus the static source guards — "TinyStudio.io checks |
There was a problem hiding this comment.
At the explicitly named revision 9302611, the five Node test files contain 6 heading, 7 sitemap, 42 worker, 16 UI, and 8 product-contract tests—79 total, not 92. Consequently this reported result cannot be reproduced on the revision the receipt claims to verify and suggests the output came from a different checkout; record the actual output from 9302611 or rerun the suite on the intended revision.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
1 participant
What
Re-verification lane for dogfood finding b8f6046e942a ("Render-blocking resources on home"). The finding was closed on 2026-08-08/09/10; since the 2026-08-10 closeout at 536b3c9, ~30 commits landed on main, including several that touch the public pages and the worker (favicon rel=icon link, intake labels, search-intent bridge, retired-Agent-Desk worker corrections, CSS fixes, canonical/JSON-LD edits). This lane re-confirms the guarantee against the current head (9302611) and the live deployment.
Verification
npm run check:render-blockingon the working tree at 9302611 — real Chromium, production CSP, css2 intercepted and delayed 2500ms, stubbed response. All six pages PASS: css2 non-blocking, FCP never waits for it (homepage 224ms vs css2 at 2500ms), no render-blocking resources other than same-origin stylesheets, promoted sheet applied.npm test— 92 tests (headings 6, sitemap 7, worker 55, ui 16, contract 8) plus static source guards ("TinyStudio.io checks passed"), 0 failures.Result
Finding b8f6046e942a remains closed on the code side (PRs #20/#23), in CI (
npm run check:render-blocking), and against the live site. No further changes needed; this PR adds the 2026-08-11 re-verification receipt todocs/evidence/render-blocking-fonts-2026-08-08.mdfollowing the established per-lane pattern.Summary by CodeRabbit