[website] Improve rebranding homepage performance

[siriwatknp]

Preview: https://deploy-preview-27838--material-ui.netlify.app/branding/home/

Changes

• remove font blocking resource (will be in another PR before switching to mui.com)
• code splitting the showcase components in Hero
• lazy load each section below the fold using react-intersection-observer
• optimize some images
• optimize PlusJakartaSans (40kB -> 7kB) and improve UX with preload (no more font swap!)

Summary

Desktop

WebVitals Metric	Before	After
LCP (ms)	1334	576
CLS	0.001	0.001
TBT (ms)	1245	384

Full test (Before, After)

Mobile

WebVitals Metric	Before	After
LCP (ms)	3395	903
CLS	0.049	0.062
TBT (ms)	4303	1606

Full test (Before, After)

Comparison between /branding/home/ & /

Before improvement

index is faster than rebranding

index	rebranding

Full test link

After improvement

Both routes are faster than before because font blocking resource is changed to async. Rebranding is a bit faster than index 🎉

index	rebranding

Full test link

• I have followed (at least) the PR section of the contributing guide.

[mui-pr-bot]

No bundle size changes (experimental)

Generated by 🚫 dangerJS against 587c92e

[oliviertassinari]

lazy load each section below the fold using react-intersection-observer

Could we only lazy load the heavy sections that are not relevant for SEO? For instance, if the approach means that Google bot can't extract the relevant content of the page and index it, I think that it's K.O.

[oliviertassinari]

What do you think about moving this to the lab, so we can dog food #16663?

[siriwatknp]

Why, I don't get your point? Can you elaborate?

[oliviertassinari]

This helper seems simple enough for us to implement a quick & dirty version and start experimenting with it before we expose something public.

[siriwatknp]

Could we only lazy load the heavy sections that are not relevant for SEO? For instance, if the approach means that Google bot can't extract the relevant content of the page and index it, I think that it's K.O.

The areas that are lazy loading. Do you think it will have an impact on SEO?

(edited) sponsors section is not lazy load anymore.

[oliviertassinari]

The areas that are lazy loading. Do you think it will have an impact on SEO?

@siriwatknp More than SEO, I'm worried about two other things:

• If creates a layout shift. The height of the page changes when I scroll. I'm in a hotel with a poor connection, it flickers
• It's not a method that developers can't use at scale to solve slow landing page performance issues. I think that we should rather have a slow landing page and solve the underlying problems, e.g. sx prop that is too slow, or use upcoming React server-side components and be upfront with developers on what they can expect, than working around the problems. So us feeling the same pain as the community.
• It seems to trigger too late, we could trigger the next section before it gets visible. For instance, so that the images are already loaded once they get in the viewport.

I would propose we use this viewport technique as little as possible, at least, never at the expense of a changing scroll height.

[oliviertassinari]

Regarding pushing it one step futher. The initial request is suspicious. Compare:

Maybe it's the size of the HTML output. Should we shorten the class names in production? From .css-18grc4p-MuiButtonBase-root-MuiButton-root to .css-18grc4p? There are already the global class names on the element cc @mnajdova

[siriwatknp]

It creates a layout shift. The height of the page changes when I scroll. I'm in a hotel with a poor connection, it flickers

@oliviertassinari Can you try again? I forgot to add placeholder when it is loading. Tested with poor connection, I don't see obvious layout shift.

It's not a method that developers can't use at scale to solve slow landing page performance issues
I would argue this point.

In the context of rebranding, our goal is not to build API for solving landing page perf. So, I think it is not relevant.

It seems to trigger too late, we could trigger the next section before it gets visible. For instance, so that the images are already loaded once they get in the viewport.

fixed.

---

I think it is a trade-off to decide which one we can live with. Here is the data I get from google analytics, the past year / pageviews is ~9M. From the improvement, the first load time reduced by ~1s, so the result is quite huge in my opinion.

However, the code looks a bit more complicated and the Placeholder's height need to be calculated manually to prevent layout shift which means if design change in the future, the height might change.

The question is "Can we live with this?". For me, the total time reduced in a year is far better than the increase of code complexity and maintenance (I don't think we will change the homepage design more than once a year). Moreover, it is not a public API so we can revert back at anytime if we found out it is not worth by whatever reason.

Anyway, waiting to see what other team members's thought.

[oliviertassinari]

Can you try again? I forgot to add placeholder when it is loading. Tested with poor connection, I don't see obvious layout shift.

No layout shifts now, even on the crappy shared WiFi of my hotel. Niice.

The question is "Can we live with this?"

I would have framed the question as: "Are we OK dodging a performance root issue on the homepage for improving developers's perception?" To be fair, we were already doing it in the homepage of v4 with NoSsr.

[eps1lon]

lazy load each section below the fold using react-intersection-observer

I like the approach if it's only focused on non-content e.g. images, component demos. But you're also lazy-loading sponsors which I wouldn't do. Part of their interest is to get exposure. Lazy-loading them diminishes that significantly.

In the context of rebranding, our goal is not to build API for solving landing page perf.

Who said that? The landing page is the first impression for our product. We can't just neglect that.

"Are we OK dodging a performance root issue on the homepage for improving developers's perception?"

This is not a tradeoff. These are part of the same story

To be fair, we were already doing it in the homepage of v4 with NoSsr.

This is not intended. What issue do you currently see on v4?

[siriwatknp]

But you're also lazy-loading sponsors

thanks for the feedback, I also doubt myself if I should do it. I will revert the sponsors section.

Who said that? The landing page is the first impression for our product. We can't just neglect that.

I think you misunderstand my point or I misunderstand Olivier's point. I am all in for improving performance on the homepage. However, Olivier pointed out here that the approach "is not a method that developers can't use at scale to solve slow landing page performance issues". That's why I responded that the PR try to improve the performance not building method for other developers.

[eps1lon]

However, Olivier pointed out here that the approach "is not a method that developers can't use at scale to solve slow landing page performance issues".

I have no idea what Olivier is talking about. We should have a slow landing page because that's what user should expect? This is news to me. A major aspect of the new styling solution was performance.

[siriwatknp]

merged to unblock refinement. If @oliviertassinari does not agree with this approach, we can discuss once you are back.

[oliviertassinari]

@siriwatknp I have noticed a minor issue with the sizes, there is one last layout shift. I'm sending a PR to address it: #27930. It looks great.

To clarify #27838 (comment). We have acknowledged that the lazy mount approach costs developers' time, a scarce resource:

the code looks a bit more complicated and the Placeholder's height needs to be calculated manually to prevent layout shift which means if design changes in the future, the height might change.

If we assume that the lazy mount approach is not something that most developers have the time to leverage, would it mean that:

• these developers will experience the same slow page loading that we had, blaming us and moving to a different solution that is more straightforward
• we, the MUI maintainers would be blind to the pain because we dodged it

?

Parts of the pages are always rendered, so I think that we will still get the confirmation feedback loop if we improve the performance of the styles/system. All good.

---

Regarding the performance of the styles in v5 vs. v4. The best summary I'm aware of is https://stackoverflow.com/questions/68383046/is-there-a-performance-difference-between-the-sx-prop-and-the-makestyles-functio, the change of performance depends on the API.

We did a benchmark at the component level at some point: #22342 (comment). v5 Slider was about 25% slower than v4 but we moved forward anyway, judging that the value of dynamic styles was well worth the slowdown. It could be interesting to update the benchmark, to get a more accurate view now, vs. before.