Great post by Jonathan. For the case of a big 'single page' JS app where a most of the rendering happens from Javascript fetched on the page, I'd guess this approach won't help that much since you have to fetch the JS from the CDN/cookieless domain anyways. Still though, definitely worth an experiment to know for sure.
For the case of a big 'single page' JS app where a most of the rendering happens from Javascript fetched on the page, I'd guess this approach won't help that much since you have to fetch the JS from the CDN/cookieless domain anyways.
If you're taking that approach, you probably don't care much about performance anyways (I've never seen a pure JS SPA which rendered fast).
Reminds me of the time, 2 or 3 years ago, when Google announced that every page which would take more than 300ms to load and render would be downranked in the search.
Comments
Great post by Jonathan. For the case of a big 'single page' JS app where a most of the rendering happens from Javascript fetched on the page, I'd guess this approach won't help that much since you have to fetch the JS from the CDN/cookieless domain anyways. Still though, definitely worth an experiment to know for sure.
If you're taking that approach, you probably don't care much about performance anyways (I've never seen a pure JS SPA which rendered fast).
FastMail begs to differ: http://blog.fastmail.com/2014/12/15/dec-15-putting-the-fast-...
Loads & renders in between 0.5-1.0s.
(Though I must say FastMail is rather unique in this regard.)
Reminds me of the time, 2 or 3 years ago, when Google announced that every page which would take more than 300ms to load and render would be downranked in the search.
Seems like we’re going backwards...
try http://hn.premii.com/ - Even though it relies on 3rd party for data (backend), it loads quickly.
If you have a control over backend, you can optimize it further.