Describe the bug
ROR site scores 64–67 in Lighthouse Performance, with a modeled LCP of about 23 seconds and a 6.17 MiB transfer.
To Reproduce
- Open https://ror.org/ in Chrome Incognito.
- Run Lighthouse for Mobile -> Performance.
- Observe a score around 64–67 and LCP around 23 seconds.
Expected behavior
The homepage should score above 90, with LCP at or below 2.5 seconds.
Device information:
- Device type: Desktop, mobile emulation
- OS: macOS
- Browser: Chrome
- Version: 151.0.7922.172
Additional context
I confirmed this low score across all envs with Lighthouse 13. All three scored 67 with approximately 23 seconds LCP, 0 ms TBT, and a 6.17 MiB initial transfer (5.68 MiB images). Production-only Matomo doesn't look to be implecated at all.
- The LCP element is
static/img/ROR_Lions_Banner.jpg, which is a 3135×1567, 2.73 MiB JPEG loaded as a CSS background by themes/hugo-ror/layouts/_partials/landingbanner.html. It doesn't have any responsive source or fetch-priority hint. I tested mocking up a 1600 px WebP proof of concept conversion and this was about ~102 KiB.
- Below-fold feature and recent-post images are CSS backgrounds in
_partials/homepage_features.html and _partials/recent_posts.html, so they load eagerly and cannot make use of any native image lazy-loading.
static/img/ror-logo.svg is 951 KiB raw because it contains embedded Adobe Illustrator data. A proof SVGO pass reduced it to approximately 2 KiB.- Lighthouse reports that approximately 96% of
hugo-ror.css unused on the homepage and estimates 1.54 seconds of render-blocking savings. head.html compiles Sass without explicitly minifying or fingerprinting the result and also loads full Font Awesome and Material Icons resources.
Suggested fixes:
- Generate responsive WebP/AVIF variants during the Hugo build. So, render the hero as
<picture>/<img> with srcset, sizes, dimensions, and fetchpriority="high". If we truly need to keep in the background, preload the appropriate responsive source.
- Render below-fold feature and post images as
<img loading="lazy" decoding="async"> and provide appropriately sized sources.
- Optimize the logo with SVGO and make sure it renders identically.
- Minify and fingerprint generated CSS/assets. Reduce or subset unused Bootstrap/theme and icon CSS where practical.
- Configure HTML for revalidation/no-cache and fingerprinted assets with
Cache-Control: public, max-age=31536000, immutable. Do not apply immutable caching to the current stable filenames.
- Load the legacy scripts in
_partials/scripts.html conditionally or with defer where safe (not really a priority ATM because current TBT is 0 ms).
- Possibly add a Lighthouse CI performance or similar check to prevent regressions.
Acceptance criteria:
- Mobile Lighthouse Performance score is at least 90 across repeated runs.
- LCP is at most 2.5 seconds, FCP at most 1.8 seconds, TBT at most 200 ms, and CLS at most 0.1.
- Initial homepage transfer is below 1 MiB on the Lighthouse mobile profile.
- Fingerprinted assets return long-lived immutable cache headers. HTML remains revalidated.
- No visual or accessibility regressions on mobile and desktop versions of the site.
Describe the bug
ROR site scores 64–67 in Lighthouse Performance, with a modeled LCP of about 23 seconds and a 6.17 MiB transfer.
To Reproduce
Expected behavior
The homepage should score above 90, with LCP at or below 2.5 seconds.
Device information:
Additional context
I confirmed this low score across all envs with Lighthouse 13. All three scored 67 with approximately 23 seconds LCP, 0 ms TBT, and a 6.17 MiB initial transfer (5.68 MiB images). Production-only Matomo doesn't look to be implecated at all.
static/img/ROR_Lions_Banner.jpg, which is a 3135×1567, 2.73 MiB JPEG loaded as a CSS background bythemes/hugo-ror/layouts/_partials/landingbanner.html. It doesn't have any responsive source or fetch-priority hint. I tested mocking up a 1600 px WebP proof of concept conversion and this was about ~102 KiB._partials/homepage_features.htmland_partials/recent_posts.html, so they load eagerly and cannot make use of any native image lazy-loading.static/img/ror-logo.svgis 951 KiB raw because it contains embedded Adobe Illustrator data. A proof SVGO pass reduced it to approximately 2 KiB.hugo-ror.cssunused on the homepage and estimates 1.54 seconds of render-blocking savings.head.htmlcompiles Sass without explicitly minifying or fingerprinting the result and also loads full Font Awesome and Material Icons resources.Suggested fixes:
<picture>/<img>withsrcset,sizes, dimensions, andfetchpriority="high". If we truly need to keep in the background, preload the appropriate responsive source.<img loading="lazy" decoding="async">and provide appropriately sized sources.Cache-Control: public, max-age=31536000, immutable. Do not apply immutable caching to the current stable filenames._partials/scripts.htmlconditionally or withdeferwhere safe (not really a priority ATM because current TBT is 0 ms).Acceptance criteria: