So, today I did a quick audit of my web pages, and noticed that PageSpeed Insights had AGAIN changed their algorithm... Okay.
As you may know, Wedge is the champion of web optimization, I spent enough time on making sure it was, and in earlier versions of PSI I was hover over 95% while the SMF-based competition was between 60 and 70%. All scores were lowered by a fair margin when analyzing an actual topic page, though.
Now it seems that with the new algorithm, and with page 1 of a random topic, SMF is at 53%/59% (Speed/User experience), ElkArte is at 68%/97%, and Wedge is at 78%/97%. Yes, BARELY better than ElkArte... Anyway.
Both Elk and Wedge have the same 'blocking' error: CSS blockers in the head, which end up delaying the page render phase. Okay, uh...
Seriously.
CSS files are supposed to be in the head. It's the standard thing.
Now what does Google suggest..? Moving them to AFTER the closing html page. Not kidding.
Okay, I'm not sure I want to do that. Why should I generate a FOUC just to please PageSpeed Insight..?
So I looked into doing something else to improve parallelism... Moving my assets to new domain names. Which would also eliminate the problem with cookieless domains. Which PageSpeed Insight does NOT care about, but the Chrome Dev tools "Audit" section does, so I'm doing that.
Okay, we're on topic now.
I started by doing some tests with the skin system's <replace> tag, but I don't want to have to update the custom.xml files on all of my skins every time I add or remove a subdomain, so I spent my afternoon working on a UI to implement page replacements. Just simple str_replace calls, that you can control from within the "Pretty URLs" admin page.
Cool, uh?
Well, it works.
But it has problems, which I want to discuss. (Putting numbers next to topics, so we can refer to them individually.)
1/ If I move all of my assets (+css+js) to a single subdomain, Google's Audit complains that there are too many resources loaded from that subdomain (!!). Solved by moving to assets, js and css subdomains.
2/ Looks like Wedge is still creating cookies on these subdomains, even though I modified the cookie admin option to no longer be 'global'. After removing that cookie (once for each subdomain), though, I have yet to reproduce.
3/ Relative URLs will no longer work, of course, inside CSS and JS files. Because you can't access the /assets/ folder from a css subdomain which is restricted to the /gz/css/ folder as its base, I was forced to remove relative URL optimizations, and regenerate my cache. Not cool. It definitely adds a few bytes to CSS files, although not THAT many...
4/ PageSpeed Insights is now... giving me more complaints about <head> links. Yayz. My score actually went (for the same page), down from 78 to 70%!!! Way to go!
What do you think?
Why do you think my score has decreased that much, even when it should have actually increased...?
As you may know, Wedge is the champion of web optimization, I spent enough time on making sure it was, and in earlier versions of PSI I was hover over 95% while the SMF-based competition was between 60 and 70%. All scores were lowered by a fair margin when analyzing an actual topic page, though.
Now it seems that with the new algorithm, and with page 1 of a random topic, SMF is at 53%/59% (Speed/User experience), ElkArte is at 68%/97%, and Wedge is at 78%/97%. Yes, BARELY better than ElkArte... Anyway.
Both Elk and Wedge have the same 'blocking' error: CSS blockers in the head, which end up delaying the page render phase. Okay, uh...
Seriously.
CSS files are supposed to be in the head. It's the standard thing.
Now what does Google suggest..? Moving them to AFTER the closing html page. Not kidding.
Okay, I'm not sure I want to do that. Why should I generate a FOUC just to please PageSpeed Insight..?
So I looked into doing something else to improve parallelism... Moving my assets to new domain names. Which would also eliminate the problem with cookieless domains. Which PageSpeed Insight does NOT care about, but the Chrome Dev tools "Audit" section does, so I'm doing that.
Okay, we're on topic now.
I started by doing some tests with the skin system's <replace> tag, but I don't want to have to update the custom.xml files on all of my skins every time I add or remove a subdomain, so I spent my afternoon working on a UI to implement page replacements. Just simple str_replace calls, that you can control from within the "Pretty URLs" admin page.
Cool, uh?
Well, it works.
But it has problems, which I want to discuss. (Putting numbers next to topics, so we can refer to them individually.)
1/ If I move all of my assets (+css+js) to a single subdomain, Google's Audit complains that there are too many resources loaded from that subdomain (!!). Solved by moving to assets, js and css subdomains.
2/ Looks like Wedge is still creating cookies on these subdomains, even though I modified the cookie admin option to no longer be 'global'. After removing that cookie (once for each subdomain), though, I have yet to reproduce.
3/ Relative URLs will no longer work, of course, inside CSS and JS files. Because you can't access the /assets/ folder from a css subdomain which is restricted to the /gz/css/ folder as its base, I was forced to remove relative URL optimizations, and regenerate my cache. Not cool. It definitely adds a few bytes to CSS files, although not THAT many...
4/ PageSpeed Insights is now... giving me more complaints about <head> links. Yayz. My score actually went (for the same page), down from 78 to 70%!!! Way to go!
What do you think?
Why do you think my score has decreased that much, even when it should have actually increased...?