Will serving real HTML content make a website faster?
blog.webpagetest.org
blog.webpagetest.org
Having myself run this "experiment" for many years now by (a) controlling DNS so that only the domain in the "address bar" URL is resolved^1 and (b) making HTTP requests using a TCP client and/or an unpopular nongraphical web browser that only processes HTML and does not perform auto-loading of resources. No images, JS, CSS, etc.
The answer to the question is yes. This "makes a website faster", or, more specifically, as someone else in the thread has stated, it does not make the website slow. It does not accomodate the practices of "web developers" that slow a website down.
But most importantly, IMO, it makes "website speed", not to mention appearance, more consistent across websites. Good luck achieving any semblance of that with a popular graphical web browser.
Most web pages submitted to HN can be read this way. I find it easier to consume information when it follows a consistent style of presentation and without the distractions enabled by "modern" web browsers.
1. This is the only URL the www user is informed about. In the short history of the www so far, auto-loading from other domains, whether through HTML, Javascript or otherwise, has unfortnuately been abused to the point where allowing it produces more risk-taking for the www "user" than convenience for the www "developer". Sadly, instead of deprecating the "web development" practices that have been abused and make websites slow, the new HTTP standards proposed by an advertising company and supported by CDNs cater to this practice of "composite" websites comprised of resources from various third parties. It stands to reason that advertisers and therefore "tech" companies and their providers, e.g., CDNs, stand to benefit more from "composite" websites than www users do. IMHO the easiest way to "make websites faster" is to stop enabling "web developers" to do the things that make them slow.
It's been said countless times; but Slack, Discord, Youtube, Google Meets, Figma, Google Maps, Google Docs, Github, Excalidraw, Penpot, Diagrams.net etc. etc. are all web sites. They are a different class of websites than Hacker News or Project Gutenberg, being more apps than documents, but they are an important class, too; and they were all made possible because web developers were enabled, through various browser apis, to build them; and I am grateful for that. Wishing that web developers were not enabled to build complex things on the web is inconceivable to me. It's the culture and the education around web development that should change; not the enablement of web developers.
Is “web application” not a common term anymore? Haven’t we always made the distinction between web apps and web sites?
yeah as one those developers who jumped on the processing everything on the client/browser side, and supported all the browser having fancy JS features when ajax first popularised by gmail, I have come to regretted my decision. Especially with all the standards proposed by an advertising companies, the user/consumers don't really benefit from the usage of the web.
I've come to rely a lot on gitlab and github's web interfaces through the years for diff and quickly navigate a specific commit, or a project I don't want to checkout. All the improvements coming from more JS and Ajax have been a boon to me. Sure I could do everything locally, but it's just so much more convenient.
Same for gmail as you mention it: I wouldn't go back to the previous web mail interfaces short of getting paid a living salary just for that. Same for banking web sites, which came such a long way.
The technology and trend is a net plus, advertising company coming to ruin whatever they can ruin is par for the course. I mean, looking at newspaper, TVs, Google Search, YouTube, Instagram, AppStore search etc....making anything it touches worse is in the ad business' DNA.
For commercial use of the www of course I am forced use a popular graphical web browser like everyone else. But I make minimal commercial use of the www. Most www use for me is academic or recrerational.
Apparently my skepticism has been validated.
I just tested my own site, which I built using Gatsby — a JS framework — and https://astro.build, whose entire schtick is that they deliver as little JS to the page as possible.
(Because I’m thinking of rebuilding my site using Astro. But that’s not relevant here.)
In the default test, my page loaded in 1.6s and Astro in 1.9s. In the ‘not bad’ ratings below the main figures, my site fared better.
Now that my page is loaded, Gatsby does some neat pre-loading on hover of links. So clicking around my site is literally instantaneous. The same is not true of Astro, where every click is a classic HTTP request.
I am not judging Astro. That’s not the point of this post. I’m no Gatsby fanboy, I think it’s horribly over-complicated. I’m just saying. It’s complicated.
it's a common misconception that SSR implies no XHR at all. That's never been true except prior to IE5 adding the technique for outlook.
*Except with touch-based interfaces. Which are the majority of browsers today.
This is the almost fully left as a pure document with low interactivity.
Applications are much harder to cache and start up fast.
If I shipped a git repo viewer as an executable, nobody would be asking why it's not rather a txt/doc/PDF. It's unquestionably an application, not a document.
It takes about 4s to load and does 2 or 3 jarring text reflows, I guess as fonts load or something.
It's also unreadable. Incredibly tiny text that would exhaust my eyes to parse within a few minutes.
And besides that... It's just text. Displaying text is easy. I'm sure this would be close to instant whatever framework you used, as long as it was coded well.
notice how all these "benefits" only benefit the developer at the expense of the user or have nothing to do with the problem at hand. "personalized content"? really?
Pre client side Youtube,Twitter,FB,Reddit were all superior feats of engineering to their modern JS heavy counterparts.
Twitter is slow in this experiment because it has to load a bunch of JavaScript up front. But that's not the case in practical use! Twitter uses service workers and HTTP cache headers (e.g. `expires`) to make sure that most non-first-time-users aren't actually loading most things every time. Client-side rendering isn't the thing that's slow here, it's mostly the re-downloading of the rendering code every time when that's not realistic.
https://www.webpagetest.org/result/220921_BiDcBJ_GQX/
One big thing to remember is that browser caching only works if you aren’t shipping updates frequently (bundlers have been an anti-pattern for many sites for the last few years) and aren’t storing too much. On mobile in particular a lot of sites load enough junk that they fall out of the cache. I use Twitter only via their web app and the page load time on a fast iPhone is still like 10 seconds or worse, when a well-optimized HTML page can be in the hundred of milliseconds.
Not everyone has the resources to support that level of investment and there’s a pitfall in the middle where you get the costs but don’t see the desired benefits.
Other sites in the article fit a traditional website model where folks commonly land on pages from search results, but they're still very JS dependent for content. CNN and FedEx etc
Twitter is the slowest website I come back to after Reddit. It's a hot mess and the fully loaded web app isn't any faster. Yes, the megabytes of content being loaded for rendering 280 characters aren't indicative of web app performance, but clicking through to the main app is still slow and unreliable. My old phone used to get hot from the Twitter web app for no real good reason. There's less than a kilobyte of content in a tweet yet I have constant issues with getting all images to load when they come into view or scrolling back up without having the content jump around because some recommendations block decided it exists again now.
Getting faster devices solved Twitter's problems for me for a while but it's still ridiculous if you open Nitter and compare the performance. It's a clear example of what's wrong with modern web development because the "traditional" design of Nitter does everything I want it to do and 90% of what most people want it to do (needs tweets, DMs to become interactive) at a fraction of the load time.
Plain Jane HTML is going to save us.
It's always 4G, mobile Chrome and I assume the same device.
Very likely same carrier at the same place, so roughly same connection conditions in terms of latency DL/UL bandwidth and jitter. Also always the same device with same CPU/GPU. Perhaps a flagship new shiny phone with a superfast SoC which gives a headstart to faster JS execution? Or perhaps a very spotty barely 1-bar 4G connection. (Just assumptions, maybe both are false, but you get the idea)
I'm a bit fan of client-side generation using JS too but I don't think this experiment is exhaustive of many practical scenarios.
If we see more connection types and more variety of devices with different CPUs then it'd be more convincing.
A news article or tweet takes way too long to load on my phone, it's just ludicrous that on a mid-range phone and connection it would take 45 seconds! A copy of Frankenstein[0] (~78k words) weighs in at 463KB. A random CNN article or tweet is not a damn copy of Frankenstein. There's no reason either should take more than a second to load and render.
An HTML document with a bare minimum CSS to not be ugly has enough information to render and be useful to a user. It can do that with a single request to a server. At minimum the same page rendered with JavaScript needs two connections to a server. It's also got a higher minimum threshold for displaying something to the user because the JavaScript needs to be downloaded, parsed, interpreted/JIT, then requests for useful resources made. All to do things a browser will already do for free.
There's full JavaScript applications that can't be built with just HTML and CSS. Of course they need to load and run the JavaScript. A tweet or news article are not applications. They do not need to load the equivalent of copies of Doom to display a dozen paragraphs of text or just 140 characters of text. The modern web's obsession with JavaScript everywhere is asinine.
More testing environments would make the results more or less significant, as you'd expect.
In ideal browsing conditions, the impact will be more minor, and in the spotty barely 1-bar connection you mention, the difference would be much more dramatic than the 4G examples in the post.
What if instead of client side load time, what's also being looked at is load time per finite server side compute resource? By dumbing down the server side to graphql JSON delivery + static JS, maybe that allows them to serve that specific need faster per 10k servers or something, and having to do the full page composition under heavy load server side just doesn't scale as well?
They'll keep doing it until they're penalized in some fashion for doing so, if it's cheaper.
It's a compromise, and hydration is a huge performance hit. (I work on performance of a SSR ecommerce)
"Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the content server-side and showing it to the user first, then adding on the bells and whistles after that, is how you do that.
Not necessarily. If you "load" the page but it doesn't do what it should when I click on it, that can be much more frustrating to the human than taking a little longer to load but being fully functional when you do. The assumption that anything that isn't HTML is "bells and whistles" is pretty dubious (as is the converse assumption that everything in the HTML is valuable).
Sure, but a) the purpose is rarely just to show content, one of the great strengths of the web is interactivity. b) often a lot of what's in the HTML (and especially the CSS) isn't the content the human wants to see.
They matter for SEO.
> "Time to human satisfaction" should be a number that front-end developers measure and aim to improve.
Satisfaction varies. TTI is a relevant metric. E.g. On our ecommerce it takes less than 10 seconds to load the entire page (sub 5 for most pages), but then the user can literally do nothing till all hydration has happened and executed which is simply not a great experience.
Our users, if using the website through slower connections/devices are looking at 40 seconds + delays before they can do anything meaningful, that's unacceptable.
I can't tell if you're gloating about this or agreeing that these numbers are unacceptable.
Let's say it's a product page. You should be able to have the product title, description, and images (in the sense of <img> tags) load with the page instantly. If you need to do dynamic stuff like have a T-shirt size and color picker which changes what options are available based on stock or something like that, that functionality can be added to the page after the initial load, but nothing that doesn't have to be dynamic should be dynamic.
Do you disagree with this?
This is only true for a fraction of sites - the ones I work on are content heavy and use progressive enhancement so TTFB is how long it takes a CDN cache hit to transfer, and since you’re using so much less JavaScript in the critical path they’re less affected by network latency and device performance. Obviously that hits a different trade off than an app which has to have dynamic functionality to meaningfully load and lots of user-specific features are going to lower cache effectiveness.
As always, you get what you measure: pick metrics which matter for your business and get as much as possible get your data from real users so you don’t waste time chasing something people don’t care about. It’s too easy to focus on, say, making your search page as fast as you can when you should be asking whether you have what they’re looking for and surfacing it for them.
PS: thank you for calling HTML HTML!
Even with that 1-second additional delay included though, the improvement in that first test is still large (over 8 seconds faster in those tests). If the experiment took a few seconds longer on the server, it still would be 5 or 6 seconds faster to render content than the control.
You don't need to make your website fast, all you have to do is not make it slow in the first place.
Partially or fully generating a web site client side can be plenty fast, the slowness tends to come from using some bloated framework to do so.
Gotta be honest, I’m grimacing already. An order of magnitude too much.
IMO a few hundred milliseconds for something that is actually webapp-like rather than just an information website is quite reasonable.
We have different experiences. HN is light but it's not fast.
Either way, the post isn't saying you have to abandon app-like experiences. It's only about improving initial HTML delivery regardless of what you do after that.
This is just realigning what many of us already knew, SSR is faster.
If I may, the argument of "well... sure, but CSR can be plenty fast!" is redrawing the line after someone stepped over it.
This requires testing. Which is, apparently, something most companies don't know how to do correctly.
You absolutely do, even setting aside UX and accessibility benefits, there's a huge impact in SEO as web core vitals impact seo a lot.
If you are in a niche business or have no competition, then this argument is weaker of course and you're left with the previous 2.
In my view, the dom should be made obsolete, and there should be tighter restrictions, by making things immutable, or just completely redesigning how the dom works.
I'm not an expert, but the dom smells very weird.
You could probably speed up pages significantly by introducing deferred rendering to the DOM, but: backwards incompatible change.
(That was my answer about hydration that you didn't like)
Why stop at the dom? Why not the protocol too?
The reason websites use local javascript to render html is so they don't have to do it on their server while you have to wait for the result. This way you have the perception of a page load while the html renders. It's actually a better experience for the user.
This entire analysis assumes that the server renders the html instantly. Unless it is static content that is highly cacheable, chances are the render time on your machine isn't much slower than the server, but the website can use a lot less compute resource to make the webpage for you since your computer is doing part of the work.
Also, chances are they have to transmit less data to you, which cuts down on network latency as well.
As for data across the wire, GZIP is a thing so again I would want to see real world performance numbers to back your claims.
So the benefits of server side generation is no need to deserialize the code that generates the page and locality to the data. I'm guessing these two things are the biggest contributors to the speed ups.
I guess "server side rendering" is a bit of a misnomer, since you're not getting a rendered image, but rather a functional web page. It's possible I've misunderstood the whole SPA vs server side rendering arguments as well and my entire argument is invalid ¯\_(ツ)_/¯
Lots(most?)of server side apps are python, ruby, php or javascript.
Also this is if you check professionals. It's pretty similar for all respondents, but Flask and Django rise above spring and ASP.NET, although ASP.NET Core is still above those.
https://insights.stackoverflow.com/survey/2021#section-most-...
But most of the desktops, notebooks, phones and tablets doesn't have 3GHz, 50Mb L2 processors coupled with Gb/Tbs of RAM and local (compared to the client requesting the page) storage.