AJ @ WpFASTER.org

Hi folks,

Just a tip —

If your website is served over HTTP/2 and has ‘lots’ of JavaScript, concatenating this JavaScript into a single or even a few files will decrease real world performance.

Multiple minified and deferred JavaScript files are parsed far more efficiently over HTTP/2 since they are multiplexed/served in parallel, whereas if one has them all — or nearly all — of them combined, the end user is going to have to wait the additional time it takes for that one big JavaScript file to finish. The real world affect being the delayed loading of anything above the fold or functionality dependent upon JavaScript, sliders for example. That a combined JavaScript file can be deferred does not ipso facto translate into improved perceived speed, even if some or another best practices recommendations tool gives one higher grades for having combined their website’s JavaScript.

In short, while tools like GTmetrix can be helpful if interpreted correctly, the bottom line is that blindly following the suggestions tools like this make will often result in anti-patterns which translate into a slower site for one’s real human users, which then translates into degraded UX, which then of course translates into the Universe collapsing in on itself and the end of all life in the Cosmos… please don’t end all life in the Cosmos.

Be well,
AJ

Thanks, Jared.

AJ

An option for Server Push would be awesome, Frank. Ideally for any ‘loose’ file — jQuery for example — as well as the concatenated CSS. W3TC has a similar feature in the Minify section if you’d like to see how Frederick is doing it.

Be well,
AJ

Awesome! Yeah, big FOUT. And will sometimes still be identified as render blocking for mobile on PSI lol ??

Be well,
AJ

Wonderful, folks. Thanks ??

Be well,
AJ

Just a note:

I hope you will consider not removing certain functions from the plugin as it is when you phase-in the new modules.

One thing that sticks out in my mind at the moment is that the new CSS module differs in that the option to load CSS in the footer is no longer available, replaced with timed delay.

The problem with this is that not all browsers process DOM manipulation the same way or follow the instruction to delay parsing the same way, whereas all browsers do in fact process CSS loaded in the footer the same way. It seems clear that the option to load CSS in the footer was removed from the new CSS module since timed delay and load-in-footer should — in theory — be capable of producing the same results in the wild. They do not.

Short version: It would be great if you would keep all of the current functionality available plugin-wide and add the new features on top of an already great schema.

Super short version: Don’t fix what ain’t broken! ??

Be well,
AJ

The you should update your “Tested up to:” in the plugin’s profile, no?

Be well,
AJ

We’re going to try and find some time to test this, o10n.

Be well,
AJ

Wow, very impressive ??

Very much looking forward to this.

Be well,
AJ

Will do!

AJ

Hey Frank,

I don’t immediately understand how that filter would work as the desired “push-button solution” or how to leverage it to automagically change headers as they are added via the HTTP/2 feature of this plugin. But okay; I’ll pass this along to Marcus, resident PHP adept.

Be well,
AJ

It would. The FOUT is obviously more pronounced, however.

Just to emphasize: The problem is not with webfont.js (it does in fact async fonts) but with PageSpeed Insights and how it speculates about and/or deals with stuff that appears in the </head>. For a reason we’re still a bit fuzzy about, GPSI likes RequestAnimationFrame, LoadCSS, webfont.js, in that order, in spite of LoadCSS and webfont.js being superior in terms of real world performance.

Another potential option, Frank, would be “Inline Google Fonts CSS?” (Fast Velocity Minify offers this). The irony here being that while inlining Google Fonts CSS will get rid of the render blocking recommendation for Google Fonts on GPSI, the specific file the browser needs… will block rendering in the real world. Albeit in a far less significant manner than the browser having to contend with parsing an entire aggregated font file for example.

AJ

The truth about PageSpeed Insights will set you free! ??

May we all have less gray hair in 2018.

AJ

Hi folks

PageSpeed Insights’ analysis does not use real devices. PageSpeed Insights fetches a site with a Blink renderer (the rendering engine that powers Google Chrome) that emulates both mobile device and desktop devices. It is an artificial/synthetic test prone to errors.

PageSpeed Insights’ recommendations should always be compared against real world tests to see what’s really going on and to figure out which of it’s recommendations are actionable and which should be ignored.

Your CSS file does not block rendering on mobiles, c0mpil3r. You’re getting a false positive, as you can see here with Google’s real world performance testing platform Webpagetest (Dulles, VA – iPhone 8 iOS 11 – LTE): https://www.webpagetest.org/result/180103_36_5d11d2397861da8f035183384363fd88/7/details/#waterfall_view_step1

Request #64 is your aggregated Autoptimize CSS. It comes well after the green line that indicates when rendering begins.

Be well,
AJ
Managing Partner
WpFASTER

I’ll indeed try to find some time to test 2.2 Frank.

Be well,
AJ