4 ms·

I know it's awfully tempting to obsess on something that is easy to measure, like file size. I also know it's tempting to imply things like "twice the file size

I know it's awfully tempting to obsess on something that is easy to measure, like file size. I also know it's tempting to imply things like "twice the file size means twice the page load time". But it's not true. It's NOT true. Look at this video at 6m30s: http://channel9.msdn.com/Events/Build/2012/3-132 http://channel9.msdn.com/Events/Build/2012/3-132 Productively optimizing a web page is no different than optimizing any other code. If you want to know why a web site is slow, profile it or run it through a tool like webpagetest.org. Don't just set off to rewrite all your loops to run backwards, or eliminate function calls, or reduce the amount of this or that without any understanding of the result.

corresation 13y ago
Look at this video at 6m30s What does that video possibly prove? That if you compare completely different sites, you can't use reductionist measures of individual attributes to compare speed? Is there anyone on HN who actually doesn't already know that? This is asking which of a collection of mystery vehicles is the fastest by engine size, and then revealing that one is a dump truck, one a train, and the other a motorcycle, with results that should surprise no one. The only people who would possibly be interested in this project are people who are attempting to optimize the experience their app provides, presumably in a holistic fashion. It is pretty much part and parcel that such a person is going to minimize elements, CSS, images, and scripts in such a case, and aren't simply going to replace jQuery with something like this and assumes that it will make everything fast. The reality of something like jQuery, like Ruby on Rails or MongoDB, is if you start with it you'll likely be stuck with it. You can't simply make a full site and run it through the profiler and swap out components without significant rewriting.
- dmethvin 13y ago
  > Is there anyone on HN who actually doesn't already know that? I see a lot of discussion here based on the premise that this smaller script will make a big difference in overall page load time. It's why the audience in that video was leaning towards the site with the most JavaScript being the slowest. The first benefit listed on the minified.js page is "Minified is smaller!" so exactly what benefits does "smaller" imply? > The only people who would possibly be interested in this project are people who are attempting to optimize the experience their app provides, presumably in a holistic fashion. I agree, and creating your own homebrew framework for a large project in a holistic fashion has its own pitfalls. Especially if you've never done it before.
  - benologist 13y ago
    "Smaller" on a slow connection does make a big difference. That's almost everyone, everywhere.
    - chc 13y ago
      My phone is fast enough that the difference between 4KB of data and 80KB is not huge.
      - girvo 13y ago
        With all due respect: Not everyone else's phones are.
        chc 13y ago
        I don't believe you actually read the context of my comment.
        girvo 13y ago
        I actually believe that I did. I understood the point you were making, and I'm pointing out that while your devices don't have that constraint, others may, depending on your target audience. :)
      - corresation 13y ago
        There are endlessly discussions on here whether to go with an app or web, with many favouring the app angle because of endemic performance issues on the web when you're running on an ultra-low power mobile device. The web is often death by a thousand cuts. Every decision by itself may seem small, but the end result is an unenjoyable, inefficient, battery-sucking result that leads people to abandon the web.
      - eksith 13y ago
        Unless you're being targeted as a potential customer or a member of the audience, your mobile performance is irrelevant. What is relevant is that the majority of the devices being used to access sites don't have the performance of mid-high end models.
paulsutter 13y ago
There's only one way to make a tiny page that loads super fast - and that's to make every single decision with an eye towards efficiency. People who say "hey, what's an extra 30KB for one library? It's only like 10x larger" will tend to reach a similar conclusion at every decision point. And that's why the internet is full of massive, bloated, slow web pages. Single decisions don't cause bloat. Bloat comes from a slack attitude towards efficiency. I'm not saying this project is an important breakthrough, but I definitely applaud the effort. I've always been surprised at the large size of jquery. I'd love to see a benchmark for runtime performance, including a comparison of parsing time and a benchmark of common operations.
- hnriot 13y ago
  But the reality is, everyone that visits your site already has jQuery in their cache, because the common cdn sources are so ubiquitous, this making this 4k library actually add to your page load footprint. Using the most common, most likely to be a cache hit library is more efficient than using the smallest.
  - LocalPCGuy 13y ago
    People need to stop saying this.
    - rralian 13y ago
      Please elaborate.
      - waitwhat 13y ago
        One thing... Mobile Safari didn't use to cache anything over 15KB uncompressed. http://www.phpied.com/iphone-caching/ http://www.phpied.com/iphone-caching/ (No idea about more current versions of iOS or browser-caching on other mobiles OSs.)
      - adventured 13y ago
        It's a reasonable point. Given the vast array of jQuery versioning across just the top thousand web sites, it's very plausible a user will not have each one of those cached, and then a lot of sites vary on what cdn (if not local) they're using. I would be willing to bet that among just the top 1,000 sites, a user would be required to have 25 to 30 copies of jQuery cached to cover all the sites.

corresation 13y ago

Look at this video at 6m30s What does that video possibly prove? That if you compare completely different sites, you can't use reductionist measures of individual attributes to compare speed? Is there anyone on HN who actually doesn't already know that? This is asking which of a collection of mystery vehicles is the fastest by engine size, and then revealing that one is a dump truck, one a train, and the other a motorcycle, with results that should surprise no one. The only people who would possibly be interested in this project are people who are attempting to optimize the experience their app provides, presumably in a holistic fashion. It is pretty much part and parcel that such a person is going to minimize elements, CSS, images, and scripts in such a case, and aren't simply going to replace jQuery with something like this and assumes that it will make everything fast. The reality of something like jQuery, like Ruby on Rails or MongoDB, is if you start with it you'll likely be stuck with it. You can't simply make a full site and run it through the profiler and swap out components without significant rewriting.

dmethvin 13y ago
> Is there anyone on HN who actually doesn't already know that? I see a lot of discussion here based on the premise that this smaller script will make a big difference in overall page load time. It's why the audience in that video was leaning towards the site with the most JavaScript being the slowest. The first benefit listed on the minified.js page is "Minified is smaller!" so exactly what benefits does "smaller" imply? > The only people who would possibly be interested in this project are people who are attempting to optimize the experience their app provides, presumably in a holistic fashion. I agree, and creating your own homebrew framework for a large project in a holistic fashion has its own pitfalls. Especially if you've never done it before.
- benologist 13y ago
  "Smaller" on a slow connection does make a big difference. That's almost everyone, everywhere.
  - chc 13y ago
    My phone is fast enough that the difference between 4KB of data and 80KB is not huge.
    - girvo 13y ago
      With all due respect: Not everyone else's phones are.
      - chc 13y ago
        I don't believe you actually read the context of my comment.
        girvo 13y ago
        I actually believe that I did. I understood the point you were making, and I'm pointing out that while your devices don't have that constraint, others may, depending on your target audience. :)
    - corresation 13y ago
      There are endlessly discussions on here whether to go with an app or web, with many favouring the app angle because of endemic performance issues on the web when you're running on an ultra-low power mobile device. The web is often death by a thousand cuts. Every decision by itself may seem small, but the end result is an unenjoyable, inefficient, battery-sucking result that leads people to abandon the web.
    - eksith 13y ago
      Unless you're being targeted as a potential customer or a member of the audience, your mobile performance is irrelevant. What is relevant is that the majority of the devices being used to access sites don't have the performance of mid-high end models.

paulsutter 13y ago

There's only one way to make a tiny page that loads super fast - and that's to make every single decision with an eye towards efficiency. People who say "hey, what's an extra 30KB for one library? It's only like 10x larger" will tend to reach a similar conclusion at every decision point. And that's why the internet is full of massive, bloated, slow web pages. Single decisions don't cause bloat. Bloat comes from a slack attitude towards efficiency. I'm not saying this project is an important breakthrough, but I definitely applaud the effort. I've always been surprised at the large size of jquery. I'd love to see a benchmark for runtime performance, including a comparison of parsing time and a benchmark of common operations.

hnriot 13y ago
But the reality is, everyone that visits your site already has jQuery in their cache, because the common cdn sources are so ubiquitous, this making this 4k library actually add to your page load footprint. Using the most common, most likely to be a cache hit library is more efficient than using the smallest.
- LocalPCGuy 13y ago
  People need to stop saying this.
  - rralian 13y ago
    Please elaborate.
    - waitwhat 13y ago
      One thing... Mobile Safari didn't use to cache anything over 15KB uncompressed. http://www.phpied.com/iphone-caching/ http://www.phpied.com/iphone-caching/ (No idea about more current versions of iOS or browser-caching on other mobiles OSs.)
    - adventured 13y ago
      It's a reasonable point. Given the vast array of jQuery versioning across just the top thousand web sites, it's very plausible a user will not have each one of those cached, and then a lot of sites vary on what cdn (if not local) they're using. I would be willing to bet that among just the top 1,000 sites, a user would be required to have 25 to 30 copies of jQuery cached to cover all the sites.