4 ms·

First, I believe that "every millisecond counts" is a good principle in web design. There is enough latency that we can't avoid, which is why we should avoid la

First, I believe that "every millisecond counts" is a good principle in web design. There is enough latency that we can't avoid, which is why we should avoid latency wherever it is possible. Considering this, 45K is a big deal indeed. Second, just some hours ago, I read that the mere execution (not the download!) of jQuery takes about a second on an iPhone 3G. These devices and similarly weak ones are still out there, which is easy to forget if you test only on the latest hardware. Lastly, keep in mind that bandwidth isn't always ideal. Consider mobile: In rural areas, 3G isn't always available. When I'm on the train, loading the slim HN itself often is not an issue, while many other pages simply time out. In developing countries, bandwidths are often very low, too. 56kbps still is a realistic bandwidth. And downloading 45K on a 56kbps connection takes almost 7s.

cmircea 14y ago
Depending on the definition of developing countries, I think you would find "developing" countries can have much better connections than many western developed countries. This is $10/mo: http://www.speedtest.net/result/2436462597.png http://www.speedtest.net/result/2436462597.png (local server) & http://www.speedtest.net/result/2436466252.png http://www.speedtest.net/result/2436466252.png (across the pond.
tambourine_man 14y ago
Every millisecond does count. But design is about compromise. By that logic we shouldn't use CSS at all, but we choose to pay the price of a few KBs for the returned value. I'm all for efficiency, I'll use Zepto or a focused custom made solutions whenever I can, I'll squeeze every byte out of the images, serve resolution specific versions, gzip, etc. But there are some compromises that I'm not willing to make. Take images for example. If I can see image quality degradation on something that I find important, I won't compress it further, even if it's huge. Add a few iPad retina display PNGs and suddenly 45KB seems like small change. Sometimes I'd rather have the user wait for a great result than deliver a poor one fast. In the case of jQuery 2.0, dropping IE8 support seems a poor and premature kind of optimization. If your target is a memory starved 128MB iPhone 3G on Edge, than 45K for a single JS library is still way too much. Not only it would take forever to load and run, but unresponsiveness and eventual crashing would still be a problem. I think the effort would be better spent on improving jQuery mobile. People on 56kbps connections could be running even older versions of IE.
- codeka 14y ago
  There's also a difference when you're developing your own site compared to when you're developing a framework or library. If your library is used on more than half of the top 100,000 websites (as jQuery is) then a 45KB saving or a 100ms speed boost, 50,000 times over is a big deal.

cmircea 14y ago

Depending on the definition of developing countries, I think you would find "developing" countries can have much better connections than many western developed countries. This is $10/mo: http://www.speedtest.net/result/2436462597.png http://www.speedtest.net/result/2436462597.png (local server) & http://www.speedtest.net/result/2436466252.png http://www.speedtest.net/result/2436466252.png (across the pond.

tambourine_man 14y ago

Every millisecond does count. But design is about compromise. By that logic we shouldn't use CSS at all, but we choose to pay the price of a few KBs for the returned value. I'm all for efficiency, I'll use Zepto or a focused custom made solutions whenever I can, I'll squeeze every byte out of the images, serve resolution specific versions, gzip, etc. But there are some compromises that I'm not willing to make. Take images for example. If I can see image quality degradation on something that I find important, I won't compress it further, even if it's huge. Add a few iPad retina display PNGs and suddenly 45KB seems like small change. Sometimes I'd rather have the user wait for a great result than deliver a poor one fast. In the case of jQuery 2.0, dropping IE8 support seems a poor and premature kind of optimization. If your target is a memory starved 128MB iPhone 3G on Edge, than 45K for a single JS library is still way too much. Not only it would take forever to load and run, but unresponsiveness and eventual crashing would still be a problem. I think the effort would be better spent on improving jQuery mobile. People on 56kbps connections could be running even older versions of IE.

codeka 14y ago
There's also a difference when you're developing your own site compared to when you're developing a framework or library. If your library is used on more than half of the top 100,000 websites (as jQuery is) then a 45KB saving or a 100ms speed boost, 50,000 times over is a big deal.