5 ms·
The page you link to on Medium renders after less than 100KB have been downloaded with an unprimed cache. Javascript is not required to read it. Javascript is
by chrisrhoden 10y ago
The page you link to on Medium renders after less than 100KB have been downloaded with an unprimed cache.
Javascript is not required to read it. Javascript is used to provide extra functionality outside of the download / render cycle, to speed the experience of the page up, and to make future navigation faster.
I understand where you are coming from, but you picked a bad example.
- TeMPOraL 10y ago> Javascript is used to (...) speed the experience of the page up That is one thing I'm totally not buying. How does JavaScript speed anything up over simple staticly rendered text, (which is what Medium should be)?
- cnp 10y agoOptimistic loading / prefetching / etc -- the list goes on if you take the time to think about it for more than a second.
- callumlocke 10y agoUsed correctly, it can hugely speed up the experience by preloading things. In an ideal case you could have a fast initial page load with static HTML. Then an async script tag quietly loads a script in the background while the user is reading (done properly, this can be imperceptible). Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load. That's not usually the reality but it's definitely possible.
- debaserab2 10y agoHow is that faster than loading a single HTML template with the "dom" already rendered correctly by the server?
- learc83 10y agoI think you missed this part >Then when the user clicks a link, JS handles it and instantly updates the DOM and location bar, faster than would be possible with a static page load. In the GP's example, the first page load is already rendered by the server. It's subsequent page loads that are rendered in JS.
- debaserab2 10y ago..so you want to preload the content of every link on the page? Because if it's just to display comments or something, I stand by my original statement.
- callumlocke 10y agoThat's a big revision of your original comment ;)
- nuggien 10y agoSpeeds up subsequent pages accessed at least.
- chrisrhoden 10y agoThe related articles and comments are not rendered until after the page is readable. If they had to be rendered on the server, it would cause the article to take longer to be readable.
- debaserab2 10y agoThere's a lot of different caching and persisting strategies you could put in place to load comments or related articles quickly that don't involve entire HTTP round trips. There's a definite trade-off there (and a not insignificant one, especially on mobile)
- NoGravitas 10y agoNot to mention, HTTP2 mitigates a lot of this, without the downside of huge upfront downloads.
- debaserab2 10y agoYes, sources are packed pretty well, but there's still a lot going on for a blog article: * 10 XHR requests on page load * 3 downloaded fonts * Continuous XHR requests as you scroll through the article * ~400ms time spent executing javascript (according to timeline benchmark) I'm not really sure why all those things need to happen to load some text in a blog article.
- tedunangst 10y agoDoes it stop downloading after that initial 100K? If not, then I think the original claim is a reasonable description. Reading one sentence will cause one megabyte of data to be transferred.