Abrasion's post made me want to post about this. We're starting a "make Chrome fast again" performance initiative inside the Chrome team. It kicked off last week.
When Chrome first came out, our biggest selling point was performance. Chrome was just shockingly fast compared to everyone else, not only on dumb things like JS benchmarks, but on starting up, loading pages, general usage, etc.
Over the years other browsers have gotten significantly better in many of these respects, while on the team we've in some ways taken our eyes off the ball. In particular, a lot of people have slow starts (especially when opening lots of tabs), Chrome gets sluggish and unresponsive, you can't scroll certain pages while loading, etc. We still do a lot of things really well -- our network stack is pretty awesome, the omnibox is super cool, etc. -- but we need to smash the worst cases of the browser feeling sucky. We get a lot of user reports of "Chrome is slow". That's too vague to do anything about, but in aggregate that tells us we need to improve.
I'm excited that this initiative is going to happen, and I'll be leading a specific piece of it -- trying to eliminate jankiness on the UI and IO threads. Chrome is both multi-process and multi-threaded; the UI thread is the "main thread" where things like processing incoming events and implementing the UI happen, while the IO thread is primarily a message-passing thread that is used to handle all IPC traffic between processes. (Actual disk I/O doesn't happen on the IO thread, confusingly enough, since that would be slow and block everything else; instead it generally happens on other threads such as the File thread or the DB thread.) If either of these slow down, the whole browser can start hitching; you'll see tab throbbers freeze before continuing to spin, the omnibox will stop accepting typing for a moment, UI won't repaint correctly on resizing, etc. This is especially a problem during startup, when ideally we'd still be responsive even if your tabs hadn't loaded, but in practice the whole browser can slow to a crawl.
I'd show you the cool dashboards we have to start tracking this stuff down, but unfortunately they're internal-only. But based on our data, we have about an order of magnitude improvement to make in overall thread responsiveness to get to where I think would be healthy. (The problem seems to be especially bad on Mac, I'm not sure why. Lesson: Use Windows. :P)
There are lots of other pieces going on too: people looking at the holistic picture of startup, people worried about scrolling perf and web page responsiveness, and people trying to look into how extensions affect things. That last is a big issue: we find that extensions, malware, and antivirus programs are an enormous source of slowdowns. Often people will assume that running various ad blockers will make their browser load faster but in reality with the ones we've looked at the opposite is true. Other times people will have 60 different extensions all injecting content into the page and wonder why their browser is slow. We're trying to figure out how we can attribute slowdowns to particular extensions, offer users opportunities to try running with those disabled to see if performance is better, and work with extension authors to make the common extensions more performant.
Anyway, I hope by six months from now Chrome will feel noticeably snappier and better. In the meantime, if you have *reproducible* cases where things are slow, please do file bugs and let me know so I can triage them. (Cases you can't reproduce aren't ones where we don't care, but hopefully we'll track them down using some of our other metrics; reproducible bugs are ones where we can take action on an external report.)