docusaurus icon indicating copy to clipboard operation
docusaurus copied to clipboard

Improving image loading

Open johnnyreilly opened this issue 1 year ago • 2 comments

Have you read the Contributing Guidelines on issues?

Prerequisites

  • [X] I'm using the latest version of Docusaurus.
  • [X] I have tried the npm run clear or yarn clear command.
  • [X] I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
  • [X] I have tried creating a repro with https://new.docusaurus.io.
  • [X] I have read the console error message carefully (if applicable).

Description

This is not so much a bug as gathering useful points on image loading from the Hacker News discussion on https://johnnyreilly.com/2023/01/15/how-i-ruined-my-seo

https://news.ycombinator.com/item?id=34389421

image

You don't have to get 100 score, but passing the core web vitals score and having higher score on mobile is recommended Note that they don't have a CWV score yet due to low traffic. But a 39 performance score from the simulated Lighthouse is often more than enough for a passing grade. That is: if a Moto G4 can do OK, your normal users will likely do great.

For instance, a site I made[0] has a 22 from Lighthouse, but a passing CWV grade, so further improvement to the LCP, FID, and CLS would confer no direct Google SEO benefit.[1] (But it may help things like bounce rate, which may confer second-order benefits)

by removing the lazy load effect from the LCP

Indeed. Even better, making it high priority instead of normal: https://addyosmani.com/blog/fetch-priority/

The proposal is: for the first image in a post, we use fetchpriority="high" as documented in @addyosmani's post. And possibly remove loading="lazy" for that image - although removing may not be necessary

Reproducible demo

No response

Steps to reproduce

n/a

Expected behavior

n/a

Actual behavior

n/a

Your environment

  • Public source code:
  • Public site URL:
  • Docusaurus version used:
  • Environment name and version (e.g. Chrome 89, Node.js 16.4):
  • Operating system and version (e.g. Ubuntu 20.04.2 LTS):

Self-service

  • [X] I'd be willing to fix this bug myself.

johnnyreilly avatar Jan 15 '23 18:01 johnnyreilly

I've implemented an approach to tackle this on my blog:

https://johnnyreilly.com/2023/01/18/docusaurus-improve-core-web-vitals-fetchpriority

It does 2 things:

  • swizzles the img component to opt out of lazy loading
  • implements a rehype plugin which sets fetchpriority on the first image and lazy loading on the rest

It would be good to get this into Docusaurus if it makes sense - the question is: does it? And if it does, what sort of implementation makes sense?

johnnyreilly avatar Jan 18 '23 13:01 johnnyreilly

I'd prefer to work on this after MDX 2 lands because multiple remark plugins had to be modified already in the WIP PR

Also it's still not 100% clear to me what should be done 🤪 Maybe we should ping Addy or some perf guru to be sure what we plan to implement actually improve things.

It's hard to know for sure what should be done and what's the impact for each doc. Some posts might have the 1st image under the fold, some might have multiple images above the fold 🤪

slorber avatar Jan 19 '23 11:01 slorber

Yeah it's hard to know if there is a reliable approach that could be applied to pages / blogs en masse. The approach I have works for me, but I don't know if it's general enough. I really don't know enough.

@addyosmani if you care to weigh in, we're trying to work out if Docusaurus (a general purpose documentation / blogging tool) could apply fetchpriority to LCP images in a reliable way. Maybe that's not something that's we can generally apply? In my case, I have a blog with a reliable hero image and so it works in my case. But maybe it can't be applied to all.

johnnyreilly avatar Jan 19 '23 19:01 johnnyreilly