Perf/lighthouse mobile 546#548
Open
vanshika2720 wants to merge 9 commits into
Open
Conversation
Lighthouse (mobile) reported invalid heading order and no main landmark on the homepage. The page rendered four <h1> elements (Hero, Why Volcano, Rich Framework Support, Recent Posts) and jumped straight from h1 to h3 for card titles, skipping h2. Custom pages built with Docusaurus's generic Layout are also not wrapped in a <main> element, unlike doc pages. Demote the section headings to h2, keeping the Hero's "Volcano" title as the page's only h1, and wrap the homepage sections in <main> so the document has exactly one main landmark. Signed-off-by: Vanshika <[email protected]>
Lighthouse (mobile) flagged two footer links (#f05545 on the #2b2a2b footer background) at a 4.14:1 contrast ratio, below the 4.5:1 required for normal text. Lightening the link color to #f26b58 alone dropped its contrast against the surrounding white paragraph text to 2.99:1, which trips a related check requiring inline links to be distinguishable from body text by either contrast or a non-color cue. Use #f26b58 (4.78:1 against the footer background) and make the underline permanent instead of hover-only, satisfying both checks regardless of the exact color contrast against the paragraph text. Signed-off-by: Vanshika <[email protected]>
Lighthouse (mobile) reported ~40 <img> elements without explicit width/height (navbar logo, footer logo, framework and supporter logos), which lets the browser reserve no layout space for them before they load. The Supporters component already tracked per-logo width/height in its data array but never passed them to the <img> tag; wire them through. Add the same width/height fields to the Frameworks logo data, and set width/height on the navbar and footer logos in docusaurus.config.js (both natively supported by Docusaurus's Logo component and theme footer markup). Signed-off-by: Vanshika <[email protected]>
Lighthouse (mobile) reported these logos as far larger than their displayed size, e.g. ray_logo.png was 4726x1478 for a ~258x81 rendered box, and volcano_argo-horizontal-color.png was 1500x1500 for ~100x100. Resize each to roughly twice its rendered size (sufficient for retina displays) while keeping the PNG format and visual appearance; combined size drops from ~485 KiB to ~114 KiB. Signed-off-by: Vanshika <[email protected]>
Lighthouse (mobile) flagged banner_02.png (1920x541, 1.22 MiB) and bg_1.png (1920x652, 839 KiB) as the largest contributors to page weight and LCP/Speed Index, recommending a modern image format. Re-encode both as WebP at quality 80 with no visible difference, cutting combined size by ~94% (2.06 MiB -> 127 KiB), and update the frameworks section's CSS background-image reference accordingly. Signed-off-by: Vanshika <[email protected]>
The hero heading is Lighthouse's LCP candidate on the homepage, but Chrome attributes its paint time to the hero-container's CSS background-image, and a background-image url() is only discovered after the stylesheet that declares it has downloaded and parsed — Lighthouse's LCP request discovery check flagged it as not discoverable from the initial HTML and unable to carry a priority hint. Render the hero background as a real <img> (object-fit: cover, absolutely positioned behind the text, alt="" since it is purely decorative) so it is discoverable by the HTML preload scanner immediately, and mark it fetchpriority="high" plus a matching <link rel=preload> so the browser fetches it in parallel with the render-blocking CSS instead of after it. Signed-off-by: Vanshika <[email protected]>
Lighthouse (mobile) reported 'Use efficient cache lifetimes' for every asset, since Netlify's default caching leaves cache lifetime to the browser and this site set no explicit policy. Add a Netlify _headers file (same mechanism this repo already uses for _redirects): webpack's content-hashed assets under /assets/* are safe to cache indefinitely, since any change produces a new URL; unhashed images under /img/* get a one-week cache instead, since a replaced file would keep the same URL. Signed-off-by: Vanshika <[email protected]>
React DOM 19's server renderer automatically emits a <link rel=preload as=image> for every <img> it encounters during SSR, unless that image has loading="lazy". On the homepage this meant all 35+ framework/supporter/author-icon logos - every one of them below the fold - were being fetched at high priority alongside the actually critical resources (render-blocking CSS, hero image), even though native lazy-loading was never engaged for any of them. Add loading="lazy" to the Frameworks, Supporters, and blog author icon images (leaving the above-the-fold navbar logo and the hero's LCP image untouched). This both defers their fetch until they near the viewport and, as a side effect of the React behavior above, removes the 35+ unnecessary preload hints competing with the critical path. Lighthouse mobile: LCP 8.5s -> 6.9s, Speed Index 2.5s -> 1.4s, TTI 9.3s -> 8.1s, total transfer 1.82MB -> 1.39MB, Performance 75 -> 76, with Accessibility/Best Practices/SEO unchanged at 100. Signed-off-by: Vanshika <[email protected]>
Lighthouse mobile still flagged banner_02.webp (image-delivery-insight, Est savings of 27 KiB) after the prior WebP conversion at quality 80. LCP breakdown analysis (Lighthouse's lcp-breakdown-insight under real network throttling) shows Resource Load Duration accounts for ~70 percent of the 6.9s LCP time - the hero image is the LCP element itself, so bytes shaved off its own transfer size translate directly into faster LCP, unlike savings on non-critical resources. Re-encoded both backgrounds from their original source PNGs (avoiding double lossy compression) at quality 65 instead of 80. Side-by-side comparison at full desktop resolution (1920px) shows no visible difference for either image - both are soft, gradient-heavy photographic renders that compress cleanly, and bg_1 additionally sits under a rgba(0,0,0,0.7) CSS overlay that further masks any artifacts. Combined size: banner_02.webp 78KB -> 56KB, bg_1.webp 48KB -> 37KB (~33KB total). Verified with Lighthouse mobile: Performance 75 -> 77, LCP 7.3s -> 6.9s, Speed Index 3.0s -> 1.4s, with Accessibility/Best Practices/SEO unchanged at 100. Signed-off-by: Vanshika <[email protected]>
volcano-sh-bot
added
the
kind/cleanup
Collaborator
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
volcano-sh-bot
added
the
size/L
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces several performance and SEO optimizations to the landing page, including preloading the hero banner image in WebP format, adding lazy loading and explicit dimensions to various images, restructuring heading tags for better semantic hierarchy, wrapping the main content in a <main> tag, and adding cache-control headers for static assets. The review feedback suggests addressing React console warnings by changing the fetchpriority attribute to camelCase (fetchPriority) in the Hero component.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Author
7 tasks
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
2 participants
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.
Please check if the PR fulfills these requirements
What kind of change does this PR introduce?
/kind cleanup
What this PR does / why we need it
This PR improves the Volcano website's Lighthouse Mobile Performance and Accessibility by addressing several actionable, low-risk optimizations identified during investigation.
Accessibility improvements
<main>landmark where appropriate.Performance improvements
Lighthouse results
Additional improvements observed during testing:
Investigation Summary
While working on this issue, I investigated the remaining Lighthouse opportunities in detail.
The remaining Performance bottleneck is not caused by the homepage itself, but primarily by Docusaurus's shared application bundle and global stylesheet.
The largest contributors are:
main.jsapplication bundle (~771 KB)These compete with the hero image during initial page load under Lighthouse's mobile throttling model and dominate the remaining LCP time.
I investigated a number of possible optimizations, including:
The changes that were safe and measurable have already been included in this PR.
The remaining opportunities would require framework-level or architectural changes (such as custom code splitting, critical CSS extraction, or adopting Docusaurus' experimental faster bundler), which would significantly increase the scope of this PR.
Which issue(s) this PR fixes
Fixes #546
Notes for reviewers
The issue requests achieving a Lighthouse Mobile Performance score of 90+.
After implementing and validating the practical optimizations available within the current architecture, the score improved from 72 → 77, while Accessibility improved from 93 → 100 and Best Practices/SEO remain 100.
Based on the investigation, reaching 90+ does not appear feasible without introducing larger architectural or build-system changes (for example, custom bundle splitting, critical CSS extraction, or migrating to Docusaurus' experimental faster build pipeline).
If the maintainers would prefer pursuing those larger changes, I'm happy to continue working on a follow-up PR focused specifically on those architectural optimizations.