4 ms·

Page weight may matter, but I think amortized page weight matters most. It's like the marshmallow experiment for the web. If you can make one request at 10x the

Page weight may matter, but I think amortized page weight matters most. It's like the marshmallow experiment for the web. If you can make one request at 10x the size, but it's only made 1/100th as often (presumably spans multiple pages) then as long as people come back enough to justify that initial extra cost, you've effectively decreased to 1/10th again. That's why I think AJAX, web manifest [1], indexedDB, localStorage, etc. need to be leveraged much more. Imagine most of your app loading without making a single request, except for the latest front page JSON, or the latest . You have a bunch already in indexedDB so you just ask the server "hey, what's new after ID X or timestamp T?" So your two minutes just became a couple milliseconds (or whatever your disk latency happens to be), and the data loads shortly thereafter, assuming there's not much new data to send back. And if you don't need any new resources, you only had to make a single request. [1] https://github.com/w3c/manifest https://github.com/w3c/manifest

nostrademons 11y ago
The initial page load matters a lot. That's the one where the user is deciding whether he'll be coming back to your site. The unfortunate thing about many caching technologies is that they speed up subsequent page loads, but do nothing for the initial one. You still need to pay attention to clean-cache load times. Indeed, it can often be worth it to pay a cost on total page load time to get first-paint time down - that's the time at which the first visual representation of the webpage appears, even if it's just the header, layout, and a bunch of boxes.
arohner 11y ago
This is a bad idea, because users may not give you a second chance. The research says over and over again, users respond negatively to small increases in latency. In fact, if I knew of a way to decrease the size of the first load, at the expense of making the second load take longer, I'd probably do it.
kellysutton 11y ago
The Ember FastBoot project has the goal to provide exactly this: lightweight HTML/CSS on the initial load and then hydrate the page/application with JS. http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-... https://github.com/tildeio/ember-cli-fastboot https://github.com/tildeio/ember-cli-fastboot

nostrademons 11y ago

The initial page load matters a lot. That's the one where the user is deciding whether he'll be coming back to your site. The unfortunate thing about many caching technologies is that they speed up subsequent page loads, but do nothing for the initial one. You still need to pay attention to clean-cache load times. Indeed, it can often be worth it to pay a cost on total page load time to get first-paint time down - that's the time at which the first visual representation of the webpage appears, even if it's just the header, layout, and a bunch of boxes.

arohner 11y ago

This is a bad idea, because users may not give you a second chance. The research says over and over again, users respond negatively to small increases in latency. In fact, if I knew of a way to decrease the size of the first load, at the expense of making the second load take longer, I'd probably do it.

kellysutton 11y ago

The Ember FastBoot project has the goal to provide exactly this: lightweight HTML/CSS on the initial load and then hydrate the page/application with JS. http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-... https://github.com/tildeio/ember-cli-fastboot https://github.com/tildeio/ember-cli-fastboot