Several people in this thread state "It's cached, so why does it matter?"<p>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?<p>What on earth is twitter doing on a given page that needs two megabytes of code?*<p>* As of March 2012, for I'm sure this will look silly when there are 2 gigabyte pages, 20 years from now.
His rant doesn't seem too informed: "aggressive anti-performance and apparent contempt for the web by Twitter’s designers"<p>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.
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
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".<p>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.<p>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.<p>A relatively high cost but one we can afford, with the help of caching.
File this under "annoying to developers and no-one else".<p>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.<p>Yes, they should bring that amount down. No, it probably isn't going to be a priority.
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.
Try <a href="http://m.twitter.com" rel="nofollow">http://m.twitter.com</a> , it's the dressed-down mobile version of Twitter.<p>It doesn't have all the features, but easily makes up for that by the fact that you can actually <i>click around</i> as much as you like without your browser getting all slumpy from loading huge pages or doing javascript.<p>You'd expect caching to help, but there's a lot of truth in the <i>jQuery tax</i> 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.<p>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.<p>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.<p>[1] <a href="http://samsaffron.com/archive/2012/02/17/stop-paying-your-jquery-tax" rel="nofollow">http://samsaffron.com/archive/2012/02/17/stop-paying-your-jq...</a>
Well, I measured that with chrome and it wasn't 2MB rather ~450 KB.<p>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.<p>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.<p>381Kb out of those 450 belongs to his own background image [2].<p>In other words, twitter does a very good job at making their service fast and speedy.<p>1. <a href="https://twitter.com/#!/bos31337/status/172156922491969536" rel="nofollow">https://twitter.com/#!/bos31337/status/172156922491969536</a><p>2. <a href="https://twimg0-a.akamaihd.net/profile_background_images/97067350/backy.jpg" rel="nofollow">https://twimg0-a.akamaihd.net/profile_background_images/9706...</a>
How does this work, is he reporting compressed or uncompressed sizes of data? text/css/js compresses really well for transmission, images do not.<p>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 <!--IE6sux--> comments.<p>It really adds up for a large thread.
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.
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."<p>Their front-end performance situation has sadly never gotten better… and has definitely gotten worse.<p>We started to build the visualization project anyway, and it got us a little bit of fame and a lot of consulting work: <a href="http://twistori.com" rel="nofollow">http://twistori.com</a><p>And just under a year later, we published a book on front-end performance: <a href="http://jsrocks.com" rel="nofollow">http://jsrocks.com</a><p>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.<p>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.
I tried to use the twitter mobile site. I'll never do it again because it takes too long to load.<p>This is why people use the twitter app instead of the site.