Skip to content
This repository was archived by the owner on Jan 11, 2023. It is now read-only.

Inline main.js #12

Closed
Rich-Harris opened this issue Dec 18, 2017 · 3 comments
Closed

Inline main.js #12

Rich-Harris opened this issue Dec 18, 2017 · 3 comments

Comments

@Rich-Harris
Copy link
Member

It's small enough that maybe it doesn't make sense to make an extra request?

@Rich-Harris Rich-Harris added this to the one day, maybe milestone Mar 11, 2018
@Rich-Harris
Copy link
Member Author

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.

@andriytyurnikov
Copy link

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% ?

@benmccann
Copy link
Member

#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.

@antony antony added the stale label Oct 30, 2020
@antony antony closed this as completed Oct 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants