prioritize_critical_css not always working...

[John Dever]

Reference:
curl "http://mps-test-criticalcss.hibustudio.com/?PageSpeedFilters=prioritize_critical_css,debug"

I had to disable the prioritize_critical_css filter today as we were getting sporadic reports on some of our legacy flash based websites that (after troubleshooting) the css that was supposed to fire some of the flash objects were not loading correctly.

Fine.

What bothers me is that the behavior wasn't consistent and I wasn't able to catch this in our UAT environments. One of the reasons why appears to be that when the prioritize_critical_css filter is turned on I can consistently get different payload sizes.

Please note the character counts when running the following several times:
curl "http://mps-test-criticalcss.hibustudio.com/?PageSpeedFilters=prioritize_critical_css,debug"

In many cases that on average the payloads are 375 characters vs 589 characters, give or take.

Any idea what might cause this?

Thanks

[John Dever]

Bump..

[Matt Atterbury]

Hi John,

Sorry for the tardiness in responding ...

On Mon, Sep 16, 2013 at 6:22 PM, John Dever <deve...@gmail.com> wrote:

I had to disable the prioritize_critical_css filter today as we were getting sporadic reports on some of our legacy flash based websites that (after troubleshooting) the css that was supposed to fire some of the flash objects were not loading correctly.

How is the flash being fired by CSS? I couldn't work it out from your test site because I couldn't find any flash in there.

The way prioritize_critical_css works is that the instrumentation code (a bunch of JS at the end of the page) checks every CSS selector to see if any DOM element(s) use that selector; if so, the selector and its associated rule are 'critical' and will be included, if not they're not so they're removed from the page.

So, if the flash object isn't returned/detected by the JS function document.querySelectorAll() then we won't include it in the critical CSS and it will get dropped.

However, in this case I'd expect this to be consistent for instrumented pages, meaning that the first few views will work but later ones won't.

I think one way this could be worked around is to add a dummy element, say a zero width/height div, that uses the flash-triggering CSS selectors.

What bothers me is that the behavior wasn't consistent and I wasn't able to catch this in our UAT environments. One of the reasons why appears to be that when the prioritize_critical_css filter is turned on I can consistently get different payload sizes.

Please note the character counts when running the following several times:
curl "http://mps-test-criticalcss.hibustudio.com/?PageSpeedFilters=prioritize_critical_css,debug"

In many cases that on average the payloads are 375 characters vs 589 characters, give or take.

This isn't very surprising because some views will be the original optimized page (like the very first one), some will have instrumentation JS injected into them (say the next 1 or 2), and some will be fully optimized so will be less CSS and no instrumentation JS.

cheers, m.

[John Dever]

'This isn't very surprising because some views will be the original optimized page (like the very first one), some will have instrumentation JS injected into them (say the next 1 or 2), and some will be fully optimized so will be less CSS and no instrumentation JS.'

To your last point, and maybe I am misunderstanding, are you saying that each pull of the page might be a more optimized version of the page until all of the optimizations are complete and cached?

I guess I am expecting that after everything has processed I shouldn't expect to see variations in return data once everything is done.

--
You received this message because you are subscribed to a topic in the Google Groups "mod-pagespeed-beta-testers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mod-pagespeed-beta-testers/9rQjMn0UGQA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mod-pagespeed-beta-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-beta-testers/CAGnGm_M3N6Q2RUMgtzYNY%3D9QO3kYwNb68AsdwcoNyhmBCH9mtw%40mail.gmail.com.

[John Dever]

Hit send on accident...

What I am seeing is that if I hit it 100 times, every other time or so will be a different payload, even if the html hasn't changed.

I will look into the flash stuff specifically. I didn't really put too much effort into it as I just accepted the fact that Flash is annoying. I will take a closer look shortly, however.

[Matt Atterbury]

On Thu, Sep 26, 2013 at 3:11 PM, John Dever <deve...@gmail.com> wrote:

To your last point, and maybe I am misunderstanding, are you saying that each pull of the page might be a more optimized version of the page until all of the optimizations are complete and cached?

Yes, that's correct, although in this case the number of optimized versions will be low since all it does the one filter, prioritize_critical_css.

 

I guess I am expecting that after everything has processed I shouldn't expect to see variations in return data once everything is done.

The problem is (AFAIK) because we re-instrument a page after 5 seconds (!).

We agree this is damn short but we figured it was where we'd start since we don't want to have stale critical CSS.

We're working on making this longer and smarter.

cheers, m.

[John Dever]

Fair points. Thanks for clarifying. I of course had my head buried in the fact that the content wasn't changing at the time, not what would happen if it did. :)

Curious, with this filter do you distinguish between 'external' CSS with defined cache headers, and CSS that is embedded with the HTML? I imagine that the embedded bits are where it becomes a pain to deal with, obviously because we would prefer not the cache the HTML.

[Matt Atterbury]

On Fri, Sep 27, 2013 at 8:32 AM, John Dever <deve...@gmail.com> wrote:

Curious, with this filter do you distinguish between 'external' CSS with defined cache headers, and CSS that is embedded with the HTML? I imagine that the embedded bits are where it becomes a pain to deal with, obviously because we would prefer not the cache the HTML.

I don't think so, though as you say it complicates the caching logic since we don't cache HTML.

I've cc'd Jud who should know for sure.

[John Dever]

Was about to go off on a tangent, then reread: "The problem is (AFAIK) because we re-instrument a page after 5 seconds (!)."

Is that a global behavior, or one specific to the prioritize css filter?

[Matt Atterbury]

On Fri, Sep 27, 2013 at 10:53 AM, John Dever <deve...@gmail.com> wrote:

Was about to go off on a tangent, then reread: "The problem is (AFAIK) because we re-instrument a page after 5 seconds (!)."

Is that a global behavior, or one specific to the prioritize css filter?

It's specific to the prioritize_critical_css filter.

m.

[John Dever]

In that case!....

I was musing about the idea of having a sort of optional parameter for this filter to only prioritize external CSS, or specific external CSS, and whether or not that would be all that helpful or not. From what I understand you all tag and store metadata for every piece of content that you rewrite and also in this case inline (because of the inline filter...), and I'm sure that the TTL is stored there as well.

Would it be too difficult to implement, sort of, some kind of QOS or priority tier, to prevent constant reimplementation on CSS that you know 'shouldn't' change based on its TTL? This way when the HTML is reimplemented to re-prioritize the CSS, static CSS doesn't have to be reprocessed, and dynamic CSS could be handled under the current (but separate) logic.

In the grand scheme of things, the majority of our CSS is static, which I imagine is true for most, and only a small bit of it would be able to be changed by the customer. The consumer DIY CMS case might be different than say a wordpress site where everything could be very fluid since the owner can change anything and everything (as I was discussing with someone on our business team this morning about), and that the nature of our business is to provide a simple and restricted CMS so that the customer doesn't have to worry about CSS.

Thanks

[Matt Atterbury]

I haven't read/processed your ideas completely (yet! :-), but I have to point out that the problem isn't just changing CSS, it's also what CSS is used.

For example, you might have CSS that never changes, but if the HTML changes so that it uses more/less of it, the "critical CSS" changes, and we need to re-instrument.

--

You received this message because you are subscribed to the Google Groups "mod-pagespeed-beta-testers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-beta-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-beta-testers/9e04142d-7aa7-44a7-b896-eb22259fd9e3%40googlegroups.com.

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

[John Dever]

Yea, I thought about that, and I guess what I was suggesting (in my head, without actually writing it)  kind of changes the definition of 'prioritize' in terms of the filter today more to prioritize in tiers, the best that you can, without doing unnecessary processing.

If you have a block of prioritized CSS that wont ever change within the confines of the TTL's, and considering a lot of the prioritization of the CSS just moves it from random places that the developers might have throw it to the top of the HTML below the critical javascript, it could make sense to just assume that if in a perfect world the ordering looked like this:
CSS 1 dynamic
CSS 2 static
CSS 3 static
CSS 4 dynamic
CSS 5 static

Consider that maybe some of the those CSS's were placed in horrible places by the developers for whatever reason (this being the reason why I love you guys), just lifting them to the top of the HTML itself would be helpful.

CSS 2 static
CSS 3 static
CSS 5 static
CSS 1 dynamic
CSS 4 dynamic

I could be trying to solve a non-issue, but it is at least helping me understand your product better.

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-beta-testers+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-beta-testers/9e04142d-7aa7-44a7-b896-eb22259fd9e3%40googlegroups.com.

[Jud Porter]

Hey John,

Sorry for being slow to respond, I was out of town on vacation at the end of last week.

You are definitely right that we need to be smarter about when and how often we reinstrument for prioritize_critical_css, and it's something we'll be tackling soon. The TTL of resources is certainly a part of that, as is looking at how much the critical CSS reported by the beacon changes from run to run. If it changes significantly, then we should take that as a signal that our old beacons are  stale now and we should reinstrument more often until we reach quiescence.

I'm not sure I've fully groked what you are proposing, but if I understand correctly, you're suggesting to divide up the CSS into basically low-variable and high-variable tiers so that we could potentially be smarter about which set of selectors we have to check, is that right? One issue is that because of the cascading nature of CSS, we can't safely reorder CSS. This is also why we when we lazyload the full CSS after onload, we have to load the full CSS, and not just the non-critical rules. Otherwise the resulting styles may change since they can cascade differently. It'd be nice if our CSS parsing was smart enough to understand when it's safe to reorder CSS rules, but we don't currently have that capability.

-Jud

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-beta-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-beta-testers/2c696b7c-82ed-4aff-ab66-23fa2812e21e%40googlegroups.com.

[John Dever]

No worries. Hope you had a great vacation.

Thanks for the detailed response. You got my point, and I get your response. I look forward to testing whatever you all come up with.

Aside: If I can, I will try and reproduce with some detail the issues that I was having this filter and our flash based sites. It was causing some really funky caching and because of the reinstrumentation and something else in the browser cache, it was causing things not to fire and be quite hard to diagnose and reproduce.

I might say, shooting from the hip here, that you might consider flagging this as a higher risk. Unfortunately I, nor our QA, could catch it until it made it into prod.

To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-beta-testers+unsubsc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-beta-testers/9e04142d-7aa7-44a7-b896-eb22259fd9e3%40googlegroups.com.

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

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-beta-testers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-beta-testers+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-beta-testers/2c696b7c-82ed-4aff-ab66-23fa2812e21e%40googlegroups.com.