[docs] Reduce .html response size #18356
Conversation
oliviertassinari
added
docs
| @@ -91,6 +93,7 @@ const styles = theme => ({ | |||
| }, | |||
| '& pre': { | |||
| overflow: 'auto', | |||
| lineHeight: 1.5, | |||
There was a problem hiding this comment.
Fix hydration layout jump (vs 1.43)
Details of bundle changes.Comparing: e0dd45f...77a9ee5
|
There was a problem hiding this comment.
Very interesting. Rich Harris had a thread about this a few days ago about the fundamental issue of rendering interactive content on the server. The gist is that it's kind of useless to render a button on the server if it isn't interactive because the user sees a button but every click will be ignored until hydration completes.
This PR basically addresses this by not rendering the interactive controls for the demo on the server. It might make sense to investigate similar potential for the landing page because that's more likely to be server rendered. Do we have stats on pages where the user lands on (ssr is actually used) vs pages that are navigated to with client side routing (ssr is unused)?
|
Thanks for the reference. I would like to wait the end of the Netlify enterprise hosting trial period to measure the impact of these changes. In 5 days. |
|
https://material-ui.com/components/material-icons/ might be a black sheep 😬
|
How do the changes in hosting relate to the changes in this PR?
Please don't fall into the trap of condemning everything sent over the wire. The browser is capable of rendering partial html. The correct question to ask here is if everything that's sent visible before hydration completed. |
|
I believe that the metrics shared in the pull request description doesn't involve a browser, but the time it takes to crawl, on average, one page. |
|
Netlify enterprise benefits from more physical presence (more servers) and higher cache size, it should translate into faster HTML fetches for Google Bot. |
What do you mean "believe"? You took the screenshots which look like something from the network panel in chrome devtools. Where did you get the screenshots from? Just want to emphasize that SEO that targets the machine will always be bad SEO. Google is not interested in pages that are fast for their machine. They model their machine after the user. So by improving the experience for the user we do improve SEO. Initial page size does improve the experience for a regular user not just google. And ultimately I don't understand how netlify relates to this? If enterprise improves SEO you don't want to ship this improvement? Could you expand the full context of this? It seems like you're omitting some important insight into the scope of this PR |
|
The graph comes from https://neilpatel.com/blog/google-search-console-crawl-stats/. Yeah, agree. It's definitely not the end metric we would like to improve. It's more of a derivative metric that we can observe to hint if we are going in the right direction or not. Google probably has some other hidden metrics to estimate the perceived speed of the website. |
|
But there are two other images in your description. If these are not part of this PR why include them? |
It's about isolation. I think that we should deploy one change at the time, so we can measure the impacts. |
|
Right that makes sense. It sounded like it's one or the other. |
oliviertassinari
added
PR: ready to ship
and removed
on hold
|
Given that Netlify still has 1 more days to run, that Google Dashboard has 2 days of lag and that we won't release this change before next week. We can merge :) |
Explore if we can do better than (23.5 kB gzipped)
with minimal changes.
After
Aim to improve Google crawler download durations:
https://www.google.com/webmasters/tools/crawl-stats?siteUrl=https%3A%2F%2Fmaterial-ui.com
240ms on average for a static website is not OK.