Skip to content

Styles should not be inserted into HEAD in Safari #492

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
theKashey opened this issue Jan 11, 2020 · 10 comments · Fixed by faceyspacey/extract-css-chunks-webpack-plugin#195

Comments

@theKashey
Copy link

  • Operating System: OSX
  • Node Version: does not matter
  • NPM Version: does not matter
  • webpack Version: does not matter
  • mini-css-extract-plugin Version: does not matter

Expected Behavior

Expected that application behaviour would be the same across different browsers.

Actual Behavior

In Safari the whole rendering would be suspended while style, added to the head, is loading.
Adding style to the body resolves the problem.

Code

This example reproduces an issue originally created for loadable-components.

It delays serving for .css file for 10 second, and all this time nothing is rendered.

How Do We Reproduce?

  1. add link to the head in Safary
  2. render some animation (like counter) in on the page
  3. page is expected to be fronzen all time link is loading the data

How to fix?

For Safari "dynamic" styles has to be added into Body. It resolves the issue.

  • ongoing PR Add support for the insert option #459 should fix the problem, however it should be considered as a default behavior.
  • I would say that's a WebKit bug, but could not find something at their bug tracker
  • see this PR for a bit more context
@theKashey theKashey changed the title Styles should not be inserted into HEAD in Safary Styles should not be inserted into HEAD in Safari Jan 11, 2020
@ScriptedAlchemy
Copy link
Contributor

@evilebottnawi i could pr it appending to the body instead. Or an option could be added to the plugin like ‘appendTo’ thoughts?

@theKashey
Copy link
Author

First one has to investigate the consequences. Plus should new links be added to the beginning of the body, or appended to the end?
Look like the issue is here already for a while, let's not rush.

@hkhere
Copy link

hkhere commented Jan 12, 2020

@theKashey It is not just style files but js files too could cause the whole rendering suspended. The dom is acutally loaded (we can examine it in the devtools). Should this be reported to webkit?

@theKashey
Copy link
Author

  1. Yes. That's a purely webkit bug
  2. Also yes... it would take some time to resolve it, as well to release a new version, and ship an update.

I would say - it might take a year to resolve this issue via webkit, so some other solution should be created.

@ogonkov
Copy link

ogonkov commented Jan 17, 2020

inserting styles to <header> is a common practice, it is definitely shouldn't be changed

@theKashey
Copy link
Author

That's not how you should think about it. Now "what everybody is doing it", but "why everybody is doing it". And really - there is no reason.

For example all CSS-in-JS solution during SSR insert styles or links just before markup, and that's ok. There is no real reason to hoist everything to the head.

All existing studies, proposing keeping "styles in the head" are:

  • for SSR/Pure HTML cases only, trying to optimize browser re-rendering
  • ignoring critical css and other best practices of today
  • obsolete

@ogonkov
Copy link

ogonkov commented Jan 17, 2020

The reason is to start to load CSS as much faster as we can, because CSSOM is blocking JS parsing.

@theKashey
Copy link
Author

Again, you are speaking about SSR case, but this (JavaScript!) plugin is adding them when application is already half running. In the original issue (code splitting) - when you change your route - everything is already parsed, everything is loaded.

ScriptedAlchemy added a commit to ScriptedAlchemy/mini-css-extract-plugin that referenced this issue Jan 19, 2020
@alexander-akait
Copy link
Member

You can fix it using #609, I think we can close it, because it is not good default behavior, but if you provide more information we can improve it out of box

@theKashey
Copy link
Author

insert option is capable to mitigate this problem 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants