Any way to further optimize how the CSS is included on a page?
-
Is there any reason why the CSS for the font(s) & variation(s) is simply included as CSS directly on each webpage?
It’s certainly helpful that there’s some caching in how that inline CSS is being pulled into a page, but I’m wondering why it wouldn’t be better to have it where that CSS is then saved out as a CSS file to then be enqueued on pages accordingly (or at least available as a setting where it’s a dropdown to choose between “inline” [current method] or “saved to filesystem” [newly suggested method] for how the CSS is loaded onto pages; other plugins [ex. Max Mega Menu, assorted page builders, etc.] have done something similar when custom CSS is involved to allow for a potentially more optimal way of loading their custom CSS for visitors.)
I bring this up since I’m seeing something like 45KB of inline CSS on a site that’s then being included in the HTML of every single webpage when using this plugin with 3 fonts selected. I imagine a site with a good handful of fonts would see its webpage filesizes increase even further & potentially to a rather noticeable degree.
– Potential Implementation –
Couldn’t it be set up so this plugin has a folder in wp-content/uploads/ which then has the CSS that’d otherwise be included directly onto all webpages be saved out as a CSS file & enqueued on pages to keep the webpage itself slimmer while also taking advantage of browser caching, making that CSS more available to minify/combine via optimization plugins, etc.?
At that point, I’d imagine the CSS files could be named with timestamps so a webpage that’s cached server-side & might want to pull an older version of the CSS can do so while freshly generated pages can have it grab the latest timestamp on record for that CSS (while then having it clean up those older CSS files after a set [possibly configurable] duration like a month or so…? *Possibly then doing so whenever the plugin’s settings are saved to avoid needing to get cron events involved while that’s when it would generate the new CSS file anyway to then also check the existing CSS file timestamps to delete anything that’s older than the max age.) I also bring up timestamped files since this would need to account for browser caching where having it keep the same file name might cause changes to the plugin’s settings to be quite delayed for visitors depending on a site’s browser caching setup.
Not saying it needs to be the new default (though that could certainly be considered.) I just think there can be a case where offering this would help optimize the performance of a site in a few, potentially impactful, ways (especially when the number of fonts adds up for a given site; load it once & have it be in browser cache while browsing additional pages compared to having all of that CSS be loaded as part of every webpage visited seems like a clear optimization opportunity for this plugin.) Maybe this is already an option that I haven’t come across so definitely let me know if there’s a way to do this. Otherwise, I’d be curious to hear what the thoughts/concerns are about getting this added as an option.
-
Hi @kzeni,
Thanks for sharing your thoughts!
A lot of frameworks are actually doing the opposite, moving the CSS from separate files to inline code. I believe this is what Gutenberg does with block CSS.
I’m wondering what proposed benefits would come from your solution? It sounds like we would simply be moving the 45kb from the HTML (which is compressed by GZIP) to a CSS file which can also be minified. But we would also gain another network request. I’m eager to learn more though.
I’d imagine something like Gutenberg has styles where they’re much more likely to be unique to one particular page where it being inline then makes more sense (I’ve also seen block editor devs mention how further performance optimizations to consolidate & serve up styles in a more optimal way is a goal after multiple people brought up how too much inline styling can be detrimental for performance.) That said, CSS that’s largely/entirely the same across all webpages would have much less of a need/reason to be inline on every single page. Certainly, we’re not about to make all theme & plugin CSS entirely inline on all pages, right? With that in mind, I feel this plugin is more akin to a theme’s site-wide CSS rather than something like Gutenberg’s block styles where block(s) and/or their styling could be entirely unique for a given page.
It’s certainly a balance. Yes, it’s 1 more network request to grab the CSS file, but it’s however many KB of that CSS then not needing to be loaded on every single webpage while that CSS file really only makes that 1 additional network request once per browser caching then holding onto it for however long (some sites then having their CSS files not expire in browser cache for something like a year.)
I’m certainly not the one to make the decision, but I’m curious how you see the balance of 1 more network request that only happens for however long the browser cache lasts to then be instantly loaded by all webpages being visited after that compared to however many KB that CSS is then always being loaded across all webpages ever visited.
Don’t want to forget about plugins that combine/minify CSS where that concern of 1 additional network request goes away entirely as it’s simply bunched together with other CSS for the website/page. So, I’m not sure if there’s any downside to the file approach at that point while then still getting those assorted improvements.
Also, I’m not 100% in the know on how unique this plugin’s CSS can get given different settings across various pages. If it actually is rather dynamic depending on what page one’s on, then inline can certainly make more sense… while it being the same across all pages really makes it more akin to theme CSS where I’m thinking having it be a file has the potential to be a solid performance optimization.
- The topic ‘Any way to further optimize how the CSS is included on a page?’ is closed to new replies.
