Closed Bug 1379064 Opened 7 years ago Closed 7 years ago

No max-age or expires headers/values on many static assets in new-desktop AMO

Categories

(Cloud Services :: Operations: AMO, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: stephend, Assigned: wezhou)

References

()

Details

(Keywords: perf)

Comparing the in-development desktop redesign of AMO[0] vs. current AMO[1] (on staging), WebPageTest.org, we got an "F" (compared with an "A" on the current site), due to the following:

Leverage browser caching of static assets: 18/100
FAILED - (No max-age or expires) - https://addons-amo-cdn.allizom.org/6d50ec7554d41365f085fe4281b2b9a4.svg
FAILED - (No max-age or expires) - https://addons-amo-cdn.allizom.org/0eff19a04ae3b96909f34d747d538642.woff2
FAILED - (No max-age or expires) - https://addons-amo-cdn.allizom.org/04d57ec285657e0dd888838cdb22d5b9.svg
FAILED - (No max-age or expires) - https://addons-amo-cdn.allizom.org/c07486b26f72420648787285a453128a.svg
FAILED - (No max-age or expires) - https://addons-amo-cdn.allizom.org/a4b5655f2fdbe07f1fe26d5a77ab79a9.woff2
FAILED - (No max-age or expires) - https://addons-amo-cdn.allizom.org/a1ea7f348ffcb1af730d8bb90d6c7792.woff2
FAILED - (No max-age or expires) - https://addons-amo-cdn.allizom.org/979a13914c3398f40c3114ead422ed41.woff2
FAILED - (No max-age or expires) - https://addons-amo-cdn.allizom.org/amo-4cdc7b0ec162c0f3a899.js
FAILED - (No max-age or expires) - https://addons.allizom.org/
FAILED - (No max-age or expires) - https://addons-amo-cdn.allizom.org/amo-157cd37a14b8a76a473ae699778a61c6.css
FAILED - (No max-age or expires) - https://addons.allizom.org/favicon.ico

[0] http://wpt1.dev.mozaws.net/result/170707_XC_2/3/performance_optimization/#cache_static_content
[1] http://wpt1.dev.mozaws.net/result/170707_78_3/
Assignee: nobody → wezhou
Hi, Wei - do you think you might be able to get to this sometime soon-ish?  My Q3 goal is to help the AMO team ensure performance parity (or better) as they rewrite the website this quarter - see https://github.com/mozilla/addons-frontend/issues/2868.

I'd like to reduce/eliminate config differences, where possible, so I can start comparing, with useful metrics, and this would be one key part of that; thanks!
Flags: needinfo?(wezhou)
Thanks for your patience, Stephen. The only app we've spent any time on optimizing is the Discovery Pane which does specify some caching headers. We will need to be a bit careful when we tweak these headers because they can trigger subtle bugs as we have already seen in the Discovery Pane.
With Kumar's commet #2, can we close this ticket for now? Because the ticket is for AMO desktop site, whereas only discopane (the mobile site) has been spent time optimizing. We can either re-open or create a new ticket once the desktop site is also optimized then do this and compare.

Also Stephen, I can't access either [0] or [1], they timed out for me.
Flags: needinfo?(wezhou)
Wei, I want to track this where the work is/will be, in order to have performance parity.  Wei/Kumar: when we're doing the optimization work, will the headers be implemented through https://github.com/mozilla/addons-frontend, https://github.com/mozilla/addons-server, or somewhere else?  (Or a combination?)
Flags: needinfo?(kumar.mcmillan)
Since these files are served from the CDN, I'm not sure if we can modify their cache properties from addons-frontend. I doubt we can. I think this is maybe something Wei would have to modify in our CDN settings but I'm not sure how it works.
Flags: needinfo?(kumar.mcmillan)
Hi Stephen,

I can't access either [0] or [1], so I'm not sure if the info in them is useful for me to troubleshoot or not.

Can you provide a link that returns max-age or expires for me to compare?
(In reply to :wezhou from comment #6)
> Hi Stephen,
> 
> I can't access either [0] or [1], so I'm not sure if the info in them is
> useful for me to troubleshoot or not.
> 
> Can you provide a link that returns max-age or expires for me to compare?

Sorry, the past results were wiped due to the WPT AMI being re-deployed after that last incident.

Here are public links:

[0] AMO redesign, on dev (with Cookie: mamo=on header):

https://www.webpagetest.org/performance_optimization.php?test=170812_CT_ZFY&run=1#cache_static_content

[1] AMO dev, no redesign:

https://www.webpagetest.org/performance_optimization.php?test=170812_4Z_ZKD&run=5#cache_static_content
Hi Stephen,

The reason why you see the different behaviors in the mobile site and the legacy site is because as mentioned in https://github.com/mozilla/addons-server/issues/4649#issuecomment-279546873, for the legacy site, "-dev and stage do not use a CDN today, they just use the CDN origin directly." Basically, the CDN origin sets "max-age" or "expire" in the headers, whereas CDN doesn't.

Additionally, you don't see the difference on -prod because both the mobile and legacy sites use CDN on -prod, not because they set "max-age" or "expire" in the headers.


So the question is, is the ask of this ticket to have us set the "max-age" or "expire" in the headers, or have us set up CDN for -dev and -stage for the legacy site? 

The title and the description of this ticket seem to imply the former, however since we don't set the "max-age" or "expire" in the headers on -prod today, I'd think it shouldn't be a concern for -dev or -stage without them.

If the ask is for the later, i.e., to have us set up CDN for -dev and -stage for the legacy site, can you help justify why we should do that? Not using CDN for these two environments apparently helps save costs.
(In reply to :wezhou from comment #8)
> Hi Stephen,

Hi Wei -

<polite snip of content, just to focus the reply>

> So the question is, is the ask of this ticket to have us set the "max-age"
> or "expire" in the headers, or have us set up CDN for -dev and -stage for
> the legacy site? 

When originally filed, I didn't know which (origin vs. CDN) was responsible for which content.  The original intent, though, was (as with my other filed Issues/bugs) to get addons-dev/addons.allizom.org (esp. redesign/mobile site) as close to parity, config-wise, with prod, sans scaling, of course, so I could directly-compare best-practice recommendations and scores (outside of raw performance, since we can't directly compare dev/stage to prod, naturally).

In the originally-filed context, then, it was to have the appropriate header/value(s) (max-age or expires) set. 

> The title and the description of this ticket seem to imply the former,
> however since we don't set the "max-age" or "expire" in the headers on -prod
> today, I'd think it shouldn't be a concern for -dev or -stage without them.
> 
> If the ask is for the later, i.e., to have us set up CDN for -dev and -stage
> for the legacy site, can you help justify why we should do that? Not using
> CDN for these two environments apparently helps save costs.

Since, as you say (and I can see on prod[1]), "max-age" and/or "expires" headers are added to the static assets, which are served by the CDN (CloudFront), and costs is a consideration here (though Jason notes he  "has a todo to configure -dev and stage to use CloudFront so that we can finally test HTTP/2.0"), I and my automated test runs (and my approach) can definitely omit these particular metrics from my focus, until (and if) we're ready for them.

Cheers!

[1] https://www.webpagetest.org/result/170815_49_E0C/1/details/#step1_request15
Hi Stephen,

Thanks for the explanation. 

I take it the original request of this ticket is no longer needed for now. Thus I'm closing this one.

Meanwhile, I filed [1] to track the work of making -dev and -stage of the legacy site use CDN as well.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1390682
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.