Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Will serving real HTML content make a website faster?

blog.webpagetest.org

Post reply on HN
Print view View original

51–60 of 109 posts

Re: Will serving real HTML content make a website faster?

#51

Post by acdha »

epolanski wrote: post #19
vxNsr wrote: post #4

This basically just tells us what we already know, SSR is faster for the client usually

I don't think it necessarily is. You do get better LCP and FCP but other metrics suffer (time to interactive, TTFB and several other metrics are primary examples). It's a compromise, and hydration is a huge performance hit. (I work on performance of a SSR ecommerce)

> other metrics suffer (time to interactive, TTFB and several other metrics are primary examples).

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.

Re: Will serving real HTML content make a website faster?

#52

Post by kyle-rb »

acdha wrote: post #46
kyle-rb wrote: post #44

These types of tests tend to be unfair to actual web apps, since they only really account for first-time-use. 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 rende…

Note that WebPageTest supports repeat tests for exactly this reason - that closes the browser and restarts it without clearing the cache. Here’s what that looks like - it helps the first render a lot (0.5 vs 1s) but the largest paint is still 7s: better than 11 but still pretty slow. https://www.webpagetest.org/result/220921_BiDcBJ_GQX/ One big thing to remember is that browser caching only works if you aren’t shippi…

Browser caching is nicer with service workers - you can use the cached version and load/install the updated version in the background, so that the user can get the updated version on their next refresh.

Re: Will serving real HTML content make a website faster?

#53

Post by est31 »

jen729w wrote: post #14
kmeisthax wrote: post #9

I remember when single-page applications were all the rage. I was highly skeptical that they could beat just loading HTML, given that the performance benefits were all predicated upon amortizing the initial load cost over many page requests. It's a very risky bet given that a lot of sites don't have a lot of repeat traffic to begin with, unless you just so happen to be an application in the guise of a website. Appare…

As usual, it depends. 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 bette…

The amount of JS to download and parse is only one component that makes SPAs slow. SPAs often have to do another request to fetch json. Depending on how far away you are from the web server, and some users are literally on the other end of the world, this latency can be really large. You don't just want to minimize the javascript you also want to minimize the round trips. But using a small js framework is a good start I think.

Re: Will serving real HTML content make a website faster?

#54

Post by jedberg »

What this doesn't account for is html rendering time on the server.

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.

Re: Will serving real HTML content make a website faster?

#56

Post by jlembeck »

jedberg wrote: post #54

What this doesn't account for is html rendering time on the server. 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 stat…

While it does leave out server rendering time, that could not possibly account for several seconds of difference. TTFB could maybe be increased by 300-500ms… 1/10th of what gains are happening here

Re: Will serving real HTML content make a website faster?

#57

Post by jedberg »

jlembeck wrote: post #56
jedberg wrote: post #54

What this doesn't account for is html rendering time on the server. 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 stat…

While it does leave out server rendering time, that could not possibly account for several seconds of difference. TTFB could maybe be increased by 300-500ms… 1/10th of what gains are happening here

Why do you think the server can render it any faster than your computer? Server CPUs aren't all that much more powerful than desktops these days.

Re: Will serving real HTML content make a website faster?

#58

Post by justsomehnguy »

jedberg wrote: post #54

What this doesn't account for is html rendering time on the server. 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 stat…

Now open Developer Tools and go to www.reddit.com.

Re: Will serving real HTML content make a website faster?

#59

Post by jedberg »

justsomehnguy wrote: post #58
jedberg wrote: post #54

What this doesn't account for is html rendering time on the server. 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 stat…

Now open Developer Tools and go to www.reddit.com.

Having been responsible for reddit personally, I already know what a mess I left behind for them to clean up. :)

Re: Will serving real HTML content make a website faster?

#60

Post by blakehaswell »

jedberg wrote: post #54

What this doesn't account for is html rendering time on the server. 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 stat…

Citation needed. Whether the server is serving HTML or JSON it still needs to serialise the data, so I don't think serialising JSON is going to be significantly faster than serialising HTML. Plus then the client needs to deserialise that JSON before it can render HTML, so all of that work related to (de)serialising JSON is work which doesn't even need to happen if the server is rendering HTML. Not to mention the work on the client to parse and evaluate the JS which needs to happen before it can even start rendering HTML.

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.

Post reply on HN