4 ms·

A friend analyzed the page and noted that they didn't minify or combine anything. "One obvious reason is that they're serving unminified and unconcatenated Jav

A friend analyzed the page and noted that they didn't minify or combine anything. "One obvious reason is that they're serving unminified and unconcatenated Javascript and CSS files. A single page load causes 92 requests to the server, and they're not using a CDN for any of that. They're also not setting the Cache-Control and Expires headers, so the browser isn't caching many of those files, including on 80k file full of response strings. For the non-technical, this means the site is essentially killing itself. An optimized and properly tuned production website would load one (1) HTML document, one (1) CSS document, and one (1!) JS document, they're loading 92. "

deleted 13y ago
[deleted]
- evan_ 13y ago
  True, but it's not like minifying and serving from a CDN will make anything worse, and it could improve things quite a bit.
- WalterSear 13y ago
  It is, however more than just a smell: a front end of such an egregious turditude doesn't just uninspire confidence in any of the system - these poor practices demonstrate that whoever is in charge of the checks and balances hasn't done their job.
thejerz 13y ago
While that is an egregious amount of requests, it's not the reason the site is broken. Based on my experience as a user and poking around quickly in Firebug, the issues are largely server-side.
- patrickg_zill 13y ago
  True, it is just an additional data point. You have to wonder, if they can't minify their JS or even run the pages through the Yahoo YSlow tool, what is the quality of the backend?
  - outside1234 13y ago
    I think we really don't have to wonder at this point.
- danielweber 13y ago
  Yeah, people bitch about client-side because it's what they can see. But they are mostly just dumb inefficiencies that are easily fixed. (And if you were doing a sane rollout, you wouldn't be worrying about this stuff because you only have 10K users at once. Save the minifying for later.)
ngcazz 13y ago
Although I do agree with your final point, serving static files is no issue for modern web servers.
ssmoot 13y ago
I seriously doubt that the static content performance of NGinx (or whatever) has anything to do with performance issues. They're probably spending more money on bandwidth than they need to, and offer a slightly degraded user experience, especially for people on slower connections, but otherwise... Things may have changed since October 1st, but on second page load of the home-page, I'm seeing the majority of content as either cached or served by CDN, a relatively small functional payload compared to a lot of HN darlings, and an 79ms latency for the main request. None of that is really alarming IMO. Even so, half these assets are trackers and 3rd party resources that would probably be CDNed externally. If storage IO and bandwidth isn't your limit (and internally the URLs could easily be routed to different servers entirely as well as caching proxies), then it's pretty plausible that there's practically nil overall performance impact as far as service availability goes. Also, I think the whole "you should only use one of each type of asset" philosophy is debatable at least.

deleted 13y ago

[deleted]

evan_ 13y ago
True, but it's not like minifying and serving from a CDN will make anything worse, and it could improve things quite a bit.
WalterSear 13y ago
It is, however more than just a smell: a front end of such an egregious turditude doesn't just uninspire confidence in any of the system - these poor practices demonstrate that whoever is in charge of the checks and balances hasn't done their job.

thejerz 13y ago

While that is an egregious amount of requests, it's not the reason the site is broken. Based on my experience as a user and poking around quickly in Firebug, the issues are largely server-side.

patrickg_zill 13y ago
True, it is just an additional data point. You have to wonder, if they can't minify their JS or even run the pages through the Yahoo YSlow tool, what is the quality of the backend?
- outside1234 13y ago
  I think we really don't have to wonder at this point.
danielweber 13y ago
Yeah, people bitch about client-side because it's what they can see. But they are mostly just dumb inefficiencies that are easily fixed. (And if you were doing a sane rollout, you wouldn't be worrying about this stuff because you only have 10K users at once. Save the minifying for later.)

ngcazz 13y ago

Although I do agree with your final point, serving static files is no issue for modern web servers.

ssmoot 13y ago

I seriously doubt that the static content performance of NGinx (or whatever) has anything to do with performance issues. They're probably spending more money on bandwidth than they need to, and offer a slightly degraded user experience, especially for people on slower connections, but otherwise... Things may have changed since October 1st, but on second page load of the home-page, I'm seeing the majority of content as either cached or served by CDN, a relatively small functional payload compared to a lot of HN darlings, and an 79ms latency for the main request. None of that is really alarming IMO. Even so, half these assets are trackers and 3rd party resources that would probably be CDNed externally. If storage IO and bandwidth isn't your limit (and internally the URLs could easily be routed to different servers entirely as well as caching proxies), then it's pretty plausible that there's practically nil overall performance impact as far as service availability goes. Also, I think the whole "you should only use one of each type of asset" philosophy is debatable at least.