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)
Cloud Services
Operations: AMO
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/
Updated•7 years ago
|
Assignee: nobody → wezhou
Reporter | ||
Comment 1•7 years ago
|
||
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)
Comment 2•7 years ago
|
||
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)
Reporter | ||
Comment 4•7 years ago
|
||
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)
Comment 5•7 years ago
|
||
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?
Reporter | ||
Comment 7•7 years ago
|
||
(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.
Reporter | ||
Updated•7 years ago
|
Reporter | ||
Comment 9•7 years ago
|
||
(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
Assignee | ||
Comment 10•7 years ago
|
||
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.
Description
•