Question for the web-devs in the audience

[andrewducker]

So, in order to capture the user's Timezone* I'm giving the user a dropdown with all of the allowed timezones. The new one has a popup for each possible output** - so that data is duplicated. And having checked, that's 18kB of options, repeated twice. 36000 characters of data being generated twice and then sent over the wire, every time a page is served.

This seems silly, as I don't actually expect people to pop up that combo box very often. Most of the time it's hidden invisibly in the background***

So, should I do something clever using JavaScript to fetch the list of allowed timezones when needed and then create the options on an ad-hoc basis? That risks slowing everything down for a second while it fetches the list over AJAX and then creates 600-odd entries, but shaves some time off the load. Or avoid doing this on the client in order to keep processing on the server where the majority of the page is generated, on the grounds that 36k is trivial by modern standards, and it's ok to waste that? Or add it into a separate JS file so that at least it's only loaded the once and then cached from then on****? Or something else?

Thoughts?

*For LJ/DW, which insists on having a time passed with each post, and mustn't have a time passed in before the current one - but takes that _in_ the user's local timezone, so I have to do the conversion before making the call. API here.
**i.e. LJ, DW, Wordpress, and any others I add later. Probably Tumblr, at the least.
***Iin the new version - clearly in the current one it's visible all the time.
****Which I only thought of at the end of writing this, and now seems most sensible. After all, they're loading jQuery whenever they hit my page, and that's 92k, and also cached.

Comments

[marahmarie]

I'd go with 'add it into a separate JS file so that at least it's only loaded the once and then cached from then on***'. At least serve it via JS in some form. 36k doesn't sound like a lot but it is, especially on slower connections.

(Coincidentaly, I'm having a similar debate with myself, but over my userscript. Long story short, Google's running three versions of HTML and/or JS that I know of to serve the exact same design on regular search results. They normally run only one version of HTML/JS *unless* they're testing obvious-to-the-eye design changes, but not so this time.

Right now I have three userscripts that deal with the changes in each version of HTML/JS they're running - because, for the most part, they're changing positioning on existing elements of the HTML, not adding new classes or IDs for me to target.

Instead of doing that, I'd like to target exactly what in the HTML and JS they've changed, version by version, then add conditional JS to my original userscript that runs only *if* one of the two new versions of code are presented. Because G pretty much serves each version at random - you can often hit all three in one browsing session, but you'd never know it without something like my userscript in action, since they're not making changes that are otherwise actually visible - the JS would solve the problem of not one of my current userscripts addressing all three versions. But...I don't know how to write that sort of JS, so I'd have to brush up on it, I guess.)