Testing prioritize_critical_css and inline_preview

theartofweb

unread,

Apr 14, 2013, 6:58:24 AM4/14/13

to mod-pagespeed...@googlegroups.com

Test site: www.simnet.net.au

Issues with prioritize_critical_css:

A new <style> tag is being inserted before the HEAD block instead of inside. This is not valid HTML:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

This was not the case on another website/server where the <style> appears correctly inside the HEAD block.

New <noscript> and <script> tags are being inserted after the closing HTML tag instead of inside BODY, leading to more validation errors;
The <noscript> inserted at the start of BODY contains:

<div style="display:block">Please click <a href="http://www.simnet.net.au/?ModPagespeed=noscript">here</a> if you are not redirected within a few seconds.</div>

</noscript>

will this impact indexing/SEO? If the <noscript> code is executed the original page will have all content hidden, and redirect to a new page with identical content. Maybe an idea to add "nofollow" to the link and "noindex" to the new URL, but many spiders will follow regardless...
the self-closing tag assumes XHTML and should adjust to the DOCTYPE (same problem in combine_css);
the <style> selector should be changed to something like: body * { display: none; }
the <div> should define a background and text colour to ensure it stays visible;
and maybe use better wording than "Please click here ..."?

This filter does a good job of identifying which styles are needed based on tag, id and class, but is confused by advanced selectors such as "input:required" and ".someclass tr:nth-child(even)" and sometimes prioritises them unnecessarily.

Issues with inline_preview_images:

In our testing on SIMNET, the large photo on the homepage (710 x 400) was replaced by a 15,000 character data URI which did load faster than the original and wasn't too chunky;
However, the overall page load time was longer due to the extra HTML. The page size went from 3.3kb to 4.9kb (prioritize_critical_css) to >17kb (inline_preview_images) causing load times to increase from 1.3s to 1.5s. It will also increase bandwidth usage;
I'm assuming there is (or will be) a way to target only images of a specific size, or only specific photos? By default the website logos are also being converted to inline previews which could upset some business clients.

GTmetrix reports (HOME, SIM NEWS):

Again, "request counts" are probably not 100% accurate as some files have been moved outside of the HTML/BODY and are not being counted.

theartofweb

unread,

Apr 14, 2013, 7:23:03 AM4/14/13

to mod-pagespeed...@googlegroups.com

To prevent images <5kb being previewed in low quality:

ModPagespeedEnableFilters inline_preview_images

ModPagespeedMinImageSizeLowResolutionBytes 5120

The documentation doesn't say what the default value is, but it appears to be 0.

Also:

ModPagespeedMaxInlinedPreviewImagesIndex 2

prevents more than 2 previews being generated on one page (default is 5).

The JavaScript trigger for loading the full resolution images is inserted immediately after the last image on the page that requires a lowsrc preview, or omitted entirely if no previews are needed.

theartofweb

unread,

Apr 14, 2013, 7:35:56 AM4/14/13

to mod-pagespeed...@googlegroups.com

Correction:

ModPagespeedMaxInlinedPreviewImagesIndex 2

means than only the first two IMG tags on the page will be considered for inline preview and the rest not, regardless of other settings.

Matt Atterbury

unread,

Apr 15, 2013, 2:08:50 PM4/15/13

to theartofweb, mod-pagespeed-beta-testers

Hi,

On Sun, Apr 14, 2013 at 6:58 AM, theartofweb <dun...@chirp.com.au> wrote:

Test site: www.simnet.net.au

Issues with prioritize_critical_css:

A new <style> tag is being inserted before the HEAD block instead of inside. This is not valid HTML:

This will be fixed in the next beta release due out later this week.

New <noscript> and <script> tags are being inserted after the closing HTML tag instead of inside BODY, leading to more validation errors;

This too will be fixed in the next beta release.

The <noscript> inserted at the start of BODY contains:

will this impact indexing/SEO? If the <noscript> code is executed the original page will have all content hidden, and redirect to a new page with identical content. Maybe an idea to add "nofollow" to the link and "noindex" to the new URL, but many spiders will follow regardless...

AFAWK no this will not affect indexing/SEO as it's only for browsers that don't have JavaScript enabled. That said your suggestion is good and I'll raise it internally.

the self-closing tag assumes XHTML and should adjust to the DOCTYPE (same problem in combine_css);

What is the 'self-closing tag'?

the <style> selector should be changed to something like: body * { display: none; }

Why so?

the <div> should define a background and text colour to ensure it stays visible;

Good point.

and maybe use better wording than "Please click here ..."?

What do you suggest and why is 'Please click here' poor?

This filter does a good job of identifying which styles are needed based on tag, id and class, but is confused by advanced selectors such as "input:required" and ".someclass tr:nth-child(even)" and sometimes prioritises them unnecessarily.

Yep. Our CSS parser doesn't handle a lot of CSS so if it finds anything it can't parse it has to assume that it's critical since it's safer than leaving it out. So this is WAI until our parser improves.

Issues with inline_preview_images:
In our testing on SIMNET, the large photo on the homepage (710 x 400) was replaced by a 15,000 character data URI which did load faster than the original and wasn't too chunky;

However, the overall page load time was longer due to the extra HTML. The page size went from 3.3kb to 4.9kb (prioritize_critical_css) to >17kb (inline_preview_images) causing load times to increase from 1.3s to 1.5s. It will also increase bandwidth usage;

Does the original time (1.3s) and bandwidth (whatever) include the time and bandwidth of download the image as separate URL? In many case, though yes not all, we've seen that inlining the image results in faster download/rendering because it eliminates the cost of another HTTP connection.

I'm assuming there is (or will be) a way to target only images of a specific size, or only specific photos? By default the website logos are also being converted to inline previews which could upset some business clients.

IIRC you can already limit the size of inlined images, though to be honest I don't know if that's overridden/ignored by the new filters.

I believe we are planning on an attribute to disable inlining of a specific img.

Re the website logos, are these on other sites (like, say www.facebook.com)? If so, AFAIK they should only be inlined if you have authorized that domain, but again I could be wrong or there could be a bug there. Why do you think these other website owners might get upset - do they use these are beacons?

Finally, thanks for the fabulous data and feedback, we really appreciate it!

m.

--
"Klaatu barada nikto" (754) 444-6288

theartofweb

unread,

Apr 16, 2013, 9:07:40 AM4/16/13

to mod-pagespeed...@googlegroups.com, theartofweb

the self-closing tag assumes XHTML and should adjust to the DOCTYPE (same problem in combine_css);

What is the 'self-closing tag'?

Having an extra "/" at the end of the tag. It's not valid in HTML4, but is required in XHTML and optional in HTML5.

e.g.

If the DOCTYPE specifies HTML4 or lower the "/" should be omitted. Otherwise the page will throw validation errors making it harder to debug.

the <style> selector should be changed to something like: body * { display: none; }
Why so?

What you have now only hides the contents of certain tags: table, div, span, font, p { display: none; }

Any content not a child one of those will still be visible. "body * { display: none; }" should hide all content, plus it's shorter.

the <div> should define a background and text colour to ensure it stays visible;
Good point.

and maybe use better wording than "Please click here ..."?
What do you suggest and why is 'Please click here' poor?

For accessibility, "here" is a very small target, and for usability you should include a verb. e.g. "Click this link if …".

Issues with inline_preview_images:
In our testing on SIMNET, the large photo on the homepage (710 x 400) was replaced by a 15,000 character data URI which did load faster than the original and wasn't too chunky;

However, the overall page load time was longer due to the extra HTML. The page size went from 3.3kb to 4.9kb (prioritize_critical_css) to >17kb (inline_preview_images) causing load times to increase from 1.3s to 1.5s. It will also increase bandwidth usage;

Does the original time (1.3s) and bandwidth (whatever) include the time and bandwidth of download the image as separate URL? In many case, though yes not all, we've seen that inlining the image results in faster download/rendering because it eliminates the cost of another HTTP connection.

?! with this filter the original image (60-70kb) is still downloaded as well as inlined (15kb). The inlined version is just used to fill the space until the full resolution version is downloaded. The visual effect is definitely better, making the website appear faster, but in reality it takes longer for all elements to be loaded, and uses more bandwidth.

I'm assuming there is (or will be) a way to target only images of a specific size, or only specific photos? By default the website logos are also being converted to inline previews which could upset some business clients.

IIRC you can already limit the size of inlined images, though to be honest I don't know if that's overridden/ignored by the new filters.
I believe we are planning on an attribute to disable inlining of a specific img.

Re the website logos, are these on other sites (like, say www.facebook.com)? If so, AFAIK they should only be inlined if you have authorized that domain, but again I could be wrong or there could be a bug there. Why do you think these other website owners might get upset - do they use these are beacons?

Only the websites own logos and branding. Setting the lowres inlining cutoff to 5kb solved it in this case.

We have/had clients who would flip out at seeing their logo appear at a low resolution, even for just a flash. (-;

Finally, thanks for the fabulous data and feedback, we really appreciate it!

No problem. I hope to test more sites next week on our main server. Maybe when the new beta arrives?

Matt Atterbury

unread,

Apr 16, 2013, 9:22:07 AM4/16/13

to theartofweb, mod-pagespeed-beta-testers

Thanks for great feedback ... give me some time to digest it! :-)

Matt Atterbury

unread,

Apr 16, 2013, 10:08:43 AM4/16/13

to theartofweb, mod-pagespeed-beta-testers

HI again,

Regarding this point:

The <noscript> inserted at the start of BODY contains:

will this impact indexing/SEO? If the <noscript> code is executed the original page will have all content hidden, and redirect to a new page with identical content. Maybe an idea to add "nofollow" to the link and "noindex" to the new URL, but many spiders will follow regardless...

AFAWK no this will not affect indexing/SEO as it's only for browsers that don't have JavaScript enabled. That said your suggestion is good and I'll raise it internally.

I've asked around and done some investigation and it's not clear to me the benefit of adding nofollow nor noindex.

[I presume you meant this? <meta content="noindex, nofollow">]

This will stop spiders from indexing the noscript block and from following the link to the ?noscript page.

It's not clear why you'd want that - unless the spider processes this page regardless nothing will get processed (and I freely confess I have no idea if they would or wouldn't). But even if it does process it ...

In the ?noscript version of the page we insert <link rel="canonical" href="original-URL"/> to indicate that it's the same contents as the original page so indexing should be unaffected.

Thanks! m.

theartofweb

unread,

Apr 16, 2013, 11:42:17 AM4/16/13

to mod-pagespeed...@googlegroups.com

The rel="canonical" should be adequate. I hadn't checked that far yet (-;

We have already seen 10 user agents following the ?noscript links in the last 48 hours on one website. No search engines.

On Sunday, April 14, 2013 1:58:24 PM UTC+3, theartofweb wrote:

Reply all

Reply to author

Forward

Testing prioritize_critical_css and inline_preview_images

theartofweb

theartofweb

theartofweb

Matt Atterbury

theartofweb

Matt Atterbury

Matt Atterbury

theartofweb