Amphtml: Combine AMP Components - Browser-Caching Issue - PageSpeed Insights

[ghost]

Hey, is there a way to combine the AMP extended components to one script? When you use a lot of components, Google PageSpeed Insights gets crazys

Thanks!

[rudygalfi]

@Polylike Breaking out the components is a design feature. That way, if your page _doesn't_ use specific functionality, the user isn't paying for those things with their data and time to download them.

Unfortunately my German capability is non-existent, so I'm not sure what to make of your error -- @cramforce :) -- but we can raise this with the Google PageSpeed Insights team.

[ghost]

@rudygalfi Sorry for the german screenshot and my non-existent english capabilitys :-)

I'm working on a Mobile-First-Super-Fast-Website with AMP HTML but i need to include a lot of small scripts. The results of "Check your Mobile-First-Super-Fast-Website" tools like Google PageSpeed Insights return "Leverage browser chaching" "to many scripts/requests" e.g. and im asking me: is there a better solution to combine these scripts?

[cramforce]

When served from the AMP cache, the cache time is infinite.

We still want to make the origin case fast, but there is a trade off with the usability of non-versioned URLs and caching.

One thing that PageSpeed ignores is that we send the stale-while-revalidate header, authorizing the browser to once-in-a-month use a stale version while it is fetching a new version into the cache. This is currently being implemented into Chrome.

[talawahtech]

Hi,

I get get that AMP is broken down into components by design, and rightly so, but the question is basically whether or not the AMP CDN can be configured to serve up pre-bundled (or dynamically bundled and then cached) assets based on well defined urls e.g.

<script async src="https://cdn.ampproject.org/v0.js?1=amp-analytics-0.1.js&2=amp-youtube-0.1.js"></script>

That way multiple extensions can be fetched using a single url. If it is two burdensome to manage this for all extensions, perhaps for just the top 10 or 15 most popular.

The default urls would continue to work as they do now, but this feature would allow developers to optimize even further.

[Gregable]

Google Fonts does something similar:
https://fonts.googleapis.com/css?family=Lato|Roboto
I don't know if this is necessary with HTTP2 pipelining though. It also reduces cache-ability with unique URLs on each document.

[cramforce]

Correct. Bundling is bad (Unless files are super tiny, but AMP is not playing in that world) in an HTTP 2 world. It increases URL entropy which reduces cache effectiveness and has little other benefit.

HTTP2 plus stale-while-revaldiate is a much better option. Also, note, that while AMP document files may not be delivered by HTTP2 (they always are when served from the AMP Cache), the JS files are always served with HTTP2.

[jaspersorrio]

I think the problem at hand is not about combining the scripts but enabling caching on the cdn's server side.

Since the amp cdn serves up versions of amp, shouldn't caching on amp cdn's server be enabled?

I do understand that amp is undergoing much changes currently. But this should be fixed in the future to allow caching optimizations to kick in.

[cramforce]

For Chrome users this will be fixed when our foreign-fetch ServiceWorker launches. Beyond that cache time has to stay reasonably low to avoid skew issues.

[ghost]

Hi there,
this issue is due at max-age parameter on https://cdn.ampproject.org: cache-control: private, max-age=3000, stale-while-revalidate=2592000

It's only 50 minutes and I think this value should be increased.

Thanks,
Marco

[cramforce]

We can't really increase it for the main JS, because they are unversioned. When AMP is delivered from an AMP cache, the URLs have infinite caching and very soon there will be a ServiceWorker enabling long cache times on these URLs. PageSpeed won't care, but we don't care about PageSpeed, we care about UX.

[ahmedkaludi]

@cramforce I agree and we care about UX too but users take the Google's pagespeed tool and it's recommendation very seriously and we need a solution for this, because people think that google AMP isn't really good because it doesn't rank high in Pagespeed tool. I know what you are thinking, but this is the user's perspective, Think about this from the User Experience perspective.

[ghost]

Hello people! I also agree. Anyway, as I said before this is not an issue of AMP but of infrastructure, so * it is not required to combine AMP * components, but to avoid this "controversy" with Google's pagespeed it is enough to ask to system engineers who manage the web servers hosting the url https://cdn.ampproject.org to increase the header "max-age" from the current value 3000 (50 minutes) with a higher (for example, 86400 = 1 day)

Cheers,
Marco

[cramforce]

This won't happen for a while. Explained above. We actually do see this from the user perspective. We do not see it from a customer perspective.

With the upcoming ServiceWorker launch the effective cache time is infinite, so from that time on PageSpeed will be literally wrong.

[darshkemo]

@marcofortina
I made some trick that enhanced pagespeed that has this specific problem of 50 minutes cashe time
it didn't remove the 50 minutes message but increased pagespeed from 84 to 91 so it is really a big optimization score.
in case you only load cdn.ampproject.org/v0.js
add the following:
before the

in case you load more one of other amp scripts, you can combine them in one url ie
before the

[cramforce]

Huh? No that combination doesn't work.

On Sat, Nov 18, 2017 at 6:49 AM, darshkemo [e-mail] wrote:

@marcofortina https://github.com/marcofortina
I made some trick that enhanced pagespeed that has this specific problem
of 50 minutes cashe time
it didn't remove the 50 minutes message but increased pagespeed from 84 to
91 so it is really a big optimization score.
in case you only load cdn.ampproject.org/v0.js
add the following:
before the

in case you load more one of other amp scripts, you can combine them in
one url ie
before the

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ampproject/amphtml/issues/3454#issuecomment-345446938,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeTyF77X0K1Zi9CEixVTpIpDC0quC5ks5s3u6HgaJpZM4Iumzr
.

[darshkemo]

Yes, you are correct.
it produced AMP validation errors so I removed them, sorry
I had another trick that increased score on mobile 7 points which is
/amp redirection on mobile waste response time which affect pagespeed score.
I let the /amp redirection occur for mobile from htaccess rather than from CMS php/plugin
the difference is we save loading time of CMS/DB ..etc and decrease redirection time which saved at my case 0.8 seconds hence enhanced pagespeed score
below is the .htaccess lines

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{REQUEST_URI} !/amp/?$ [NC]
RewriteCond %{HTTP_USER_AGENT} (2.0 MMP|240x320|400X240|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|Googlebot-Mobile|hiptop|IEMobile|KYOCERA/WX310K|LG/U990|MIDP-2.|MMEF20|MOT-V|NetFront|Newt|Nintendo Wii|Nitro|Nokia|Opera Mini|Palm|PlayStation Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|SHG-i900|Small|SonyEricsson|Symbian OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|webOS|Windows CE|WinWAP|YahooSeeker/M1A1-R2D2|iPhone|iPod|Android|BlackBerry9530|LG-TU915 Obigo|LGE VX|webOS|Nokia5800) [NC]
RewriteRule ^([a-zA-Z0-9/-]*?)/?$ $1/amp [L,R=302]