Repository navigation
Undim the banner link, and keep the preview probe out of first paint - #436
Merged
Merged
Conversation
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
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
1 participant
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.
Two home page fixes, and a correction to a number I reported earlier today.
The banner's link text was
text-white/85, which resolves to #d9e9fa on rgb(1,109,221): 4.01:1, under the 4.5 small text needs, and Lighthouse failed the page's colour contrast for it. At full white the same text measures 4.96:1, sampled from a strip of the banner where no text sits, and accessibility goes from 97 to 100. A test fails if the banner dims its link text again.StylePreviewfinds its resting frame by drawing seven frames and reading seven of them back, inside the first paint. The landing page mounts four previews, so that was 28 synchronous getImageData calls in front of the page settling. It now paints the start of the range immediately and does the probe when the browser is idle. Measured on a local production build at 6x CPU slowdown: 90ms blocked before, 80ms after. A real improvement, and a small one.The correction: I reported this morning that the home page scores 73 performance with 480ms blocked. Measured again just now, twice, it is 99 and 100 with 0ms blocked. The earlier runs were taken while this machine had 50 Chrome processes from my own verification work, and that contention went into the numbers rather than the page. I should have checked the conditions before calling it a product problem. Every other page measured 97 to 98 at the time, which was the clue I had and did not follow.
tsc and eslint clean, vitest 718 of 718.