AJ @ WpFASTER.org

It should, Frank.

However, some issues might be: Firstly — if speaking of Chrome — Chrome (the browser itself) runs its own experiments and does not always behave in accordance with even the most technically executed, brilliant trickery ?? This is one of the reasons why CloudFlare’s Rocket Loader doesn’t always work in Chrome or Firefox (very similarly constructed browsers), in spite of re-executing JavaScript in the exact order in which it appears in the HTML but after onload.

Secondly, and I think this is more important: Sliders, when they are, are above the fold content… This raises, I think, two sub-points:

1.) We ought not be deferring anything that is going to be jarring to the user if executed later than indented. (This is one of the points at which the layman misinterprets GPSI, in spite of it being a layman-centric tool).

2.) Again with Chrome: Chrome, during its parsing of the page, may ‘decide’ that it needs jQuery to render the page properly, and wait for jQuery to load before painting will begin in spite of jQuery being deferred or asynchronously loaded with standard attributes; or, via the method you’re talking about.

I’d certainly love to see some experiments though, Frank. It could certainly work and do so consistently. But either way, it seems to me, we have a render-blocking scenario/a situation in which the browser is waiting for jQuery to be defined.

AJ

P.s. Sorry if this reads a bit muddled. I’m running on about 3 hours of sleep in 3 days.

To the best of my knowledge, ossser, all sliders with any degree of functionality (Master Slider, Slider Revolution, Soliloquy etc) have jQuery dependencies and almost always inline scripts that can’t be aggregated.

This however, will effectively render jQuery in a non-blocking fashion: https://www.wpfaster.org/blog/when-and-how-to-load-jquery-from-googles-cdn ??

Be well,
AJ

view-source:https://avada.theme-fusion.com/

??

AJ

Rather than all the hassle of a child theme and so on I use Simple Custom CSS to fix 3 tap target line spacing so it keeps the Jigglybot people happy. But sccss is not included in Autoptimize Inlinling and thus is render blocking.

Let’s fix that.

1.) Install Modular Custom CSS.
2.) Copy and paste all of the CSS you have in SCCSS into the appropriate Modular Custom CSS code box. Save.
3.) Deactivate SCCSS.
4.) Clear your caches, have a look at the site.
5.) Decide whether or not you want AO to aggregate the now inline CSS that was once loaded dynamically by SCCSS.

At this point, the Critical Path CSS generator will incorporate whatever parts of that CSS are needed to render above the fold content.

Be well,
AJ

I have a couple of pages that have flash player videos on them. Only two about 2 meg each vid. Both the new pingdom and webpage test call the vids and measure the wait until the vids load as a page load. IMO this is not correct as the vids are click operated only if the viewer wants to watch them. The load in a browser by gtmetrix is about 1.5 or less. So IMO the information from both those tests are not accurate.

Well, you’re ahead of the curve and don’t even know it.

There are accurate tests; there is then the interpretation of those tests, however accurate they are……

You’ll do wonderfully.

Be well,
AJ

Hi flyfisher842,

Google also says they are ranking on page load so it would seem some attention to page load would be important. ie. page load of 10 seconds with a user of 99 would not do as well as the same page loading at 0.8 with a UX of 99.

It’s complicated. But the bottom line is:

1.) PageSpeed Insights is a basic best practices tool. People — and it’s not their fault — attribute WAY more to this tool than what it actually is (more info available upon request).

2.) Page Load/Document Complete is only a problem when it is *learn more*. And this is where things get fuzzy for the layman (no insult intended)… If, for example, one’s site has a Speed Index of 942, BUT, their Document Complete time is upwards of 18+ seconds… yeah, that MIGHT be a problem. MIGHT be, but not necessarily…

What Google wants, because it is what your website’s users want, is an optimal User Experience. Simply stated, the user’s perception of speed is the by-far-and-away most important performance characteristic. This is, of course, why Google is so adamant about optimizing above-the-fold content.

Or is all this google page speed just smoke and mirrors

No, not at all. There must needs some sort of major reworking, however, of the general public’s perception of what GPSI actually is and the Internet isn’t helping. WpFASTER is attempting to lead this charge.

Again — and I cannot stress the simplicity of this enough — GPSI is a basic best practices tool. That’s it. That’s all. End of story. No different than, say, GTmetrix or Pingdom.

And a big thanks for the webpagetest.org link. I will check it out today.

I just ran a couple of test very cool site. I like the ability to check with different browsers and locations. This tool makes more sense than any I have tried. Thanks again for the tip.

My pleasure. If you’re looking… you will see that WebPageTest is a real test…

What Google — and your site’s users — ultimately want is real world performance.

It is in fact the only thing that matters.

Be well,
AJ

Just a few comments:

php 5.7

This is a bit of a ‘fringe’ version of PHP. Something of a ‘WTF do we really want to do from here…?” sort of thing. One should ideally update to PHP 7.x — the finalized, solidified presentation of that thought.

Update, I switched to all css inline at bottom and used php instead of static files along with speed booster pack to only remove queries from static files. Result is all my test pages are running insights mobile at 98 or 99 speed and user at 100/100 with desktop at 98 and 99

Your primary goals should be improved UX (User Experience) and real world performance. Not grades on any given best practices tool. So please, make sure you are using WebPageTest.org, Google’s REAL WORLD performance testing platform. There’s a learning curve with it; but, anyone that REALLY wants to can learn it with relative ease.

Be well.
AJ

As a side note: Scores on best practices tools ≠ a website’s real world performance. As counterintuitive as it is, these are generally mutually exclusive things. Mentioned because of this thread’s title v. the reference to “page score” in your initial post, kmay.

Right, so jQuery and sliders in general and Slider Revolution in particular. Workaround: Load jQuery via Google instead of locally.

While loading jQuery from Google is technically still render blocking, it in effect is not, because millions upon millions of websites use Google’s jQuery.

What this means is that it is all but certain that a visitor to your website will already have jQuery cached in their browser, which means that that user’s browser won’t have to download jQuery at all. Voilà, jQuery no longer blocks rendering for the vast majority of your users whereas it would being served locally (i.e. from your server).

Cool, right?

How to: https://www.wpfaster.org/blog/when-and-how-to-load-jquery-from-googles-cdn

Be well,
AJ

Now that you’ve added jQuery to the exclusion list it will in fact be render blocking. Not a huge problem in itself but you should try to get rid of it. If you can’t, you can’t.

If when aggregating jQuery (ie. it was not added to the exclusion list) the only problem you experienced was with your lazy load plugin, the solution there would be to find a lazy load plugin that is not dependent upon jQuery being render blocking. Here’s one. Make sure to add “data-lazy-original” to AO’s exclusion list after installing Rocket Lazy Load.

You can then try removing jquery.js from the exclusion list. If all is well afterwards, you’re good to go and will no longer have any render blocking JavaScript.

You can indeed remedy render blocking CSS with AO. Answers to this and other of life’s great mysteries can be found in Frank’s extensive FAQ and this stickied post string at the top of the plugin’s support page.

Be well,
AJ

??

@washingtonsblog,

jQuery and anything dependent upon it is generally the culprit when one has problems with Autoptimize (or any minification plugin, really).

Between Frank’s #3 and #4 I would add that looking at your site’s source code, one can see:

https://www.washingtonsblog.com/wp-content/plugins/lazy-load/js/jquery.sonar.min.js?ver=0.6

A dead giveaway that the plugin relies upon jQuery.

Note also in the file path “lazy-load”. Again viewing the source code, one can see another .js file with “lazy-load” in its file path:

https://www.washingtonsblog.com/wp-content/plugins/lazy-load/js/lazy-load.js?ver=0.6

While we do not see “jquery” in there, we see “lazy-load” and so know that this file may or may not also need to be excluded for the plugin to function properly.

So, you should further experiment with allowing AO to aggregate that file by removing “lazy-load” from the exclusion list (which was excluding all JavaScript with that in its file path) and adding “jquery.sonar.min.js”, the file we are certain is problematic. In so doing, AO will go ahead and aggregate “/lazy-load.js?ver=0.6”.

If all is well after that you know that that particular file put out by your lazy load plugin can indeed by aggregated ie. combined with the rest.

Be well,
AJ

Hello folks,

@washingtonsblog: Try adding “lazy-load” (no quotes) and “jquery.js” (no quotes) to the JavaScript exclusion list.

Be well,
AJ

Both Avada and Gravity Forms work just fine with AO. We have optimized thousands of sites using both with Autoptimize.

The only negative reviews of AO seem to come from people who want it to work without having to configure it. Frank is too nice to say it but this is simply ignorant.

One must exclude Avada’s inline CSS and Gravity Form’s inline scripts from concatenation. This is not the fault of Autoptimize, but the result of how Avada and Gravity Forms are coded.

One would actually be hard pressed to find any fault whatsoever with AO, given that it merely concatenates and minifies code that is already there.

Be well,
AJ

Hi ScottLush,

You’re not actually getting additional HTTP requests, the problem is that you are using a synthetic ‘speed test’ ie. Pingdom that is incorrectly reporting the base64 gif as an HTTP request.

Test using WebPageTest.org — Google’s real world performance testing platform — and you’ll see accurate request reporting.

Be well,
AJ

You are not aggregating inline CSS, correct? And can you share the homepage URL?

Hello abhisekpadhi,

Your website almost certainly has page and/or request specific scripts. Aggregating such scripts will bloat your cache and slow your site as AO has to produce a new file for each page/request.

Exclude the jQuery library (jquery.js or jquery.min.js depending on which you’re using) as well as inline scripts from aggregation. Doing so should solve the cache issue and improve your website’s user experience centered performance metrics immensely.

Be well,
AJ