fix(pwa): Lighthouse pass — accessibility 100, deduped fetches (#28) - #95
Merged
Merged
Conversation
…tches (#28) Mobile Lighthouse on the static export: accessibility 0.96 → 1.00 on / and /library (active tab label and active filter chip now use the accent-strong token for AA contrast; wordmark links no longer carry a redundant aria-label), performance 0.56 → 0.83 on / after deduplicating concurrent manifest and proverb fetches that loaded the same JSON two or three times on first paint. Installability checks all pass. Performance on /library stays at 0.64 locally, dominated by LCP render delay under a single-threaded HTTP/1.1 test server plus the analytics round trip; a true reading needs a run against the deployed site. Signed-off-by: Devu Dilip <devu.dilip@gmail.com>
Deploying sirigannada with
|
| Latest commit: |
902c27a
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://60c88343.sirigannada.pages.dev |
| Branch Preview URL: | https://fix-lighthouse-pass.sirigannada.pages.dev |
On the deployed site the 171 KB gtag script was the largest download on every page and finished before the fonts. lazyOnload defers it until after load and idle, keeping first paint free of third-party work. Very short visits may go uncounted; Cloudflare Web Analytics still sees them. Signed-off-by: Devu Dilip <devu.dilip@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linked issue
Refs #28 (
accepted). Partial: the installability and accessibility targets are met; performance ≥ 90 is not reached in a local run and needs a measurement against the deployed site (Cloudflare, HTTP/2) before deciding on further work.What changed and why
Mobile Lighthouse on the static export, before → after:
//libraryfetch()calls for the books manifest, picture-book manifest and proverbs file loaded the same JSON two or three times on first paint; each loader now shares one in-flight promise.Remaining, for an owner decision: the same coral-on-ivory pattern in shared
Button/LinkButtonand about a dozen components (a separate audit), and whether to defer the analytics tag, which is the largest third-party cost on first paint. The largest remaining opportunity Lighthouse reports is unused JavaScript from route prefetching.Checklist
npm run typecheckcleannpm testgreen (662)next buildgreen; Lighthouse run against the exportUpdate (owner decision)
Owner agreed to defer the analytics tag: the GA4 script now loads with
lazyOnload(after load and idle) instead ofafterInteractive. On the deployed v0.3.0 it was the largest download on every page (171 KB) and finished before the fonts. Cloudflare Web Analytics still counts very short visits.Deployed-site Lighthouse (mobile, v0.3.0, before these PRs): home perf 0.74 / LCP 5.3 s, library perf 0.73 / LCP 8.7 s. Library LCP is the first picture-book cover, which only starts after the client-side manifest fetch; that is the next step for #28 (render first covers from build-time data) and will be a separate PR.