Very slow pageload after install

Hi Koen;
I’ve seen earlier reports about AO running slow on wpengine’s staging, wheras it runs just fine in production, so maybe you should just try it in production if only of half an hour to see if that is the case here as well?

Kind regards,
frank

Hi Frank,
thanks for your quick reply.
I’m running on an automatic wpengine cdn, I thinks it’s maxcdn. Do I need to enter something in the field CDN Base URL?
If I get it right the css etcetera is minified upon first request? If so, If so I first load some pages, and then empty the caches of my cdn.
best regards,
Koen.

Avond Koen;
As far as I know (but I could easily be wrong), Photon (Jetpack’s CDN) is only used for images, no?

CSS & JS are minified upon first request. No need to flush CDN caches, as the files will be new (with a different name).

succes ermee!
frank

bedankt Frank ??

Hi Frank,
just letting you know that it did not work. Sometimes a page gets loaded a sort of quickly, but most of the time pages have a load time ranging from 10 to 30 seconds.
I’m guessing it has something to do with the ‘betheme’ I’m using right now, so I’m going to contact those guys to see if there’s something they can do.
bedankt voor de moeite!
gr.
Koen.

ok, some questions;
* can you re-enable AO on staging? i’d like to run some tests.
* does every individual page load slow all of the time, or only first time (i.e. is the page faster once it is in wpengine’s page cache)?
* is the site slow even if you disable JS and CSS (and HTML) optimization? can you switch those on and off to try to identify which one is slowing things down?

frank

Hi Frank,
I have re-enabled AO on staging: https://onest.mp/1tnPSQK

The homepage is loading faster than a woocommerce product page. Although overall it’s still slower with than without AO.

First time load is indeed much slower, it improves when in cache.

I just tried to disable and enable the options: JS, CSS and HTML. In all setups, it is slowing down. Although I get by far the best perfermance when only CSS is enabled. But still then, slower load times than without AO.

Homepage: https://onest.mp/1tnPSQK
productpage: https://onest.mp/1z9cwxx

I’m starting to realize it is more complicated than I thought. On a product page for instance I insert php code with a plugin called ‘php code’ with jquery and css inside on the fly. This is loaded near the bottom of the page (not in the head). Therefore I tried to enable the option of AO to look only for scripts in the head. But still no good performance at all.
But when I test the plugin without this css and jquery on the fly I still don’t have a good performance.
Thanks!
Koen.

OK, ran some webpagetest.org tests on your staging instance (the shop-pages);

test with autoptimize
test without autoptimize

Based on those I think that:
* the wpengine page caching isn’t working
* you probably have page-specific javascript or CSS in those pages

If a page is in page cache, this is what happens:
1. page is returned from cache
2. optimized CSS/JS as referenced in HTML is fetched from Autoptimize cache (those are entirely static files)

If a page is not in page cache, this is what happens;
1. wordpress builds the HTML
2. autoptimize intercepts the HTML before it is sent out and:
2.1. autoptimize extracts & aggregates CSS & JS
2.2. autoptimize checks if a minified version of that aggregated CSS & JS exists in cache
2.2.1. if not minified version exists, autoptimize creates it
2.3. autoptimize alters HTML, replacing original CSS/JS with links to optimized version

From autoptimize’s perspective, the most expensive step (performance-wise) is step 2.2.1, hence the importance of being able to reuse optimized files from cache. but optimized CSS/JS from cache can only be re-used if the aggregated CSS or JS from the one used on another page. This means that if you have CSS or JS (generally inline) which is specific for each page (or worse, changes with every pageload) you should exclude those from optimization.

based on that, I would suggest you to;
1. check/ ensure that page caching is active (there no specific x-cache header in the http-response-header)
2. dive in your HTML to look for page-specific CSS or JS and exclude those from optimization (I see product SKU’s in the optimized JS + the essb-thing changes with every pageload, that’s a killer really).

hope this helps,
frank

Hi Frank, wow thank you for great level of support. I already tried a few things, removed the essb-thing and my own on-the fly created css and jquery code. But no improvement. So now I know I have to dig deeper. But it takes time with me, I am not that experienced ??
I’ll keep you posted. I asked the author of the theme already if they know more.
Thanks you so much for your time and effort!
all the best,
Koen.

Well, next to essb you should probably also exclude any inline JS that has “SKU” or “sku” in it, as that will probably be the name of a variable that holds a page-specific value?

Regarding the page cache not being used; i checked on your production site and I see these headers in the HTTP-respose;

Vary: Accept-Encoding,Cookie
Cache-Control: max-age=600, must-revalidate
X-Cache: HIT: 4

So there is page-caching (10 minutes), but any change in cookie will cause the page not to be loaded from cache. This might make sense as soon as someone has an item in the shopping cart, but otherwise much less so. It is possible this is the default config of WPengine for sites that are running on HTTPS (which is somewhat hinted to in this support-post). I think you need to talk to both WPengine & WooCommerce support to see what is the optimal configuration in your case (i.e. one that allows optimal page caching, while keeping shopping carts uncached). As soon as you figured that one out, your performance will most likely improve tremendously.

frank

Hi Frank,
Great tips you are sending out! I already submitted a support ticket with WPEngine and with some googling found out that only 3 woocommerce pages should not be cached: cart, my account and checkout.
In the next few days I’m going to check every single installed plugin and associated code.
I can’t thank you enough for this great support!
Koen.