757559 - Minified and CDN hosted versions of tabzilla.(css|js) and image assets

Status: RESOLVED FIXED

(Websites :: Tabzilla, defect)

Description

[Peter Bengtsson [:peterbe]]

Currently we include tabzilla by referencing:
1. //www.mozilla.org/tabzilla/media/css/tabzilla.css
2. //www.mozilla.org/tabzilla/media/js/tabzilla.js

Can we have minified versions of these hosted on a CDN. Ideally, also with all the appropriate aggressive cache settings so the name needs to have versioning and the word "min" too. E.g. //somecdn.com/tabzilla/1.1/tabzilla-min.js

Comment 1

[James Socol [:jsocol, :james]]

See also bug 739848.

Comment 2

[Jake Maul [:jakem]]

The CDN part is blocked by bug 742890. The minification is something that Fred or James would probably need to look into, along with the TTL settings in the bug James referenced. I'll move this bug to them to investigate that.

Comment 3

[Fred Wenzel [:wenzel]]

I see nothing wrong with putting tabzilla onto its own, somewhat separate spot on a CDN.

The versioning is an issue, because updating tabzilla should not result in updates having to be pushed across all users of the tab. That's why we include it across domains in the first place. That said, the core files could have a reasonable TTL, and all secondary assets (like images) could probably have really long Expires values and change names when these assets change.

Comment 4

[James Socol [:jsocol, :james]]

It may take some work on tabzilla.js itself, but Steve Souders has a solution to the versioning issue Fred mentions in comment 3:

http://www.stevesouders.com/blog/2012/05/22/self-updating-scripts/

Comment 5

[Peter Bengtsson [:peterbe]]

:jakem can you CC me on that bug? I'm curious about CDN stuff. 


Regarding versioning, I love Steve but I think this solution is quite convoluted. Also, it requires additional GET requests and a HTML response page that is smart enough to know if the js version has been outdated. All with an iframe. Considering that we're mobile focussed, I don't think this solution is very friendly to mobiles since it entails much more CPU work. Also, in his example the beacon is sent from the cached javascript. This will not work at all for CSS and images. 

I suggest we do like Google does when it CDN hosts jquery. I.e.:

$ curl -I http://www.mozilla.org/tabzilla/build/latest/tabzilla-min.css
Cache-Control: max-age=3600

$ curl -I http://www.mozilla.org/tabzilla/build/1.4/tabzilla-min.css
Cache-Control: max-age=315360000

Then, authors who are hunting PageSpeed and YSlow points can use the versioned URI and people who are less bothered just reference the "latest". 

I can write a script on top of tabzilla that builds all of this. I just need that to be hosted. :jakem if I write a script can you set up the necessary apache directives for the cache-controls?

Comment 6

[Peter Bengtsson [:peterbe]]

:jakem,
I wrote a patch that will build all the tabzilla stuff for optimal cached serving. It's a rough draft and might need some more work which I can complete if we at least get started with the Apache/Nginx/whatever stuff.

https://github.com/mozilla/tabzilla/pull/25

Comment 7

[Jake Maul [:jakem]]

@peterbe: I opened that bug up. There's not much on it just yet, as it's part of a larger project.

The cache-controls for this would be handled in www.mozilla.org's .htaccess file, here: http://svn.mozilla.org/projects/mozilla.com/tags/production. Webdev manages that. Something like this should do the trick:

<Location /tabzilla/build>
    ExpiresDefault "access plus 10 years"
</Location>
<Location /tabzilla/build/latest>
    ExpiresDefault "access plus 1 hour"
</Location>

I'm assuming it's okay if the other files in that same location have similar Expires/Cache-Control headers... that's very likely bad, I don't know.

A better solution might be to put a short/simple .htaccess file in each directory, that has just the proper ExpiresDefault or ExpiresByType statements for that directory. That way you could clone it over to each version and not need to have a default in the /build/ directory, in case there's things under /build/ that shouldn't have that long TTL.

Comment 8

[Peter Bengtsson [:peterbe]]

(In reply to Jake Maul [:jakem] from comment #7)
> @peterbe: I opened that bug up. There's not much on it just yet, as it's
> part of a larger project.
> 
> The cache-controls for this would be handled in www.mozilla.org's .htaccess
> file, here: http://svn.mozilla.org/projects/mozilla.com/tags/production.
> Webdev manages that. Something like this should do the trick:
> 
> <Location /tabzilla/build>
>     ExpiresDefault "access plus 10 years"
> </Location>
> <Location /tabzilla/build/latest>
>     ExpiresDefault "access plus 1 hour"
> </Location>
> 
> I'm assuming it's okay if the other files in that same location have similar
> Expires/Cache-Control headers... that's very likely bad, I don't know.
> 
Uh? Not sure I understand the question. 
Basically, we want `Cache-Control:max-age=3600` for every file in "build/latest/" recursively
And `Cache-Control: max-age=315360000` for every file in "build/versions/" recursively.

> A better solution might be to put a short/simple .htaccess file in each
> directory, that has just the proper ExpiresDefault or ExpiresByType
> statements for that directory. That way you could clone it over to each
> version and not need to have a default in the /build/ directory, in case
> there's things under /build/ that shouldn't have that long TTL.

My Apache-fu is getting old. Am I right in assuming that "Expire..." sets "Cache-Control" headers, not "Expires" headers. In fact, it would be nice if it sets both. 

Also, to complicate things, we might want to leave URLs like www.mozilla.org/tabzilla/media/css/tabzilla.css as is untouched. Perhaps the builds can be placed under something like www.mozilla.org/tabzilla/build/latest/... etc

Comment 9

[Jake Maul [:jakem]]

(In reply to Peter Bengtsson [:peterbe] from comment #8)
> (In reply to Jake Maul [:jakem] from comment #7)
> > @peterbe: I opened that bug up. There's not much on it just yet, as it's
> > part of a larger project.
> > 
> > The cache-controls for this would be handled in www.mozilla.org's .htaccess
> > file, here: http://svn.mozilla.org/projects/mozilla.com/tags/production.
> > Webdev manages that. Something like this should do the trick:
> > 
> > <Location /tabzilla/build>
> >     ExpiresDefault "access plus 10 years"
> > </Location>
> > <Location /tabzilla/build/latest>
> >     ExpiresDefault "access plus 1 hour"
> > </Location>
> > 
> > I'm assuming it's okay if the other files in that same location have similar
> > Expires/Cache-Control headers... that's very likely bad, I don't know.
> > 
> Uh? Not sure I understand the question. 
> Basically, we want `Cache-Control:max-age=3600` for every file in
> "build/latest/" recursively
> And `Cache-Control: max-age=315360000` for every file in "build/versions/"
> recursively.

If there is actually a /build/versions/ directory, that'll be easy... we can do exactly as you say. If there's not, and there's just /build/1.0/, /build/1.1/, etc, then it's more complicated because the catch-all would apply to everything in /build/. This might be okay, if *everything* in /build/ (apart from /latest/) can have a 1-year TTL. If there's anything in /build/ that *cannot* have a 1-year TTL, we'd need to specify it explicitly.

Basically what I'm getting at is, we need to be careful not to set the long TTL on the wrong thing. Some directory layouts make this simple, and others make it trickier. :)

> > A better solution might be to put a short/simple .htaccess file in each
> > directory, that has just the proper ExpiresDefault or ExpiresByType
> > statements for that directory. That way you could clone it over to each
> > version and not need to have a default in the /build/ directory, in case
> > there's things under /build/ that shouldn't have that long TTL.
> 
> My Apache-fu is getting old. Am I right in assuming that "Expire..." sets
> "Cache-Control" headers, not "Expires" headers. In fact, it would be nice if
> it sets both. 

It sets both.


> Also, to complicate things, we might want to leave URLs like
> www.mozilla.org/tabzilla/media/css/tabzilla.css as is untouched. Perhaps the
> builds can be placed under something like
> www.mozilla.org/tabzilla/build/latest/... etc

Do you mean that sites using the existing name/link should continue to work regardless of this change? We could probably redirect them to the proper thing in /latest/ to accomplish this. They'll get the new TTL settings and it will serve as a "hint" to site maintainers to update their code.

Comment 10

[Peter Bengtsson [:peterbe]]

(In reply to Jake Maul [:jakem] from comment #9)
> (In reply to Peter Bengtsson [:peterbe] from comment #8)
> > (In reply to Jake Maul [:jakem] from comment #7)
> > > @peterbe: I opened that bug up. There's not much on it just yet, as it's
> > > part of a larger project.
> > > 
> > > The cache-controls for this would be handled in www.mozilla.org's .htaccess
> > > file, here: http://svn.mozilla.org/projects/mozilla.com/tags/production.
> > > Webdev manages that. Something like this should do the trick:
> > > 
> > > <Location /tabzilla/build>
> > >     ExpiresDefault "access plus 10 years"
> > > </Location>
> > > <Location /tabzilla/build/latest>
> > >     ExpiresDefault "access plus 1 hour"
> > > </Location>
> > > 
> > > I'm assuming it's okay if the other files in that same location have similar
> > > Expires/Cache-Control headers... that's very likely bad, I don't know.
> > > 
> > Uh? Not sure I understand the question. 
> > Basically, we want `Cache-Control:max-age=3600` for every file in
> > "build/latest/" recursively
> > And `Cache-Control: max-age=315360000` for every file in "build/versions/"
> > recursively.
> 
> If there is actually a /build/versions/ directory, that'll be easy... we can
> do exactly as you say. If there's not, and there's just /build/1.0/,
> /build/1.1/, etc, then it's more complicated because the catch-all would
> apply to everything in /build/. This might be okay, if *everything* in
> /build/ (apart from /latest/) can have a 1-year TTL. If there's anything in
> /build/ that *cannot* have a 1-year TTL, we'd need to specify it explicitly.
> 
> Basically what I'm getting at is, we need to be careful not to set the long
> TTL on the wrong thing. Some directory layouts make this simple, and others
> make it trickier. :)
> 

I think we're on the same page...:

/build/latest/ --> TTL 1 hour
/build/versions/ --> TTL 30 years

Everything under /build/versions/ will NEVER change (new files will be added of course). But things under /build/latest/ should be careful. 
 
> 
> > Also, to complicate things, we might want to leave URLs like
> > www.mozilla.org/tabzilla/media/css/tabzilla.css as is untouched. Perhaps the
> > builds can be placed under something like
> > www.mozilla.org/tabzilla/build/latest/... etc
> 
> Do you mean that sites using the existing name/link should continue to work
> regardless of this change? We could probably redirect them to the proper
> thing in /latest/ to accomplish this. They'll get the new TTL settings and
> it will serve as a "hint" to site maintainers to update their code.

Fine with me. As long as those two use /tabzilla/media/... are informed they should switch to another URI now.

Comment 11

[Matt Basta [:basta]]

This should also encompass the image assets.

Comment 12

[Christopher Van Wiemeersch [:cvan]]

Would it help to maybe serve it from gh-pages?

Comment 13

[Anthony Ricaud (:rik)]

We're thinking of hosting tabzilla as a regular django app inside bedrock. This would help us with localisation and minification.

No dev resources on this though. If anyone wants to tackle this.

Comment 14

[Peter Bengtsson [:peterbe]]

(In reply to Matt Basta [:basta] from comment #11)
> This should also encompass the image assets.

I agree but considering how hard it has been to even get this off the ground I suggest we tackle that as a "phase 2".

Comment 15

[Peter Bengtsson [:peterbe]]

(In reply to Anthony Ricaud (:rik) from comment #13)
> We're thinking of hosting tabzilla as a regular django app inside bedrock.
> This would help us with localisation and minification.
> 
I disagree. That doesn't give us the flexibility we need. 
My proposed solution gives us two options:
a) a URL you can use which is always kept up to date
b) a URL with aggressive cache headers

In both cases, the minification is already there.

This is, by the way, the way Google hosts jQuery. 

> No dev resources on this though. If anyone wants to tackle this.

Review my pull request and we should be all set. 
It seems that CDN is going to have to wait

Comment 16

[Anthony Ricaud (:rik)]

As said in comment 3, I don't see why we need to version Tabzilla. It goes against the goal of having only one place to edit to update all websites using it.

Comment 17

[Peter Bengtsson [:peterbe]]

(In reply to Anthony Ricaud (:rik) from comment #16)
> As said in comment 3, I don't see why we need to version Tabzilla. It goes
> against the goal of having only one place to edit to update all websites
> using it.

The reason is, by using a versioned URL you can get more aggressive cache headers. If you don't care so much about optimization and caching, you can be lazy and use a generic URL. Or, if you want the fastest performance possible, use an exact version. 

For example, if you know your exact version you get a more cached serving:

 peterbe@host-5-202:~$ curl -I https://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js 2>/dev/null | grep Cache-Control
 Cache-Control: public, max-age=31536000
 peterbe@host-5-202:~$ curl -I https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js 2>/dev/null | grep Cache-Control
 Cache-Control: public, must-revalidate, proxy-revalidate, max-age=3600

Comment 18

[Peter Bengtsson [:peterbe]]

For the record, Anthony and I have discussed this in more detail and we have concluded the following:


1. We can't have a versioned URL. It's always only the "latest" or "build"

2. The maximum amount of caching we can do on the tabzilla.min.js and the tabzilla.min.css files is 1 hour. This is because tabzilla.js file contains content we want to roll out without having to notify site owners to upgrade their tabzilla version they use.

3. It's too risky to have a lax cache-control on the .js and an aggressive on the .css file. 

4. What we can do is build the tabzilla.min.css file such that it references *images* with build URLs (e.g. /tabzilla/images/mozilla.c2d5afe1d2a02.png) which can be served with an aggressive caching.

5. CDN is going to be more important and have bigger "bang for the buck" than minification and cache headers.

6. Other features such as L10n is more important than performance optimization :(

Comment 19

[Mike Alexis [:malexis]]

Web prod wants to pick this back up and get the CDN + l10n solution implemented soon.

Going to set up some time to discuss requirements.

Comment 20

[Paul [:pmac] McLanahan]

We do have a CDN on mozilla.org now. The JS and CSS for tabzilla are now served with 12h cache-control headers as that was determined to be an acceptable amount of lead time for updates to the promotions.

Replies to certain bullets from comment #18:

2. We have the cache-control headers for the tabzilla CSS and JS set for 12h at the moment. This was determined to be an acceptable amount of time to roll out new promotions in tabzilla and help keep tabzilla's impact on our sites as minimal as possible.

3. True. Promotions seemingly always involve changes to the JS and CSS, so their cache times have to match.

4. jingo-minify has this ability. We're in the process of upgrading to latest playdoh and jingo-minify now, so we should be able to automatically add build IDs to image urls in the minified tabzilla css.

A couple of things remain to be done:

1. Determine the final URLs for the JS and CSS.

This is complicated on the JS side by l10n. It'll be easy to have the CDN cache the various localized versions with the locale prefix, but autodetection and redirecting of the JS to the most appropriate localized version will be tricky when proxied. Hopefully the proxy will respect a Vary header on accept-language, which will make this easy.

Are urls at the mozorg CDN going to be acceptable? e.g. //mozorg.cdn.mozilla.net/media/tabzilla/*. Or would we prefer to have a separate tabzilla.cdn.mozilla.net? It'd be easier to go with the mozorg CDN since it exists, is already in use, and would mean not having to special-case tabzilla on mozilla.org, though I'm unsure if we can customize it enough to proxy a different location for the JS l10n view (jakem?).

2. Announce it to the world.

We'll do it in such a way that the old documented URLs redirect to these new spots, but as we've seen redirecting the JS and CSS can cause issues. The most major of these issues is the double downloading of some CSS referenced assets, most notably fonts. These assets are referenced with domain-relative URLs in the CSS (e.g. /media/fonts/walter.woff) and this is mostly fine, but IE follows those references relative to the URL in the link tag, not the url of the CSS file, so they're loaded from mozilla.org, and not the CDN, and they're often loaded twice b/c the sites often reference them in their own CSS from the CDN.

So, we'll need to do a good job informing all affected sites so they they can use the new CDN urls in their templates and get the fastest experience possible. Suggestions on where to send this announcement are welcome. We'll certainly send to the webdev public list, but apart from that I'm not sure.

Comment 21

[Mike Alexis [:malexis]]

collective brain dump from meeting: https://etherpad.mozilla.org/tabzilla-css-urls-2013-04-08

tl;dr

We'll use existing URLs; no Bedrock changes needed; and Jakem will make it happen.

Comment 22

[Mike Alexis [:malexis]]

URL no longer redirects to the original domain. 

documentation and how to announce these changes to various website owners can be a separate bug.

Comment 23

[Kohei Yoshino]

Sorry for the bugspam -- the Target Milestore was set unexpectedly.