[Performance] Eliminate Desktop LCP Delay by Pre-rendering Hero Video Thumbnail in SSR

[PARTH-TUSSLE]

Current Behavior

Desktop Largest Contentful Paint (LCP) on https://layer5.io/ fails Core Web Vitals at 3.2s (CrUX 75th percentile) and 7.2s in Lighthouse lab tests.

PageSpeed Insights diagnostics reveal:

• LCP Element: <div class="react-player__preview"> inside the hero column (div.embedVideo)
• Resource Load Delay: 4,986 ms — the browser waits ~5 seconds before starting to fetch the LCP element.
• Element Render Delay: 3,588 ms
• Discovery Insight: Request is discoverable in initial document: false

Root Cause

In index.js (around lines 90–132), the entire video column is hidden during Gatsby Server-Side Rendering (SSR) behind a client-side mount check:

{hasMounted && window.innerWidth > 760 && (
  <Col $sm={4} $lg={6} className="section-title-wrapper video-col">
    ...
    <ReactPlayer ... light={videoThumbnail} />
  </Col>
)}

Because the video column does not exist in the initial HTML payload, the browser cannot discover or fetch the hero preview until the JavaScript bundles have been downloaded, parsed, executed, and hydrated.

This creates a significant LCP resource discovery delay.

Desired Situation

The desktop hero preview should be discoverable by the browser from the initial HTML generated during Gatsby SSR.

The desktop hero preview should be discoverable early enough to avoid delaying the LCP resource, without introducing hydration mismatches, layout shifts, or regressions to the existing hero video experience.

Acceptance Criteria

• The desktop hero preview is present in the initial SSR HTML response.
• Lighthouse reports Request is discoverable in initial document: true for the LCP resource.
• Desktop LCP resource load delay is reduced from ~5 seconds to <400ms.
• Desktop Lighthouse LCP improves to ≤ 2.5s.
• No new CLS or hydration mismatch is introduced.
• Existing hero video functionality continues to work after hydration/user interaction.

Performance Evidence

Current Desktop Metrics

Metric	Current Value
CrUX LCP (75th percentile)	3.2s
Lighthouse LCP	7.2s
Resource Load Delay	4,986ms
Element Render Delay	3,588ms
Performance Score	15/100

The primary Lighthouse finding is that the desktop LCP resource is not discoverable in the initial document.

Mobile Comparison

Mobile currently passes Core Web Vitals, with an LCP of 1.9s in CrUX.

The mobile implementation already renders an image directly in the SSR HTML, allowing the browser to discover the resource without waiting for client-side hydration.

This issue is therefore primarily focused on the desktop rendering path.

---

Related Screenshot

---

Contributor Resources and Handbook

The layer5.io website uses Gatsby, React, and GitHub Pages. Site content is found under the master branch.

• 📚 See contributing instructions.
• 🎨 Wireframes and designs for Layer5 site in Figma (open invite)
• 🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack.

Join the Layer5 Community by submitting your community member form.

[afshan-khan549]

Hi @PARTH-TUSSLE, I’d like to work on this issue. Could you please assign it to me if it’s still available?

[Bryandero98]

I'd like to work on this — plan: keep <ReactPlayer> exactly as gated today (client-only, after hasMounted, so there's no new SSR-safety risk for the player library itself), but always render the .video-col structurally and replace the current window.innerWidth > 760 JS gate with a server-rendered <picture> stand-in (matching ReactPlayer's own light-mode preview markup/CSS) for the pre-hydration state. <picture><source media="(min-width: 768px)"> keeps the real ~200KB thumbnail out of mobile's payload entirely (the existing .video-col{display:none} CSS rule at max-width:767px already handles hiding it there), while making the desktop LCP image discoverable in the initial HTML via the browser's preload scanner. Could you assign this to me?