Feature Request: Preload

Possible to include it in Autoptimize?

Possibly. You would set this on all linked autoptimized CSS (i.e. non-inlined & non-inline&deferred)?

Right now the CSS loads deferred.

on your site, you mean? because by default CSS is linked in head, so render blocking, with options to either inline all CSS or to “inline&defer”.

If preload support, preload Google Fonts file css.css
Else load it the usual way

Problem is that the HTML pushed out to browsers would need to check for support and if not available should have rel=”stylesheet”. Given the fact that most of the times that HTML is cached (by a page caching plugin or a reverse proxy) you’ll have only one version.

A solution _could_ be to always send with rel=”preload” (and as=”stylesheet”) and in Javascript test if preload is supported (not sure this will be possible) and if not change rel to “stylesheet”.

But given the lack of support in any browser, this remains (very) cutting-edge stuff, so don’t think this should go in AO for the near future really?

frank

related info:
* loadCSS is a small JS … thingie to load CSS in a non-render blocking way. this one might be interesting for AO actually.
* the dev(s) of loadCSS are looking into providing polyfill support for rel=”preload”, lot’s of interesting comments in the issue for that (a.o. question of how to detect preload-support).

frank

Hi Frank,

What I meant was on top of inline and defer, if we have a preload link, then the css file is downloaded earlier and can be applied as soon as DOM is ready.

loadCSS is interesting. I’ve experimented with it. I think it uses CSSOM ready instead of DOM ready.

I just came across this:

https://github.com/filamentgroup/loadCSS/blob/753c5233e40d32578bf38b09d57b9f0c06f2297d/src/cssrelpreload.js

(Just published). Seems to check for support and does polyfill.

About your point of browser support … I think Chrome automatically updates for users. So anyone using Chrome is soon updated to the latest version. And preload is almost there. Since its share is high, the percentage of browsers with preload will also be high.

still early days (the feature will first go to chrome beta anyway and no confirmation this will be on by default, which it currently is not).

also; this doesn’t only apply to stylesheets, but also to script and fonts and … so the impact on AO could (should) be bigger.

anyway: if I have time one of the next couple of days I’ll whip something up for you to test (an updated autoptimizeStyles.php, only for preloading CSS), but this will probably not be in the next minor AO-version (the next major maybe).

frank

Hi Frank,

Sure, no hurries. I tested by inserting a preload link to the autoptimize css file on top manually and didn’t observe that much difference. Mainly because I think Autoptimize already does most of the speed gains and partly because I created my above the fold css with lots of care.

Sure, no hurries.

too late ??

1. download the latest autoptimize zip from github
2. overwrite the contents of plugins/autoptimize with the contents form the zipfile
3. download (copy/paste) this updated version of autoptimizeStyles.php and overwrite the one in plugins/autoptimize/classes/
4. use this code to enforce CSS preload (hooking into a new filter):
add_filter('autoptimize_filter_css_preload',__return_true);

(add to your child theme’s functions.php or use code snippets)

final warning: the updates in autoptimizeStyles.php are largely untested and as such kittens could die, the entire internet could get broken, or (more likely) your site might not look healthy. but reverting should be pretty simple (remove filter or replace autoptimizeStyles.php with the one from the GitHub zip or replace the plugin with the latest stable one from www.remarpro.com).

but most of all; have fun & keep me posted on your findings!

frank

Hi Frank,

That was quick!

I get a FOUC for some reason I can’t understand. First the inline is used for painting and the site looks fine and then a FOUC (of zero style) for some milliseconds and then a paint.

Do you want to have a look?

https://www.concertedaction.com

I get it both in Canary and Chrome.

Also any specific reason to put the preload in the footer? Because the intention of preload was to load it on priority but without render blocking.

Thanks.

Well, you should only use “preload” when not inlining or “inlining&deferring” actually.

I already updated the code in the Gist to only honor preload if “inline” and “inline&defer” are not active.

frank

Used it. It didn’t do anything and the css was not applied.

I think preload just downloads the file without doing anything. So one still needs inline. There’s of course another preload which is a server push. There one doesn’t need inline. So one has to then write some script to handle what to do with the downloaded file.

So basically it is the same as inlining css and loading an external file to add to inline, except that the file is downloaded quickly while the browser is getting CSSOM ready and can be applied starts to paint.

Rolled back to the WordPress version. Can test again if you have some more tests.

I think preload just downloads the file without doing anything.

that’s correct, forgot to add Scott’s clever trick to apply the preloaded CSS, now added to the Gist.

so yeah, you can test again ??

frank

also; do take into account that at least on Canary that trick did not work (may work now) as the onload event did not fire.

frank

Will test. With inline styles or without?

without (at least for now, based on how all of this unfolds this might change)

Yeah works!

Although FOUC which you said is okay for now.

Tested on both Canary and Chrome. What I saw was that the preload applied quite fast in Canary as compared to Chrome which doesn’t have preload yet.

Should I revert back to the WordPress version?

You could move the whole JS to the head … because the polyfill is such that it simulates a preload for older browsers. If I understand right, it downloads the file with media set to “only x” so that the browser doesn’t render block (which it doesn’t for media types such as print) and then once CSSOM is ready changes it to “all” (default) or user given.

You could move the whole JS to the head …

updated the gist to insert before </head> (could be elsewhere too, just tell me and I can update ?? )

Should I revert back to the WordPress version?

you could also simply remove the add_filter on autoptimize_filter_css_preload and then you’d have the wordpress-version + some fixes? ??

frank