3 ms·
User-perceived response time has little to do with the choice of language on the server. Access to DBs, lack of proper caching strategies, CDNs, minification of
by VeejayRampay 13y ago
User-perceived response time has little to do with the choice of language on the server. Access to DBs, lack of proper caching strategies, CDNs, minification of CSS and Javascript play a much larger role in the big picture. Only when you've extracted all the juice from all those lower-hanging fruits must you start to blame the language or framework used to developer a website IMHO.
- bhauer 13y agoI'm not talking about a client-side performance issue. Those are tangential matters. We should all endeavor to comply with best practices for delivery of static assets to improve client-side performance including minification, strategic concatenation, use of content delivery networks, caching strategies, and so on. Let's put that aside, however. What I am talking about is a real request to a non-cachable dynamic page or service endpoint. It's the frustration of "Waiting for [servername]..." status bar messages. It's the frustration of looking at the Network panel in Chrome or Firebug and realizing that it's just spinning waiting for the first byte of the response. It might be a server-templated HTML page. It might be an API call fetching some JSON. But the sorry state even in 2013 is that a disturbingly large number of sites will spend hundreds of milliseconds, and in some cases full seconds to respond to dynamic requests that ultimately deliver quite trivial response payloads. I for one want developers to stop sweeping these performance failures under the rug by deflecting server-side performance failure with client-side cover.