Wedge

Public area => The Pub => Features => Topic started by: Nao on April 8th, 2014, 08:35 PM

Title: Cookieless domains and other things...
Post by: Nao on April 8th, 2014, 08:35 PM
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...?
Title: Re: Cookieless domains and other things...
Post by: Nao on April 9th, 2014, 10:29 AM
Anyone inspired..? :-/
Title: Re: Cookieless domains and other things...
Post by: Pandos on April 9th, 2014, 10:45 AM
I see an overall of 90% for Wedge (Desktop)

Since the compalin is about CSS....
If the CSS is smaller than 2048 bytes, we could try to inline them.

Also nice to read:
https://developers.google.com/speed/pagespeed/service/FlattenCssImports

Cookieless:
Therefor you must have access to the virtual host file to disregard cookies for that domain. This should only work if you put your files on a different server IMHO.
Title: Re: Cookieless domains and other things...
Post by: Nao on April 9th, 2014, 11:02 AM
Quote from Pandos on April 9th, 2014, 10:45 AM
I see an overall of 90% for Wedge (Desktop)
Don't bother with the numbers, they can't be ported from platform to platform without reusing the same data...
Best I could do is to do an import of an SMF board, and compare two identical pages.

Here's what I'm basing my tests on (each random topic pages with a minimum amount of quotes and code tags):
http://wedge.org/pub/feats/6803/new-revs-public-comments/255/ (90% after adding some strategic htaccess rules)
http://www.simplemachines.org/community/index.php?topic=519351.0 (68%)
http://www.elkarte.net/community/index.php?topic=1001.0 (54%)
Quote from Pandos on April 9th, 2014, 10:45 AM
Since the compalin is about CSS....
If the CSS is smaller than 2048 bytes, we could try to inline them.
No it's not, of course for the main file (12KB compressed, 25KB compressed after embedding icons in it), and other files (such as the editor) still need to be included in all topic pages, and the best I can do is to actually move it to the bottom of the page, like they suggest.
Quote from Pandos on April 9th, 2014, 10:45 AM
Cookieless:
Therefor you must have access to the virtual host file to discard cookies for that domain. This should only work if you put your files on a different server IMHO.
The problem is that CLIENTS send a cookie with their request. Servers don't send anything, of course...
Title: Re: Cookieless domains and other things...
Post by: Pandos on April 9th, 2014, 11:20 AM
To disregard cookies there are several steps to perform.
1. configure your server to send no cookies:
php.ini: session.use_cookies = 0

2. Use your webserver (dunno if Apache support this) to disregard cookies on some filetypes, domains, etc.
So even when clients request a cookie, it will be ignored.

Moving CSS to the bottom?
Never heard of someone who actually does it :)
JS is a must, but CSS?

What about combine CSS?

What's next?
Force the use of CDN's to get a higher ranking?
Fully support for HTTP2.0?


Title: Re: Cookieless domains and other things...
Post by: Nao on April 9th, 2014, 12:23 PM
Quote from Pandos on April 9th, 2014, 11:20 AM
To disregard cookies there are several steps to perform.
1. configure your server to send no cookies:
php.ini: session.use_cookies = 0
Okay, let's go back to the basics...
I'm requesting a CSS file. Apache finds it, and sends it to me.
At no point, in this request, did Apache call PHP to do anything. Thus, php.ini is not used.
Quote from Pandos on April 9th, 2014, 11:20 AM
Moving CSS to the bottom?
Never heard of someone who actually does it :)
JS is a must, but CSS?
JS must be added before the closing body tag, so I'm doing that. The JS files, however, are loaded in the header as soon as you've loaded at least one page. (First page = load at bottom to make page load quickly, second page = load at top because it's already cached so it won't stall loading, and JS features will be available sooner to the user.)
CSS is normally NOT mandatory to render the page, so it's loaded async, and I'm not getting while Google has a problem with that. Anyway, I don't see a problem with loading the CSS at the end, it's just that link tags are usually... at the top. Dunno if it's even valid HTML.
Quote from Pandos on April 9th, 2014, 11:20 AM
What about combine CSS?
Too much. If you're visiting only one page and it's not a topic page, you end up having to load the editor CSS as well.
Although it'll only happen for members, so... Hmm... I don't know. Maybe it can be considered.
editor.css is not the only file that could be combined, of course... But generally, I'm trying to keep the main CSS file size to a minimum...!
Quote from Pandos on April 9th, 2014, 11:20 AM
What's next?
Force the use of CDN's to get a higher ranking?
Fully support for HTTP2.0?
Dunno about these.
Title: Re: Cookieless domains and other things...
Post by: Pandos on April 9th, 2014, 12:32 PM
Quote
Okay, let's go back to the basics...
I'm requesting a CSS file. Apache finds it, and sends it to me.
At no point, in this request, did Apache call PHP to do anything. Thus, php.ini is not used.
Sure?
Take a look at http://wedge.org/gz/css/Wilde/chrome34-member-955283.css.gz
Title: Re: Cookieless domains and other things...
Post by: Pandos on April 9th, 2014, 12:37 PM
Quote
JS must be added before the closing body tag, so I'm doing that. The JS files, however, are loaded in the header as soon as you've loaded at least one page. (First page = load at bottom to make page load quickly, second page = load at top because it's already cached so it won't stall loading, and JS features will be available sooner to the user.)
Seems to be OK. But Google might complain about parsing JS files, even if they are cached. :)
Quote
CSS is normally NOT mandatory to render the page, so it's loaded async, and I'm not getting while Google has a problem with that. Anyway, I don't see a problem with loading the CSS at the end, it's just that link tags are usually... at the top. Dunno if it's even valid HTML.
Dunno too.
Title: Re: Cookieless domains and other things...
Post by: Nao on April 10th, 2014, 12:13 AM
Quote from Pandos on April 9th, 2014, 12:32 PM
Quote
Okay, let's go back to the basics...
I'm requesting a CSS file. Apache finds it, and sends it to me.
At no point, in this request, did Apache call PHP to do anything. Thus, php.ini is not used.
Sure?
Take a look at http://wedge.org/gz/css/Wilde/chrome34-member-955283.css.gz
And..?

What you're seeing is the cookie associated with wedge.org. Because it's on that domain, any GET/POST request (HTML, XML, Ajax, binary, image, whatever) sent to the server will contain matching cookies.
Which is why we have to use another domain or subdomain to ensure no cookies are generated from these.

I think the main issue with wedge.org's subdomains is that it used to be set to global cookies, so until one deletes all their cookies for wedge.org and re-logs in, they'll keep sending cookies back to anyothersubdomain.wedge.org, which isn't cool.

I'll do more tests tomorrow, if I can.

I guess my main concern with this topic is: is it okay if I use absolute URLs inside CSS files (url(http-something-absolute) instead of url(../relative))? I mean, it does add more bytes. But there's no way for Wedge to determine in advance whether relative paths would work, unless I change my feature from "custom page replacements" to "custom ASSETS URL", "custom JS URL", and "custom CSS URL". Which, how can I say it..? Would be like a throw-back to 2013 Wedge.
Title: Re: Cookieless domains and other things...
Post by: Nao on April 10th, 2014, 11:48 PM
Absolute URLs in the main CSS file increase the gzipped size by about 15 bytes.
This was enough to trigger in me the need to turn them back into relative URLs...

Which is completely silly. I've been fighting all night to get it to work. It's not, for now. Well, it is, but I keep finding new weird bugs. It's getting annoying... For instance, doing a Purge Cache will regenerate all flag icons, including the ones for disabled languages. Does that ring a bell to you..? ;)
I guess I need to fix that one.

I'm considering making my relative path code simpler, i.e... If a page_replacement string is found, then use absolute URLs. Right now, I'm doing it that way, except I only use absolute URLs if one of the replacement strings has 'gz/css' in it (implying I'm trying to move my CSS to another domain). It works, but it would need more work, because... What if I keep the CSS in the same domain, but I moved the assets to another? Any attempts to access the assets would fail. Maybe I should simply look for gz/css *and* assets, but what if the skin author wants to access yet another path... Lol.
Title: Re: Cookieless domains and other things...
Post by: CJ Jackson on April 11th, 2014, 11:18 PM
Or you could wait for HTTP/2.0 or you could just use SPDY, like I am doing now! Both of those technologies can compress and deal with repeating headers such as cookies and user agent!

The only disadvantage of HTTP/2.0 and SPDY, is the fact that it's requires SSL meaning you need a certificate which you can get for free anyway for non-commercial use.
Title: Re: Cookieless domains and other things...
Post by: Nao on April 12th, 2014, 12:31 AM
Dunno, I've never looked into these things. Honestly, I don't see how something with SSL capability could be faster than HTTP 1.x, but what the hell.

Also, dunno how I could implement that in Wedge.
Title: Re: Cookieless domains and other things...
Post by: CJ Jackson on April 12th, 2014, 12:04 PM
You don't need to implement it into Wedge, only the http server has to implement it.

https://developers.google.com/speed/spdy/mod_spdy/
Title: Re: Cookieless domains and other things...
Post by: Nao on April 12th, 2014, 05:04 PM
Not available on my host... :( :(