otoh, Twitter.app on the Mac is awesome.
... except it uses the t.co URL shortener by default for everything you post. I had to switch back to the old Tweetie (which doesn't do this).
I'm curious, what's wrong with t.co?
New Twitter Has Become Browser Poison
81–90 of 108 posts
Re: New Twitter Has Become Browser Poison
#82Over time, NewTwitter does incur a large memory footprint. I've been traveling for a month and haven't looked into the problem in depth, but I'd bet the major culprit is our aggressive caching techniques. It's also worth investigating the number of polls and their frequencies. Timeline refreshes are dropped back to 90 seconds when the tab isn't focused, but not sure about other ones. As most people have reported, inf…
With respect, why exactly is total script size 912kb minified? That seems unexpectedly high. Likely not the root of the problem at hand, just curious. Also interested in what you plan to do to alleviate massive DOM issues, if you could share. Typically an overlooked point of performance.
I don't have a breakdown with precise numbers for you, but some bloat comes from the fact that we include all of our templates in the phoenix bundle. Some savings could come from fetching certain components and pages on demand, but right now, we pull down everything. Gzipped it drops to ~200k, which isn't terrible considering that this is fetched in parallel with API resources and the initialization of our cross-domain iFrame. We're currently working on getting our bootstrap time down, so the bundle size may be reduced as a result of that effort.
Re: DOM issues, when you switch around between pages and/or timelines, we detach the timeline DOM elements and keep a reference in memory. Upon returning to a previously loaded timeline, we do a repaint (not bad). Right now, we don't employ any such technique for an active timeline that has been scrolled a long way down. One thing we can do is detach large blocks of tweets that aren't in the viewport and splice them back in (while maintaining an accurate scroll height) if the user scrolls back up.
Re: New Twitter Has Become Browser Poison
#83New MBP here. It looks like it stays at a constant 7-8% cpu while sitting on the page, with momentary spikes to 30% every 15 seconds or so.
3% cpu continuously is enough to make a (my) macbook noticeably hotter.
Re: New Twitter Has Become Browser Poison
#84Over time, NewTwitter does incur a large memory footprint. I've been traveling for a month and haven't looked into the problem in depth, but I'd bet the major culprit is our aggressive caching techniques. It's also worth investigating the number of polls and their frequencies. Timeline refreshes are dropped back to 90 seconds when the tab isn't focused, but not sure about other ones. As most people have reported, inf…
Infinite scroll is also a way to make scrolling infuriating, especially if you are wanting to click links and fan out from that location: it forces you to avoid your browser's carefully designed history stack like the plague (opening new tabs or windows for navigation instead) lest you lose your incredibly valuable document you've carefully been scrolling down in (and which is now so large it is threatening to crippl…
That's not a problem inherent to infinite scroll at all. It's easily fixed by setting a hash value on the current page (the #foo in a URL) corresponding to the current scroll state, and updating it each time infinite scroll happens.
Why Twitter doesn't implement something like this is a whole different issue.
Re: New Twitter Has Become Browser Poison
#85Earlier quoted context omitted.
With respect, why exactly is total script size 912kb minified? That seems unexpectedly high. Likely not the root of the problem at hand, just curious. Also interested in what you plan to do to alleviate massive DOM issues, if you could share. Typically an overlooked point of performance.
I don't have a breakdown with precise numbers for you, but some bloat comes from the fact that we include all of our templates in the phoenix bundle. Some savings could come from fetching certain components and pages on demand, but right now, we pull down everything. Gzipped it drops to ~200k, which isn't terrible considering that this is fetched in parallel with API resources and the initialization of our cross-doma…
Good deal russ, thanks. There's a fine balance to maintain between combining and lazy loading files. Still seems to be one of the harder front end problems to solve since client side architectures are all relatively unique. Thanks again sir.
Re: New Twitter Has Become Browser Poison
#86Earlier quoted context omitted.
Are you using a really low end user agent to try to access the site? I don't know what's turned off for lower end browsers, but I just tested in desktop Webkit. There's a character count in the upper right of the tweet box. There are user icons, unless you clicked the "images off" link. As for total DM count, that isn't really possible right now. The app is just another API client, and the DM API endpoint only provid…
No, FF3.
Just a tip -- relaunch FF in safe mode (sans extensions etc.) and verify before reporting bugs like that, please.
Re: New Twitter Has Become Browser Poison
#87Earlier quoted context omitted.
Firefox has crazy memory leaks. Proof? This was the case with Firefox 2 but now it just seems like this is part of their reputation and is not necessarily grounded in fact.
I routinely leave my browser open for days on end and simply cycle through tabs, closing and opening new ones as needed, with usually ~10 open at a given time. I, too, noticed that firefox was eating up about half a gig of ram even when it wasn't doing anything, didn't have any youtube tabs open, etc. It got to the point where I would have to close firefox and restart after a day or two. Chrome fixed that. Now, I jus…
Are you sure it's wired memory that it's eating? Or just inactive "standby" memory which will be reallocated to other processes if needed?
If your free memory isn't close to 0, your OS is wasting RAM or you don't have much anything running.
Re: New Twitter Has Become Browser Poison
#88Earlier quoted context omitted.
Infinite scroll is also a way to make scrolling infuriating, especially if you are wanting to click links and fan out from that location: it forces you to avoid your browser's carefully designed history stack like the plague (opening new tabs or windows for navigation instead) lest you lose your incredibly valuable document you've carefully been scrolling down in (and which is now so large it is threatening to crippl…
That's not a problem inherent to infinite scroll at all. It's easily fixed by setting a hash value on the current page (the #foo in a URL) corresponding to the current scroll state, and updating it each time infinite scroll happens. Why Twitter doesn't implement something like this is a whole different issue.
You can imagine attempting to support something like this when the user has scrolled 20 pages worth through a timeline. We could, of course, backfill newer tweets subsequently up to the most recent (taking a minimum of two requests and a maximum of 20), but this would be expensive.
I mentioned somewhere else in this thread that we could maintain an accurate scroll height but detach more recent tweets when a timeline is scrolled a long distance. We could do the same thing here, and backfill as the user scrolls up. There are some challenging things to get right though if the user decides to jump to the top, etc. Definitely non-trivial.
Re: New Twitter Has Become Browser Poison
#89The thing I noticed in the slow new Twitter is that typing a new status seems to involve continuous autofill-like behavior for each character typed, which seemed to introduce round-trip lag (or javascript-parsing, or...) and causes characters to appear at a rate of ~1/second. Unusable. And this is one way that dominant sites fall: business considerations are given priority over the user experience. Maybe they just ha…
Or it could also point to a "Hey, this is different. I don't like change!" reaction that you always get when you change something's UI.
I don't think so. I'm not a huge tweeter and so anything that gets in the way of the rare things really jumps out at me, of which the slow status box is no small issue. Other than that the redesign is just that, an expanded sidebar with some fleshed out boxes. No big deal. That it's causing different problems for different people tells me that maybe something else is going on behind the hood. Heck, maybe they just want to be the network and aren't interested in providing a groovy webapp interface anymore, who knows.
Re: New Twitter Has Become Browser Poison
#90Earlier quoted context omitted.
That's not a problem inherent to infinite scroll at all. It's easily fixed by setting a hash value on the current page (the #foo in a URL) corresponding to the current scroll state, and updating it each time infinite scroll happens. Why Twitter doesn't implement something like this is a whole different issue.
You can imagine attempting to support something like this when the user has scrolled 20 pages worth through a timeline. We could, of course, backfill newer tweets subsequently up to the most recent (taking a minimum of two requests and a maximum of 20), but this would be expensive. I mentioned somewhere else in this thread that we could maintain an accurate scroll height but detach more recent tweets when a timeline…
Thanks for the response, I thought the reality would be much more complicated due to issues of scale.
This is primarily about supporting the back button, and I don't think users expect the latest data when going back through their browser history - generally pages aren't refreshed, and that's not an unusual or unexpected behavior. So you could cache each page state, without worrying about displaying newer tweets, though the caching mechanism itself incurs some nontrivial cost.