Rel=Preload, HTTP/2 Server Push, and mod_pagespeed

[ka...@consumermedia.com]

Hello Everyone.

Our setup includes mod_pagespeed, ngnix with http/2, and a CDN that supports http/2. We want to start utilizing http/2 server push.

We are adding a rel=preload header link for assets we are going to push.  

Example: 

add_header Link '<https://cdn.domain.com/wp-content/themes/theme/A.style.css+css,,_vendor,,_bootstrap.css,Mcc.1eqL5uHGFx.css.pagespeed.cf.otVQjC3c4K.css>; rel=preload; as=style';

After pagespeed optimizes a resource such as our CSS and rewrites the URL, it is sent to our CDN. In the header link example above, we specified the CDN URL. I know that is not the best way to do it though. When we clear our caches, which we do often, pagespeed generates a new URL and the existing preload header link becomes invalid. I'm looking for a way to keep our preload links valid even after pagespeed rewrites urls.

What is the best way to preload pagespeed assets and ensure that the preload reference always remains valid, even after pagespeed rewrites the url again?

Thanks,

Karl

[Joshua Marantz]

We are working on automatically generating the correct preload headers in PageSpeed for h2.  As far as our current software goes, here are the options:

1. You observed that PageSpeed generates a new URL when your cache is cleared (which cache?).  However, the URL that PageSpeed generates is strictly a function of the rewritten contents.  So if you flush your cache, but don't change the asset, then PageSpeed will generate exactly the same URL every time.  But maybe when you clear your caches, you could run a script to 'wget' or 'curl' your HTML a few times, and then scrape the output for the rewritten CSS filename, and then populate your preload hint using that.   That way if your change your CSS content, then preload hints can track the changes in the signed URL.  I don't think it would be all that difficult.

2. You could use "ModPagespeedRewriteLevel OptimizeForBandwidth", which will preserve all the URLs, rather than rewriting them as .pagespeed. URLs.  You won't get combining or cache extension, but you will get minification and compression.  It may be that robustly deploying preload hints benefits your users more than the things that PageSpeed can do when it rewrites URLs.

-Josh

--
You received this message because you are subscribed to the Google Groups "mod-pagespeed-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mod-pagespeed-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mod-pagespeed-discuss/7c448df1-3a73-43e9-a467-3ece3f550fbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeff Kaufman]

We don't currently have good support for rel=preload or server push,
but we think this is something we can do a good job with. We do need
to extend our code some to support this, and Maks (cc'd) has been
working on it.

What you're seeing with your current setup is surprising to me,
though. That combined css url shouldn't become invalid if you clear
your cache; PageSpeed should be able to regenerate that file given
just the url. Additionally, once your cache is warm again you should
get exactly the same urls as before because they're only based on the
content. For the first few pageloads after reloading you'll be adding
rel=preload for one resource and then referencing a less optimized one
in the html, but very soon you should be back to a healthy state.

Also, it's surprising to me that you would clear your caches often; if
a resource changes can you just purge that one?

On Sun, Jul 31, 2016 at 12:34 AM, <ka...@consumermedia.com> wrote:

[Karl Modl]

Greetings! I just realized that I never responded to your replies. My apologies and thank you for the comments. They were helpful and informative.

We launched our own private CDN shortly after starting this discussion. We built the network with h2o servers for http/2 server push and have our ngx_pagespeed setup behind it. We are currently using a nginx lua module that automatically determines which resources should have preload hints for server push.

It is working but I wanted to test some alternatives. You mentioned back in July that Maks was trying to improve support for rel=preload and server push. How is that coming along? Anything exciting in the pipeline? I would love to have pagespeed add the preload hints for server push. Any chance we'll be able to do that soon?

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

[Joshua Marantz]

Yes, we hope to have a release out soon with this feature.  The release has taken longer than expected mainly due to issues with our build-system and dependencies changing.  Sorry for the delay!

[ka...@consumermedia.com]

We just upgraded PageSpeed to Release 1.12.34.1-beta. It is great that we now have some support for Preload, Srcset, and AMP. However, I see that PageSpeed is adding "no push" with preload. Is there a way to disable the "no push" reference. We are using server push and PageSpeed's no push reference kills it.

[Jeff Kaufman]

Sorry, this isn't a configurable setting; it's hardcoded to always
append "nopush":
https://github.com/pagespeed/mod_pagespeed/blob/master/net/instaweb/rewriter/push_preload_filter.cc#L118

> --
> You received this message because you are subscribed to the Google Groups
> "mod-pagespeed-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mod-pagespeed-di...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/mod-pagespeed-discuss/2ec5871f-3092-493b-9056-a65189f2cc48%40googlegroups.com.