Improve homepage LCP to 2.5s or less (production mobile baseline: 4.73s) #121

Problem

The original user-reported homepage LCP was 2.63 seconds. A subsequent production Lighthouse audit measured 4.73 seconds median mobile LCP for the root entry (three runs, including its redirect to /latest). Improve initial content rendering so the page reaches the good LCP threshold of 2.5 seconds or less, with enough headroom to avoid repeatedly crossing it.

The 2.63-second baseline was supplied by the user. Its measurement tool, device/network profile, authentication state, and lab-versus-field origin have not yet been recorded; confirm these before making before/after comparisons.

The recommended field target is LCP ≤2.5 seconds at the 75th percentile, assessed separately for mobile and desktop. LCP guidance

Relevant implementation

• apps/web/src/app/page.tsx checks authentication: guests are redirected to the public feed, while signed-in users receive the personal feed. Measure the actual homepage entry and resolved destination, including redirect/session overhead.
• scripts/ci/browser-performance-config.mjs already measures reader routes with three Lighthouse runs and a median 2,500ms LCP target. These timing assertions are advisory; the current route set includes /latest but not the root homepage entry.
• ArticleImage already supports eager loading and high fetch priority for priority images. Identify the actual LCP element before changing image-loading behavior.

Required investigation and improvements

• Reproduce the baseline against a production build and record URL/final destination, page content, browser/tool version, viewport, device/network/CPU settings, authentication state, and cache conditions.
• Identify the LCP element and capture its trace/network waterfall. Separate time to first byte, resource discovery delay, resource transfer duration, and element render delay where applicable.
• Check session/redirect and initial feed request latency, render-blocking CSS/fonts, above-the-fold image selection/sizing, JavaScript/hydration work, and third-party execution. Implement changes against the measured bottleneck.
• Make the primary content and any LCP resource discoverable early. Prioritize only the required above-the-fold resources, preserve lazy loading for lower content, and avoid duplicate downloads or broad preloading.
• Preserve feed freshness, personalization, authentication boundaries, image quality, article navigation, and engagement behavior. Cache optimizations must not share personalized content between users.
• Extend the existing performance measurement/reporting to cover the homepage entry and relevant destination. Keep the 2,500ms target visible and document the reproducible benchmark configuration; do not loosen budgets to make the result pass.

Acceptance criteria

• Capture repeatable before/after measurements under identical conditions, with at least five runs per comparison, reporting median, range, and the identified LCP element.
• The measured homepage path reaches median lab LCP ≤2.5 seconds in the agreed representative mobile and desktop profiles and improves on its reproduced baseline.
• Report guest and signed-in homepage behavior separately, including redirect overhead and cold/warm cache results.
• Where field data is available, assess mobile/desktop p75 LCP against the ≤2.5-second target; do not treat a Lighthouse median as field p75 or claim an immediate change to a historical field-data window.
• No material regression in layout stability, interactivity, initial transfer size, or functional behavior; retain existing applicable performance budgets.
• Add regression coverage for the changed loading/rendering behavior and verify responsive layout, feed loading, navigation, and authentication.
• For shared reader changes, run browser checks against the web app and both built Chrome and Microsoft Edge extensions, including image-loading and interaction behavior.

Production Lighthouse measurements — 2026-10-07

Audited the live production domain with Lighthouse 12.6.1 and Chrome 154.0.8037.97 in fresh anonymous profiles. Mobile uses default simulated network/4× CPU, 412×823 at DPR 1.75; desktop uses the desktop preset, 1350×940 at DPR 1. These lab measurements are not field p75 and are not necessarily comparable with the original 2.63-second figure.

All homepage reports returned a final HTTP 200, with no Lighthouse runtime/audit errors. Redirected runs warn that the final URL changed, as expected. The reported scores are lab observations, not a pass/fail target of 100.

The redirect alone is not the entire LCP problem. Track its removal in #122, server latency in #123, thumbnail sizing/compression in #124/#125, and unused CSS/JavaScript in #128/#129. Implement each measured fix under its individual issue and verify the resulting homepage LCP here. Do not add Lighthouse estimates together or claim a guaranteed speedup before measuring.