You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 11, 2023. It is now read-only.
Also: until recently critical CSS was inlined; as part of the 0.19 work towards extracting CSS, that's no longer the case. We should consider whether critical CSS should be inlined, and if so in what circumstances.
Inlining of CSS, JS, SVG looks like must-have trick in performant mobile web scenarios.
To the degree that there are pretty mature HTTP server plugins to do inlining :D
Setting emitCss: false works like a charm on component level, but inlining of global critical css, sounds like a common task that is not addressed, CSS Reset, Grid, url-encoded-fonts, url-encoded-icons, also many of us rely on CSS frameworks.
Also, mobile (especially pre-HTTP/2) is quite sensitive to quantity of requests, and having one additional HTTP request per component doesn't sounds like a good idea, as slow connections do suffer from having to deal with additional requests.
Would it be good idea to add something like%sapper.inline_global_critical_css% ?
#1269 may somewhat obviate the need for this. If you use a CDN, then the preload header will probably cause the CSS to be server pushed to you, which is probably better than inline because it can be cached.
It's small enough that maybe it doesn't make sense to make an extra request?
The text was updated successfully, but these errors were encountered: