Autoptimize not concatenating CSS or JavaScript

Could this maybe be a clue? From my wp-config file:

//Relative URLs for swapping across app service deployment slots 
define('WP_HOME','https://vocularapp.com');
define('WP_SITEURL','https://vocularapp.com');
define('WP_CONTENT_URL', '/wp-content');
define('DOMAIN_CURRENT_SITE', filter_input(INPUT_SERVER, 'HTTP_HOST', FILTER_SANITIZE_STRING));

the first 3 are normal at first sight, but the last one is a mystery to me. maybe try commenting it?

Think I’ve got it Frank!

Basically I changed this line:

define('WP_CONTENT_URL', '/wp-content');

to hard-code in my url:

define('WP_CONTENT_URL', 'https://vocularapp.com/wp-content');

Now it’s concatenated all these files. The only thing is that my HTML load time has shot up massively, like from 300 ms to 8000 ms. Any idea why this could be?

James

Think I’ve got it Frank!

great!

define(‘WP_CONTENT_URL’, ‘https://vocularapp.com/wp-content’);

good catch. you should even be able to remove (or comment) that line, because https://vocularapp.com/wp-content would be the default anyway.

The only thing is that my HTML load time has shot up massively, like from 300 ms to 8000 ms. Any idea why this could be?

page cache being re-built I would guess?

Looks like you were right. One last thing, I’ve noticed that my AO files often take a long time to load (usually more than 1000ms). Anything I can do to reduce this a bit? I’ll mark this as resolved after that.

One last thing, I’ve noticed that my AO files often take a long time to load (usually more than 1000ms). Anything I can do to reduce this a bit? I’ll mark this as resolved after that.

Did some tests (see https://www.webpagetest.org/result/180509_AK_c3848c63b2e3b1566028076100d02f2c/ and https://www.webpagetest.org/result/180509_K6_324f47e96d13308f9f570ff73b6b2e35/) and see they’re fast most of the times and sometimes (the very first time) … not so fast, with a long time to first byte.

Now the problem is that these are simply static files (.css and .js) and that at that point there’s nothing AO can do to speed up delivery. It _seems_ that IIS takes more time (the TTFB) the first time, maybe putting it in an internal cache of some kind? I’m afraid you’re going to need an IIS-specialist to help you with that particular problem.

One workaround however could be to go the “critical css”-way (“inline & defer optoin in AO, see FAQ for info + optionally the new “criticalcss.com power-up”), where the rendering of the page isn’t slowed down by slow(er) loading CSS?

hope this helps (at least a bit),
frank