Duplicate requests

[sshrshnv]

@faceyspacey I use babel-lugin-dual-import, extract-css-chunks-webpack-plugin and flush-css-chunks-webpack-plugin for SPA, it works good, but I have two duplicate requests for dynamic css:

firefox:

They are caused by lines head.appendChild(link) and img.src = href

Chrome does not load css as an image, but firefox loads

Chrome:

link.onload works well for the latest versions of firefox, chrome, safari

[sshrshnv]

@faceyspacey why wait until the styles are loaded? Is not it better to resolve immediately and add preload attributes? #7

[faceyspacey]

this is the "state of the art" common solution for browsers that don't have proper load callback handling. basically, by loading it as an img and getting an error, we know it's been loaded:

https://github.com/faceyspacey/babel-plugin-dual-import/blob/master/importCss.js#L61

I forget, but likely, the file is only loaded once, since it's the same for each element that uses it. I.e. the browser dedupes it.

...as far as waiting for the styles to be loaded, we need to know they are on the page, before displaying HTML, or the HTML will display unstyled. preload won't solve that.

[sshrshnv]

@faceyspacey

I forget, but likely, the file is only loaded once, since it's the same for each element that uses it. I.e. the browser dedupes it.

No, the file is loaded twice.

...as far as waiting for the styles to be loaded, we need to know they are on the page, before displaying HTML, or the HTML will display unstyled

Ye and it's good, we don't block rendering by styles. And about the benefits of preload: https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf

[faceyspacey]

it might show it twice in the console, but perhaps the bytes are only loaded once. Either way, this is the only way to get around the fact that the load handler is unpredictable in some browsers.

preload shouldn't have any bearing, as the purpose of this plugin is to load files on user navigation after the initial page load. That said, I'm referring to when you're using SSR to embed the scripts and stylesheets required for the initial page load, which is the primary use case of most of these tools. If you're doing an SPA, perhaps you're right.

[faceyspacey]

the primary use case revolves around:

https://github.com/faceyspacey/webpack-flush-chunks

as part of SSR.

[sshrshnv]

With SSR we need to include only critical CSS (for example, header). The rest of the styles should already be loaded on the client and should not block rendering. But now they block

[faceyspacey]

i can't quite grasp your setup. if you're doing a full SSR setup, you have full control of the styles and you can put them at the top of the page with whatever attributes you want. The dual import plugin shouldn't be in use at this initial load stage. It should only come into play on navigation.

It sounds like you're not doing a full SSR setup, and relying on the client to fetch more resources on initial page load.

If you're sure about it, PR it.

[sshrshnv]

The server sends html with a rendered preview, inlined critical styles for it, app.js and chunk.js scripts. app.js adds app.css to head and chunk.js adds chunk.css. Rendering app.js and chunk.js is blocked now by loading their styles. So I'm asking why we are waiting for the load of these styles. Or I do not understand something?

[faceyspacey]

the premise of these tools is that the those js chunks don't add any css, when they are part of the initial load. instead you put them in at the head in the served html using webpack-flush-chunks + react-universal-component.

[faceyspacey]

also, in the article you linked, they were using preload for javascript. for styles, u dont want the HTML rendering without their styles, which is why we put them in the head. so it's a bit different in this case. u basically gotta wait for it.

basically, if next.js is setting their styles to rel='preload' i'd be fine doing it too. so long as it doesn't make the promises resolve too early, leaving unstyled content.

[sshrshnv]

instead you put them in at the head in the served html

If I put them at the head in the served html, they will block rendering. At the head should be only critical styles to increase the speed and reduce the response time, so those js chunks should add css

[faceyspacey]

Ultimately, we wont be able to make this change now. Please dont expend your time making the PR. i'm not sure about this and what side-effects it will have to current users, and I won't have the time to find out right now.

As far as incrementally adding styles, I'm all about pushing the limits of optimization, but basically for me that's an over-optimization and I personally wouldn't worry about it. I don't know many people adding stylesheets as the page renders so that the navbar shows before the body rendered by a chunk.

Also, this stuff is all being applied after the page has finished loading anyway, as it's added via javascript. And the corresponding html rendered by the chunk should only render after the sheet is on the page anyway. But, again, just picture your page:

• you have rendered the page
• and now a spinning loader is showing where the chunk will appear
• all page load events are already completed; the layout is already rendered
• the css + the js loads, and now it can render the chunk (nothing should have been blocked, besides what is intentionally kept hidden via a spinner)

You may very well be 100% correct about the perf benefits, but I'll need to see it close-up for myself and really investigate (primarily to make sure we don't break things for other users). If you really need this, alias importCss.js at the babel or webpack level and do whatever you want with it. Then let me know how it goes. Likely you'll find out a few gotchas to doing this fully correctly. Then maybe we can revisit this.