A single tweet page is 2.0 MB | Hacker News Reader

A single tweet page is 2.0 MB

mike.teczno.com

293 pointsskimbrel110 comments

Several people in this thread state "It's cached, so why does it matter?"

So, even ignoring the issue with cold caches, how about the two megabytes of code that the browser may need to go through to render the page?

What on earth is twitter doing on a given page that needs two megabytes of code?*

* As of March 2012, for I'm sure this will look silly when there are 2 gigabyte pages, 20 years from now.

I looks like most of the inline JavaScript is there to handle DOM abstraction and events. Every click essentially needs to be able to build a part of the page client-side.

I don't think we'll have 2 gigabyte codebases..

Higher resolution displays, bump/texture maps for live 3D rendering, 8K video, etc could all contribute to huge page sizes.

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.

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

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

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

http://caniuse.com/history

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.

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

Not strictly true. IE10 supports it.

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.

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.

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)

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

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)

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.

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/

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.

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.

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.

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

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.

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..

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.

"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).

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.

I live in Rwanda and like a sizeable portion of Twitter's userbase, have very slow internet. When Twitter switched to their new design it got a lot harder to open their site... I kept using the old version until they removed it. I don't understand why - it's not pulling down a lot of data, it's not even making that many requests (~50), but this site and other AJAX rich sites just don't seem to work as well as the old less-AJAXy versions on a really slow internet connection with a bit of packet loss

And it is funny - AJAX-related technologies were promoted exactly to make sites more lightweight and more responsive..

You could argue that Twitter is more responsive than it would be using server-generated HTML pages. But the initial app download is much bigger than it would be with that method.

What Twitter seem blissfully unaware of is that they've traded download speed for rendering speed on lower end devices.

if you want a more lightweight version of twitter on any browser, try: http://mobile.twitter.com

I used to use that all the time. It's essentially old twitter with a layout that is a little less wide.

You can also play user-agent games to get the Android version in your browser. I prefer the regular mobile edition, but it's interesting to poke around; I've found three separate versions of the site just by faking out my user agent.

All of the comments here could be shortened to "It's cached so it doesn't matter" as if the main problem was "2 MB is too large hence loading is too slow".

But the problem here (according to the author and I tend to agree with him) is that one needs to load too much junk for too little actual content; whether the junk in question is cached or not.

Now, ideally, a tweet's 140 characters shouldn't weight 2 MB but Twitter users need tools to act upon those tweets: re-tweet, follow a link, etc. and those tools come with a cost.

A relatively high cost but one we can afford, with the help of caching.

A retweet is just a post request. A follow this person is a post request. Those can both be done with a simple HTML form.

If you give the browser a form, it's going to want a callback(JS); to make sure everything went through. When you give it the callback, it'll probably ask you for a image; pretty UIs are important. When you give a browser an image, it'll need to be styled(CSS). . . and so begins the theory of "If you give a browser a cookie".

Granted 2MB is pretty big, but the only people I see complaining are techies; valid complaints but do not effect Twitter's bottom line.

File this under "annoying to developers and no-one else".

Twitter obviously caches 99% of this stuff. I absolutely agree that 2.2MB on one page seems absolutely insane, but that doesn't match up with the experience every time you load the page. And I imagine it's pre-caching code that runs on other pages as well, so you most likely only ever take that download hit once.

Yes, they should bring that amount down. No, it probably isn't going to be a priority.

Shouldn't it be a higher priority? More and more web users are accessing sites from low powered devices with slow connections that might even have data caps (think tablets or netbooks on 3G networks).

Twitter pages don't even seem particularly complex functionally or graphically, so why should the payload be so large?

More and more users are on mobile devices, sure. But those load up the mobile version of the Twitter site, which is very lean.

Not when they are clicking on a link in email or other page.

EDIT: misread your comment. Thought you were talking about mobile apps.

Also, I would not call their mobile site 'very lean'. Just got a single twit page on iPhone: 817Kb.

Really? Because when I go to a Twitter link on my phone it redirects me to the mobile site, irrespective of the original domain.

I was wrong, see update.

The mobile version that loads on my iPad is different from the one that loads on my iPhone, and it looks like it uses more javascript. Does anyone know the size of the iPad page?

File this under "annoying to developers and no-one else".

I never follow Twitter links because of exactly this (well and the fact that they trap you with forwards). It is a terribly negative experience. Even if I had all of those files cached the parsing and execution of all of that JavaScript is far from instantaneous.

Same deal with TechCrunch -- stopped visiting because it is such a script-laden monstrosity that it seriously diminishes the experience.

Say- are you a developer?

True enough, I am. However sorry I thought you meant that it only annoyed people in a development sense, ala some sort of perfectionism about Firebug call chains or the like.

I have no interest in the specific code behind Twitter, whether in the presentation or behind it, but rather simply note that the general twitter experience is a poor one.

"You can't argue with me, because you're on HN"?

I'm not. And I don't like following those links through. I wasn't aware it was because of caching - I just saw slow.

I'm not a developer, and this is a major reason I never click on links to tweets any more. Particularly when using a smartphone, I find the long load times of many web pages so annoying that I simply avoid visiting such sites altogether.

It takes 3-5 seconds for my rather powerful laptop to 'build' a twitter page after it has loaded (since it is doing AJAX etc), and this is warm. This is also on a rather fast internet connection, in the latest firefox and chrome. Compare this to Facebook - which has enough javascript to make it slow on my netbook - it loads almost instantaneously under the same circumstances, even when performing AJAX requests.

One tweet is 2 MB? More like 670 KB for first load and 18 KB cached. http://imgur.com/QFIjU

Nothing happened. Page size stayed roughly the same.

Does anyone know how to get those graphs to show up in the current version of WebKit? They seem to have disappeared or are hidden.

This is a good question. The resource panel from the old Safari 4 webinspector looked that way:

http://www.webkit.org/blog/197/web-inspector-redesign/

Yup, Safari 5 I dont see this.

The closest thing is now the bottom row under Network, which shows total requests and network transfer for the current page load.

The first tweet is 2 MB. How much is the second?

Try http://m.twitter.com , it's the dressed-down mobile version of Twitter.

It doesn't have all the features, but easily makes up for that by the fact that you can actually click around as much as you like without your browser getting all slumpy from loading huge pages or doing javascript.

You'd expect caching to help, but there's a lot of truth in the jQuery tax article[1]: even if you got the code cached, executing it all takes a significant amount of time, and the sluggishness is made worse by the fact that during this time your CPU is busy, unlike with data transfers which at most cost some memory.

I don't use the m.twitter.com site all the time, but I switch often enough whenever I get too annoyed by default Twitter's slowness.

The only real downside (for me) is that you can't click through to a full resolution version of a profile picture. Otherwise all the basic features are in there.

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

Well, I measured that with chrome and it wasn't 2MB rather ~450 KB.

Talking about 140 chars is irrelevant, a tweet, is a 140 (unicode) chars handler for a (mini social) graph, and this is how we should look at it.

In that particular page he's talking about[1] there are 10 profiles info (status owner + 9 retweeters) embedded within the page so when you click on a profile thumbnail you get the profile modal with some basic info and "Follow" button etc.

381Kb out of those 450 belongs to his own background image [2].

In other words, twitter does a very good job at making their service fast and speedy.

1. https://twitter.com/#!/bos31337/status/172156922491969536

2. https://twimg0-a.akamaihd.net/profile_background_images/9706...

How does this work, is he reporting compressed or uncompressed sizes of data? text/css/js compresses really well for transmission, images do not.

User-defined image backgrounds can also be up to 800k-ish for twitter too right?

Funny: Every user comment on reddit has about 3.4 KB of HTML overhead (<div>, in-line javascript, etc), including multiple  comments.

It really adds up for a large thread.

No wonder it takes long for Twitter pages to load. Such things show up only when you're on slower speeds.

Exactly - just set your phone to EDGE and pull up a tweet page in your mobile browser and you'll see how long it takes. And not only for the 1st page load but for all others too. I can pull up a Facebook page (while being logged in) and have that served to me in a fraction of the time it takes for Twitter. Compare that to the feature-set and your opinion will change quickly. Just try it, no stats & graphs needed, you'll see...

Honestly, Facebook's load time is quite phenomenal. It is one of the most feature-laden and complex consumer web applications out there and they still manage to set the bar with regards to speed and multi-platform usability.

Sadly Facebook's tools for other sites are some of the slowest things on the web. That they're attached to every post and so can be called 10+ times per page really doesn't help.

Scrolling on TechCrunch with your mouse over the post area is a hilariously pitiful experience.

Actually, since I blocked all Facebook widgets (tracking or otherwise), it has the nice side effect of not loading the comments when I accidentally land on a TechCrunch article.

Makes the site load faster =)

I've often thought this too. I wonder if it's because of HipHop

https://developers.facebook.com/blog/post/358/

HipHop affects server-side performance, but the fast loading is down to some very clever usage of JavaScript.

I can't find a write-up about it now, but last time I dug in to it they were pulling a really clever trick where their pages were served with a very light chunk of HTML (just enough to layout the page) followed by a sequence of script blocks that populated different areas. The magic is that the script blocks came back in the order in which the relevant back-end services replied - so if the timeline service replied instantly, the timeline would be rendered first - then as other services (notifications, app list, etc) finished new script blocks would be written out in to the HTTP stream already open to the browser and that content would appear.

This works amazingly well across all browsers, because the original browsers from the 1990s were designed with modems in mind and had to progressively render the page as it loaded. It turns out you can use that ability to serve a stream of script blocks to a page and dramatically reduce time-to-content-visibility.

Can anyone tell which page he loaded specifically? I just loaded the latest status update on my timeline in incognito mode and all it downloaded was ~578kb+ of data.

This might be one of the best reasons to have native (mobile) clients. As a web-developer I like the model of writing one web-application to fit all clients, and being able to link to pages etc. But on a slow connection it certainly makes sense not to have to download the GUI before viewing the content. As the author points out, the content from the API is just some hundred bytes.

Ah, but how big is the (downloaded) size of the next page on each of those sites?

Maybe so, but how much of that 1.65MB of Javascript is cached by the browser?

If the initial load-up time is slow, then you're probably less likely to click that Twitter link knowing that the initial page-load is always slow.

The warm-cache situation only matters to people that are on Twitter all the time, so this possibly has the effect of keeping existing users happy while raising a barrier to new users (or pushing infrequent users to completely abandon the system).

Secondly, you're only looking at download size (the importance of is really to imply a certain amount of time it takes to download those resources). Since Twitter's JS platform is about doing all of the HTML rendering on the client-side that has to be taken into account (this wasn't a concern in the past when it was mostly done on the server-side). If the page takes 3s ~ 5s to load even with a warm cache and a tiny (size) ajax-request, then it sort of defeats the purpose (unless your purpose is to relieve server-load instead of in-browser load times).

In Q1 2007, my husband and I were invited to Twitter HQ for a meeting -- I was pitching a visualization project, my husband (renowned JS developer Thomas Fuchs) was proposing that we fix their horrible front-end performance issues (both page load & laggy JS code). We met with ev, some of the team, and the new CTO at the time. They nodded and agreed it was important. It would only take about 2 days of consulting. They later said "We can't get it together to hire you." Not due to the money (only a few grand, really), but about what you might call "political will."

Their front-end performance situation has sadly never gotten better… and has definitely gotten worse.

We started to build the visualization project anyway, and it got us a little bit of fame and a lot of consulting work: http://twistori.com

And just under a year later, we published a book on front-end performance: http://jsrocks.com

But I still wish we could have fixed their damn front end. Every time somebody tweets a link to a tweet and it opens up as a web page on my iPhone and I have to watch a blank screen for 10 freaking seconds before the tweet actually shows up, I die a little inside.

This story amuses & horrifies people who believe that startups are more flexible, responsive, & sane than big companies. At this time, Twitter the company was definitely smaller than 30 people… around 15 if memory serves, but I'm not sure. It was definitely small, either way. Meanwhile Twitter the site was growing in popularity by leaps & bounds every second. I'm sure the bandwidth saved alone would have paid back our consulting fees in a matter of a few weeks, or less.

Without knowing the internal details it sounds like there's some fear locking out change-making decisions.

I tried to use the twitter mobile site. I'll never do it again because it takes too long to load.

This is why people use the twitter app instead of the site.

Simplistic.

The web will be a better place once everyone has 100mbps and servers have 10gbps. Sites like the verge can load in one second without caching.

Wirth’s Law: Software is getting slower more rapidly than hardware becomes faster.

Web data usage != slow software

But the amount of data will also increase relative to available bandwidth. A few years ago a 2MB page would have been unthinkable. Maybe in five years we'll be seeing 10MB of resources delivered for a page load.

Which at 100mbps will take about 1 second.

True, but we're not going to instantly switch everyone on the planet to those speeds.

My parents have only upgraded to "high speed" 512kbs in the last few years. My 80 year of Grandfather is still on dial up. I don't think expecting him to wait 5 minutes to load a Tweet is reasonable.

Unfortunately bandwidth has not kept up with the rate of Moore's law(unrelated one, I know), so it is becoming a bottleneck for faster computing(along with spin disk speeds) for a large section of people.

And even if you have large bandwidth, the latency that comes into play is another factor, not to mention folks opening 50 tabs which causes delays in opening and rendering a new one.

And once everyone has that for a little while it will become slow and painful again.

Remember dailup back in the day? When a T1 would have been overkill for a single household? Look at those numbers from today's perspective: a T1 is only 1.5 Mbps, thats just 192 KBps.

The popularity of mobile devices for browsing (or tethering) means that for the first time in the Web's history the amount of available CPU and bandwidth has been going down, not up, for a huge chunk of users.

Reply on news.ycombinator.com