Why does everyone worry about speed so much?
With today's technology speed isn't a problem. What happens server side depends on the CPU/RAM and the upload speed that the server has. What happens client side is depended on the clients download speed.
If my SQL query takes .0002 seconds to query and load and the client's download speed is DSL (old style dial-up) then it would take just as long as if the query took .2 seconds to do the same thing and the client had broadband and downloaded it instantly.
The performance requirements for an application is suggestive to the need. For example, my own application gets hits by hundreds of thousands of users every single day. Performance is a very big thing when dealing with that many users on a daily bases. As it is, its more about handling volume then single user performance.
Logic without the fatal effects.
All code snippets are licensed under WTFPL.
Sometimes the pursuit of purity, and efficiency is mistakenly taken to be the search for "speed".
Did I need all those include files? Did I need to use the Framework for that simple job? If the data driving this site only changes during the day when staff in my TZ are working, what if I cached it at night then? Could I refactor out the method from that class? I'm sure I could be using that somewhere else too. This "smells", its not DRY....
Addressing these daily occurrences could be seen as optimizations and achieving speed gains may well not be the goal, but "it'll go faster" is certainly an handier term to paint them.
CPU, RAM, bandwidth, etc aren't the only considerations. If you're pulling data from an external source, say Twitter and/or FB, you have to account for the time it takes to fetch that data from another site.
Or say you have a website that does a lot of writes to your database, and you've chosen to use MyISAM as your table type. MyISAM uses table level locking, so you can only perform one write at a time. This can easily make your site grind to a halt even if you have a high-end server. Yet if you use InnoDB, only the affected row is locked, so you can perform multiple writes at the same time. That would perform better even on lower level hardware.
Unoptimized DB queries with complex joins and unions can also be a huge bottleneck causing a site to run very slow when it needn't have to.
Sure, if you're making a simple site with nothing complex, and a a moderate amount of traffic, you don't have to worry about performance optimization very much. But not every project is the same and depending on the site/app, even an over-looked setting can cripple the fastest machines.
Just to add something more well from my experience one another thing is the speed of an application suffer from bad or congested design and people most of the time blame technology for that.
If the design is not right then speed may suffer but still i feel it is negligible if the site is not very big.
I have seen site with million rows running a 4 to 5 level sub query (which can be may be made better) but the site is still running ok for the users
Some apps try calling (including) everything in the all pages including homepage, which makes things worst. I have seen some app calling more than 20 libraries in every pages.
Some others try to make it too generic and magical and are able to get the magic/power but eventually turn the things into big elephant that normal people cannot afford or need heavy maintenance or many things (by products) comes along with it(even if you don’t want) causing problem in speed.(I think magento, an ecom app is very good example of this)
So trade-off questions relating to performance vs speed vs features have always been there and will remain.
Just a personal thought.