Cleanup assets serving #1969
Cleanup assets serving #1969
Conversation
I have found some more files (more than I thought there were) that reference |
cc @galuszkak @Changaco @sim6 - just trying to remember who could be interested in this PR. Anyone feel free to ping anyone else. |
I was aiming to get a better score at |
Looking onto this. |
Ok I have only one proposal. Wouldn't be better to write template tag/extension to jinja to create assets url (which will do "{base_url}{asset_url}".format(base_url=website.asset_url, asset_url=url) )? it will look something like that:
Than this:
this will remove also typo problems if we do something accidentally in variable. What do you think @zwn ? |
I probably wouldn't mind having something like that. However the added value for me does not outweigh the time I'd spent learning how to do it. Typo problems will be caught by tests anyway and I use auto completion of my editor. So as I said before, maybe nice to have but for me definitely not worth the effort (since I have almost no idea how jinja does its magic). |
https://developers.google.com/speed/docs/best-practices/rtt some more motivation. |
This has been sitting for 8 days. I'm going to review this and try and get it merged today. |
!m @seanlinsley |
|
||
response.headers['Expires'] = 'Sun, 17 Jan 2038 19:14:07 GMT' | ||
last_modified = get_last_modified(request.fs) | ||
response.headers['Last-Modified'] = format_date_time(last_modified) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach worries me because it sets the Expires
header to the far future for all assets, not just the ones in the %version
directory. That means that if any of those files change content but not name, we're very likely to break the website for some users.
Is there a reason we're not versioning all of our assets? If it means that when we deploy everyone has a 100% cache miss on their first page load, that doesn't sound so bad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to address this in the description of this PR (second and mainly third paragraph). Can you reread it and come back to me if still does not make sense? Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our versioned assets (served from assets/%version/*) are invalidated with each deploy automatically. The other assets need to have their own version embedded in url (which is the case with jquery already).
That works for jQuery, but there are many other files there that don't have a version number in the file name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is stopping us from adding one when we update them? Or do you feel that putting all of them under the %version header is better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're suggesting that, for example, if Open Street Map makes a new logo, we'd add it as www/assets/openstreetmap-2.png
? A year from now, I doubt we're going to remember to do that.
I think I'd prefer for everything to be under %version
. It means a 100% cache miss on the first page after a new deploy, but every page after that has a 100% cache hit (for assets at least).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CC @clone1018
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zwn I'd say go for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I will. Is there anything else standing in the way of merging this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we should be good to go.
Looking at the timestamps, it's now been 6 days since we last talked. Is this still on your radar? If not, I'd be happy to do the last bit of work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still on the radar (I would eventually get to it). But feel free to jump in, I'll try to help with the big 'elsewhere' and 'coinbase' PRs.
@zwn Update on this? You are busy, or burned out on Gittip, or something. Haven't seen you for a week or two. :-) Everything okay? |
We did a little bit of assets rearranging in #2142 ff. |
I'll be taking over this PR in @zwn's absence. |
@clone1018 Go ahead. Yeah, I've been busy with other stuff. Hope to be back soon. |
@@ -24,7 +24,7 @@ | |||
/* @group Single Chosen */ | |||
.chzn-container-single .chzn-single { | |||
background-color: #ffffff; | |||
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#eeeeee', GradientType=0 ); | |||
filter: unquote("progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#eeeeee', GradientType=0 )"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the purpose of the unquote
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably to support importation into the SCSS file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, unquote
is commonly used to bypass the SCSS parser for IE-specific hacks.
@clone1018 as frustrating as the recent downtime was for me, I can't let this PR sit stale any longer. I'm going to try and get this finished up today. |
@@ -99,6 +98,9 @@ def __init__(self, db, api_key, api_secret, callback_url, api_url=None, auth_url | |||
elif api_format: | |||
raise ValueError('unknown API format: '+str(api_format)) | |||
|
|||
# TODO: make this use website.asset_url! | |||
self.icon = '/assets/icons/%s.16.png' % self.name | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@whit537 thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that while rebasing this commit, I (@seanlinsley) added a good deal of extra changes since we were still using the static "/assets/foo" URL in a lot of other places.
This doesn't version the old widgets because people may still be using them. (ref: #1767) Except... the first widget refers to an old version of jQuery that we haven't provided in a long time :-/ This commit also fixes reset.css and chosen.css to correctly load.
and start using that name for `asset_version_url`
So, the tests are failing because they don't have access to |
@seanlinsley The hacky way to fix that is to change |
What sort of refactoring would make it so that's not required? |
@seanlinsley This is an old PR. I don't think we should block on any refactoring here. |
You didn't answer my question :-P. I'm genuinely curious what you had in mind. |
that way it has access to the website object by default
Very happy this is out, thank you! 💃 |
First commit in this PR fixes https://app.getsentry.com/gittip/gittip/group/13299458/ where we have so far 7.4k of exceptions. The trouble there has been that we were trying to set last modified time even on responses other than 200 (404 for example).
Second commit unifies our http caching strategy (#1555). Before we had two kinds of assets - long term and short term (versioned). For the long term, where we would want the maximum caching, we were not setting expire time. That means that the browser cannot know if the cached version is current or not without a hit to the server. We try to respond with 304 (not modified) but it is still a hit. Moreover we respond 304 not often enough because the decision to do so is based on mtime of the file. With each deploy possibly a new git checkout is made which results in mtime of 'now'. To conclude, the files we would want to be cached the most, were not.
Now all assets have far future expire time that allows the most caching. Our versioned assets (served from assets/%version/*) are invalidated with each deploy automatically. The other assets need to have their own version embedded in url (which is the case with jquery already).
Third commit makes a run to move all assets to CDN. What is not done yet a references from css files where I was not sure how to do the url expansion for
website.asset_url
.Fourth folds separate css files into our main gittip.scss file to reduce the number of http requests to make the site speedier.
I'd appreciate a full review and thorough TTW test before merge & release. Thanks.
cc: @seanlinsley @clone1018 @duckinator