I generally agree, but would present a specific software-architecture cause for most responsiveness issues: the simplest way to perform a UI update is "toss and rebuild" - remove all the elements and replace them with new ones containing changes. This method is straightforward and much more maintainable than the performant alternative: hold everything in place and manipulate the minimum needed to update.
It's a particularly important trade-off as you start considering, for example, more complex layouts where the size and positioning of one element may affect any number of others, elements get added or removed, etc. There's a spectrum of variations between these two extremes that let you choose between maintainable and fast, but neither end really has an ideal combination of both. Language and coding style changes can help, too, but a truly complete solution still seems absent.
The initial load is the second major source of peril for responsiveness. Even if a custom cache for the load is used, the user's first-run impression is still going to be of an uncached experience. Here the disk seek, as you mention, is of huge importance. But I find that I'm personally less irritated by load times than I am by software with intermittent spikes of high CPU usage, which will slow down the whole system at unexpected moments.
Well, I agree that there are specific program architectures that can cause problems, but I haven't had the experience where "toss and rebuild" is the bottleneck.
One of the other responses nailed what is a more common problem IME -- network activity and UI activity on the same single-threaded event loop. Firefox and Chrome both have this problem (or what amounts to it essentially). For example, in Chrome:
This bug has gone unfixed for YEARS (older ones were marked dupes of later ones).
The way we write software now is just too difficult to get right. Once you have 1M lines of C++ code there are going to be crazy performance bugs that nobody can fix. Chrome has some of the best engineers on the planet and they're not immune to this by any means.
I guess I would amend my original answer to say that "software size" is the problem. Everybody thinks they know how to write performant software. But that's only when you can fit everything in your head.
I would say that "toss and rebuild" isn't the #1 culprit because the web browser is the ultimate "toss and rebuild" architecture -- that is, every request and response stand alone. Yes web pages can be ungodly slow and unresponsive. But it's possible to make them responsive if you really simplify -- i.e. Google or craigslist.
In theory we could have a stateful web and make it faster. But I think our collective programming skill and our languages/tools just aren't up to the task. I think the web exists as it is, and is as popular as it is, because lots of people with "domain knowledge" could write dirty PHP scripts and such. They aren't fast but they get the job that users want done.
It's a particularly important trade-off as you start considering, for example, more complex layouts where the size and positioning of one element may affect any number of others, elements get added or removed, etc. There's a spectrum of variations between these two extremes that let you choose between maintainable and fast, but neither end really has an ideal combination of both. Language and coding style changes can help, too, but a truly complete solution still seems absent.
The initial load is the second major source of peril for responsiveness. Even if a custom cache for the load is used, the user's first-run impression is still going to be of an uncached experience. Here the disk seek, as you mention, is of huge importance. But I find that I'm personally less irritated by load times than I am by software with intermittent spikes of high CPU usage, which will slow down the whole system at unexpected moments.