by skimbrel on 3/5/12, 3:33 PM with 110 comments
by mfringel on 3/5/12, 5:10 PM
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.
by poutine on 3/5/12, 3:54 PM
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.
by rowanseymour on 3/5/12, 4:20 PM
by johncoltrane on 3/5/12, 4:27 PM
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.
by untog on 3/5/12, 3:56 PM
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.
by keeperofdakeys on 3/5/12, 11:14 PM
by hpaavola on 3/5/12, 4:35 PM
by zacman85 on 3/5/12, 4:03 PM
by noonespecial on 3/5/12, 4:10 PM
by tripzilch on 3/5/12, 7:43 PM
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...
by tzury on 3/6/12, 8:46 AM
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...
by tpurves on 3/5/12, 4:08 PM
User-defined image backgrounds can also be up to 800k-ish for twitter too right?
by OneBytePerGreen on 3/5/12, 5:59 PM
It really adds up for a large thread.
by webwanderings on 3/5/12, 3:58 PM
by swang on 3/5/12, 6:28 PM
by mrcalzone on 3/5/12, 6:58 PM
by neilmiddleton on 3/5/12, 4:07 PM
by AdamTReineke on 3/5/12, 3:53 PM
by ahoyhere on 3/6/12, 7:04 AM
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.
by rajpaul on 3/6/12, 5:41 AM
This is why people use the twitter app instead of the site.
by funkah on 3/5/12, 3:55 PM
by shimon_e on 3/5/12, 4:17 PM