Read on Twitter
Earlier this week, I wrote about how you should always bet on HTML.
Today, I wanted to break down just how dramatically more performant than JS HTML can be. A thread... https://gomakethings.com/always-bet-on-html/">https://gomakethings.com/always-be...
Today, I wanted to break down just how dramatically more performant than JS HTML can be. A thread... https://gomakethings.com/always-bet-on-html/">https://gomakethings.com/always-be...
My JS students access their purchases (books, streaming videos, etc.) on a login-required learning site I have set up.
It& #39;s a multi-page app that fetches their purchases from an API, caches them in storage between page loads, and renders the HTML with JS. 2/n
It& #39;s a multi-page app that fetches their purchases from an API, caches them in storage between page loads, and renders the HTML with JS. 2/n
I& #39;m currently working on a rebuild of the whole thing that serves up pre-rendered HTML files (as long as the current user is logged in and has access to the content).
So, SSR HTML, but the HTML is created before a user ever visits the site. 3/n
So, SSR HTML, but the HTML is created before a user ever visits the site. 3/n
Under good browsing condition—modern browser, newer device, solid internet connection—the current JS-driven site and the new SSR one perform equally as well.
I& #39;ve done a lot to optimize loading of the JS site.
But when you slow the network down... wow, things change! 4/n
I& #39;ve done a lot to optimize loading of the JS site.
But when you slow the network down... wow, things change! 4/n
When I throttle performance, deliberately slowing the network down to slow 3g speeds, the new HTML version shows up, fully rendered, in < 3s.
The current JS-driven site? That takes over 25 seconds to finish rendering.
Twenty. Five. SECONDS! On the web, that& #39;s an eternity! 5/n
The current JS-driven site? That takes over 25 seconds to finish rendering.
Twenty. Five. SECONDS! On the web, that& #39;s an eternity! 5/n
