Firstly, applications are never limited by memory, disk, CPU and so on. Entire systems are. Usually for applications we use a different terminology, like CPU-intensive, memory-intensive and so on. You can also use terms like database-centric.
There are no general answers to your question, unfortunately. A web application that processes videos will be CPU-intensive, whereas a very large website using a in-memory queue or tons of caching would be memory-intensive, etcetera.
When we look at whole systems, instead, the answer becomes a bit more interesting. A bit on background: I've been a senior architect on several large web sites. The way the code is developed, in my experience, is the following:
- The application is architected keeping in mind whether it's expected to be CPU-intensive or memory-intensive. Also, CDNs like Akamai are planned at this stage.
- The hardware is planned on a tentative level under the assumptions of the architect.
- The application is developed according to the architecture without major optimizations.
- Profiling under load testing is performed. Major bottlenecks are identified and relevant optimizations are inserted the code base.
- A new load testing round is performed and the hardware is adapted - ideally you want applications without bottlenecks -- the expected bottleneck would be the web server itself (e.g. Apache or IIS dies because of too many connections, independently of the application).
- Based on the results of 4. and 5. and the traffic estimates, the number of webservers is decided.
- At this point, since you can scale out web servers, the bottleneck will ultimately be the database server.
As you can see, the answer is not simple. There is no general steadfast rule in these systems and actually significant expenditure is expected in making sure that all possible bottlenecks are eliminated and the web application can withstand the expected traffic with ease.