-
|
I was looking at Kent's site the other day to see how remix performs in some not-so-trivial site/blog. Results are great already, really, super happy this is happening! One thing that caught my attention is that some waterfall is still happening at the beginning. Before app chunks are loaded, they are waiting for fonts, some styles and polyfill.js costing around 500ms from my machine of waiting time. Further more I can see despite the Matter font blocking the loading of the rest of the UI, I still see it causing a rerender (if you load in 3g quality for slowmo). I am looking forward to the future where we could load a site with a custom font, loaded in a non-blocking way and without layout shifts 🎉 So, I am wondering if remix could have prevented these?
|
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 12 replies
-
|
What you see there is no waterfall. It is queuing which is done by the browser. From Chrome's timing explanation:
The white bar is indicating this. EDIT: We are seeing the network waterfall diagram, but not the negative association of waterfalls, e.g. Network requests being dependent on each other. |
Beta Was this translation helpful? Give feedback.
-
|
@ccssmnn thank you for the info, super valuable! Didn't think http1 could be the issue !
|
Beta Was this translation helpful? Give feedback.
-
|
These are all waterfalls. Some are sequential and others are parallel. We want the parallel one. Borrowing from the remix homepage here.
What we avoid is network requests being dependent on each other intentionally, e.g. having a request fired by client-side JavaScript. This can only start after JavaScript is loaded and parsed. (The left part in the image) What you see in your screenshots is: the browser could download everything at once but is applying its own optimizations and queuing. Remix is offering everything needed right away. (The right part in the image) |
Beta Was this translation helpful? Give feedback.
-
|
@ccssmnn Yeah, I was intuitively including only sequencial requests in "waterfall" terminology 🤣 |
Beta Was this translation helpful? Give feedback.
-
|
@ccssmnn in your screenshot from remix landing, everything is parallel, except of document, this is correct. In my screenshots you see Document => (fonts, stylesheets, polyfills ... 7 requests in total) => rest. I am saying that those 7 requests after the document are blocking the download of the rest. Not sure why you are not seeing it the same way. |
Beta Was this translation helpful? Give feedback.
-
|
They are not blocked, they are queued. This is done by the browser and has nothing to do with Remix. The browser clearly could download everything at once but is applying its own prioritization to the downloads, e.g. "Higher priority requests". Maybe:
Downloading everything at once would slow styles and fonts down and ultimately result in a slower page. These decisions are made by Chrome, not Remix. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe "blocked" is not the right word, but it definitely has to do with how ressources are described in the document, browser doesn't optimise this magically, its because those 7 are in the header and the chunks are at the end of the body. That definitely explains why the rerender happens when font is loaded (separate problem though) I guess this is currently best for low bandwidth, downloading only what's necessary first to avoid using the bandwidth for the scripts that are only needed later
|
Beta Was this translation helpful? Give feedback.
-
|
Chrome might use |
Beta Was this translation helpful? Give feedback.
-
|
Indeed everything is different in Firefox, it even manages to have the font loaded before rendering text, so there is no rerender for that part. |
Beta Was this translation helpful? Give feedback.
-
|
Let me summarize the discussion:
Resources are not blocked. This is Chrome queuing the other resources due to lower prioritization, indicated by the white bar. Chrome might prioritize assets in
I could not reproduce this. But what you described is a font-display strategy. Kent used
Choose a different font display strategy.
Chromes resource prioritization and queuing? No. Showing the system font instead of the custom font until it is loaded? Possible with standard CSS. |
Beta Was this translation helpful? Give feedback.
-
|
The parallel vs queued downloads are choices made by the browser, not the web developer. Prioritizing font and styles for a fast FCP sounds perfectly reasonable to me. Adding polyfills to support older browsers here is a decision based on what you want to support. Polyfills must be parsed BEFORE your other scripts to achieve the desired effect, which is why he is including them in the head. You are free to make all the decisions with Remix (e.g. putting |
Beta Was this translation helpful? Give feedback.
-
|
Remix can have a higher level abstraction that decides where to put which script and which css file (well for styles it already has e.g. we can communicate to the browser to start downloading the polyfills in parallel with other scripts but evaluate them in the right order (defer) |
Beta Was this translation helpful? Give feedback.
-
|
Remix links are not an abstraction, and not an abstraction for styles. They are a 1:1 interface to the standard HTML The whole idea about Remix is not being an abstraction layer over web standards. Instead, embracing them. |
Beta Was this translation helpful? Give feedback.
-
|
This is not entirely true, but I will leave it by that ;) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Let me summarize the discussion:
Resources are not blocked. This is Chrome queuing the other resources due to lower prioritization, indicated by the white bar. Chrome might prioritize assets in
<head>over the ones in<body>which is why polyfills, fonts and CSS are loaded first. Safari and Firefox behave different because they have different opinions on the best user experience when loading websites.