Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

His rant doesn't seem too informed: "aggressive anti-performance and apparent contempt for the web by Twitter’s designers"

According to his charts most of Twitter's page is JS/CSS and presumably set to heavily cache. Very little is data. Once you've done the first page load Twitter's pages will load quite fast and efficiently. While quite a lot of JS, this is good design, not bad.



What's interesting about Twitter's model is that no data actually comes down to the user when they first request a tweet. Twitter builds the page, loads the layout, and initializes the client-side script, which makes a JSON request to pull an individual tweet after everything has loaded.

This means that to get the requested information on first load, the user has to wait for a 2MB download, followed by another roundtrip Ajax request to twitters tweet retrieval API. This results in the perception of a slow page load, even though the tweet itself comes down the pipe in only 100ms.

In my view, Twitter is an excellent case study in some of the pitfalls of thick-client application design. Mainly that ignoring the first-time-use case will result in widespread perception among users that your app is slow, even when every page view after the first is lightning fast.


That is not entirely true. If you are authenticated your home_timeline is embedded in the page for instant rendering. Once Twitter moves away from #!'s individual tweets will be embedded as well.


Twitter is heavily optimized for multi-requests. The first is big (analogous to downloading an application) while every other request is miniscule in comparison. Hell, fetching tons of data from someone is tiny because its data only, not JS/CSS/etc


"Twitter is heavily optimized for multi-requests " - Which turns out to not be a very good idea, because it means that clicking on links from other sites to Twitter results in a huge performance hit - even if my browser has cached the assets, it still takes several seconds to execute all of that JavaScript, paint the CSS etc.


It takes several seconds? How fast is your computer? I primarily use Twitter's web interface and it never felt slow compared to anything else, but then I run Chrome on a 2010 MBP, so I can imagine it would be slower on older hardware and browsers.


Yahoo did a study a while back and found that ~50% of their visitors had a cold cache http://yuiblog.com/blog/2007/01/04/performance-research-part...


Plus if you access Twitter over SSL, there might not be caching resulting in heavy loads repeatedly.


I'd imagine Twitter's serving `Cache-Control: public` where appropriate.


You would think but sadly, no.

They serve the actual tweet as "Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0"

https://pastee.org/bzeb5

EDIT: Just to check, I also looked at one of their css resources. https://si0.twimg.com/a/1330626450/t1/css/t1_core_logged_out...

Cache-Control: private, max-age=31449600

So I'm not confident Twitter actually understands how to set things.

PS: Hey Twitter, I can help =)


Maybe it's just that they don't want that one page cached as they may update their scripts, images and stylesheets. And for that css-file, I think that whenever they change the css, they'll just give the resource a new address so cache is only invalidated when there are actual changes.


That does not make sense. If they update that page, then it'll get refreshed when it expires.

For the CSS file, some browsers are buggy so it really should be set to "Cache-Control: public".

See http://www.acunote.com/blog/2008/07/why-you-should-use-cache...


In early 2007. Isn't this likely to have changed in five years?


http://samsaffron.com/archive/2012/02/17/stop-paying-your-jq...

Apparently Stack Overflow sees similar numbers.


I wouldn't call 20% "similar" to 50%, but it is still a significant number.


The author has responded[1] to some comments made when this was posted to MetaFilter[2]. He knows about caching, and he has some reasons why caching doesn't help as much as you'd think.

[1] http://www.metafilter.com/113541/The-Magic-Dollar-Sign#42233...

[2] http://www.metafilter.com/113541/The-Magic-Dollar-Sign

Google and Yahoo have been preaching for years that even fractions of a second of page load time have a big impact on how likely users are to give up and go somewhere else. Caching doesn't help anyone if the user doesn't come back. It would really be better (for Twitter) to make that first, uncached page load the fastest one of all.


> Google and Yahoo have been preaching for years that even fractions of a second of page load time have a big impact on how likely users are to give up and go somewhere else

Well of course they worry about it. I can ditch Google and go to Yahoo, DDG, Bing, hell Lycos might still be around, if the Google homepage takes too long to load. Obviously same for Yahoo. Neither of them produce or host the content (search, news) that you're going there for.

That's not quite the same situation as Twitter, GMail, Facebook and whatnot. Where else are you going to go? Your mail is in GMail, or your friends tweet is on Twiter, their wall is on Facebook and they are only there. The "instant load or I'm out of here" doesn't apply so much to them. It really only affects new users who have no other attachment to the service.

I doubt it's much of a problem for Twitter.


Well of course they worry about it. I can ditch Google and go to Yahoo, DDG, Bing, hell Lycos might still be around, if the Google homepage takes too long to load.

It's been a while since I saw the story about this, but I came away with the impression that users weren't leaving for another search engine; rather, they were deciding that searching (for whatever often-trivial thing) was not an engaging use of their time.

I'd think that would be of especial concern to something like Twitter.


You could not use Twitter. I don't think it's as much of a piece of social infrastructure as Gmail or Facebook (at least not yet).

You could also access it via a third-party app, this reducing their monetization options and network visibility.


I agree.

Especially consider for something like Gmail the incumbent for comparison is MS Outlook. (grab your coffee cup and head for the kitchen...)

2MB ain't what it use to be either.. Folks if you want lightweight sites go mobile: https://mobile.twitter.com/


But it is still bad that you need to suffer through the initial load (at least once).

EDIT: There are still many devices and locations that do not have high speed access. Just because a page loads quickly (relatively) due to the fact that you are sitting on top of a OC192 link does not mean that the load time is dog slow for say someone in Rwanda.

In fact, web devs should review their sites through a network simulator as part of the QA process.


I visit a couple twitter feeds daily (because I don't particularly want an account and their RSS is broken), so presumably I normally have a warm cache.

It typically takes anywhere from 4-8 seconds before the first tweet appears, and another 2-4 seconds before the page is fully loaded. Twitter is quite definitely the slowest website I visit on a regular basis.


A more accurate title might be "The Twitter web client is 2.0 MB."


The problem is that Twitter broke links to tweet pages by using the #! URL structure. Now you can't load a tweet page without loading the entire app. That's bad.


They'll move to pushState and all will be well. Hash-bang URLs were just a necessary stopgap solutions until more browsers supported pushState.


I would like to think so, but they haven't yet. They don't even load any page content, so that you don't get URLs like http://twitter.com/stuff/1234/things#!/different/stuff


No version of IE - not even IE9 - supports pushState. Nor does the Android browser, for that matter.

http://caniuse.com/history


Too bad for IE users. They've said they're redoing it to given users of modern browsers the best experience, and if you use a crap browser you just get full page loads. /#!'s are getting kicked to the curb


It's easy enough to use pushState where available and fall back on #!


Or just failover to full page refreshes, like we do at gdgt.


Not strictly true. IE10 supports it.


If you would like to think so, let me give you a reason to do so: http://www.2ality.com/2012/02/twitter-pushstate.html


Which is perfectly okay for the regular twitter web client, but we're talking about a single tweet status here, i.e. a page where you arrive by clicking on a link like "Bob Bobson recently stated that frobnication is all gonked up". Then you want to read the full 140 characters of what Bob Bobson said, and whoops, two megabytes.

(Never mind that at least for me, tweets are increasingly often turning up as search engine hits)


I run chrome in incognito mode pretty much 100% of the time, and this totally explains why loading tweets is so freaking slow lately.


Chrome caches in Incognito mode. It just doesn't let the cache leak out of the session. So this might explain the first tweet you load being slow, but if you load a second it should be just as fast as in normal mode.


Yeah, that is exactly the pattern. I don't use twitter, and neither do most of my friends, but occasionally I'll get linked to it.

I just chalked up the painfully slow load times to "well, it's twitter..."

(And sorry, twitter, it sounds like this has changed, but my experience with twitter involved a TON of fail whales, which is partially why I never got hooked on it, I'm sure)


This HN page is about 1.2KB. Now tell me again why you need 2MB for a single Tweet page. Also take a look at the mobile Twitter site: http://mobile.twitter.com/bos31337/status/172156922491969536

Today PG posted some HN stats: http://news.ycombinator.com/item?id=3669947 It seems that HN is still running on one server!

Don't fool yourself. Twitter is bad design, not good.


Did you know, gmail's entire web app is 1.66 megs once fully loaded? Users visit it many times every day and they've still optimized the hell out of it. Same goes for many other well built web apps. Twitter has been getting away with sloppy engineering since their inception and yet they continue to give others engineering advice.


It's also worth noting that you load gmail's web client to interact with an entire inbox full of mail, sending, receiving etc.

The point of the OP is that a user is loading 2 megs to view a single tweet. A medium that is literally defined by its brevity, should not need to send 2 megs to your browser so that you can read 140 characters.


yes but in twitters defense gmail now is 1.6 megs it was over 2.5 megs some time ago..about the time wave was launched..they heavily refactored gwt due to the problems with wave..


Caching is fine when I'm actively using Twitter, but if I do something else these 2MB will be competing against other junk|useful stuff.

I've used Twitter not very long ago (since then I've visited a forum, a piece of docs, left my browser idle half an hour, and visited HN), now I've just looked in about:cache and twitter/twimg only have a handful of profile pictures.


Maybe his "contempt for the web" comment is referring to the traditional hyperlink-based Web 1.0 model. Every time I try to view a tweet, I get redirected to https://twitter.com/?_twitter_noscript=1


Hm, true. But often tweets are insular. When a funny quip is linked you just want to read that.


"His rant doesn't seem too informed"

Worse than that, he seemed to lack some basic understanding of the modern web. The Twitter webpage is not simply a "page" in the traditional sense - it is one instance of the Twitter client app, that happens to be written in Javascript and runs in a Browser.

2MB for a rich client app? Doesn't sound like overkill to me.


How would you like it if a new copy of iTunes was spawned every time you click a MP3 in finder? That's about the analogy for the current twitter situation.

I wonder why twitter doesn't simply serve up a static "fake" page for direct links. That could easily weigh in under 100kb and display instantly. Then make all links on that page boot up the "real" twitter.

That way the long wait is at least mitigated until the user actually starts to interact with the page (which in 99% of cases he'll never do because he only wanted to read that one tweet).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: