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

101–109 of 109 posts

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

#101

Post by Cyberdog »

epolanski wrote: post #83
Cyberdog wrote: post #31

Earlier quoted context omitted.

"Time to interactive" and "time to first byte" are pointless numbers if the purpose of your site is to display content (Reddit, Twitter, pretty much everything else). If I (resentfully) click on a Reddit link on a SERP, I'm going there to read the content, not to flip open menus or whatever. "Time to human satisfaction" should be a number that front-end developers measure and aim to improve. Just rendering the conten…

> "Time to interactive" and "time to first byte" are pointless numbers if the purpose of your site 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 a…

> 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.

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 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?

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

#102

Post by pvillano »

morelisp wrote: post #93
pragmatic wrote: post #40

Earlier quoted context omitted.

Imagine a spectrum from document to application (from left to right). This is the almost fully left as a pure document with low interactivity. Applications are much harder to cache and start up fast.

How far we've come that near-real-time multidimensional dynamic views onto multi-GB data stores is considered 'a pure document' by someone. Why, just because it uses links and URLs and instead of buttons and fetch?

Yes, in the current context of the need for client side rendering.

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

#103

Post by morelisp »

pvillano wrote: post #102
morelisp wrote: post #93

Earlier quoted context omitted.

How far we've come that near-real-time multidimensional dynamic views onto multi-GB data stores is considered 'a pure document' by someone. Why, just because it uses links and URLs and instead of buttons and fetch?

Yes, in the current context of the need for client side rendering.

No, you've assumed the question. "Applications are much harder to cache and start up fast" because you're defining "applications" to intentionally exclude architectures which are cachable and fast to start.

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.

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

#105

Post by IYasha »

chmod775 wrote: post #55

There needs to be a website hall of shame that serves particularly slow websites rendered into PNGs/WEBP/WEBMs (+JS code to make them interactive/clickable) if those would load faster and use less data volume than the real thing.

That would be Alexa's top 100 I presume )

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

#106

Post by IYasha »

NohatCoder wrote: post #90
imachine1980_ wrote: post #34

Earlier quoted context omitted.

or loading everithing instead of lazy loding the images or use 3mb image instead of kb webp

You have to be careful with the lazy loading, sometimes it ends up being just more round trips. And then there are those annoying sites that refuse to load anything that is off screen, and you end up having to wait over and over again.

Those are the cursed sites! Not only you have to wait for content you want, but you always get content you DON'T want just when you're about to finish your reading. Then - BAM! - page starts lagging, twitching, spitting out another megabytes worth article you didn't ask for.

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

#107

Post by throwaway742 »

1vuio0pswjnm7 wrote: post #86
throwaway742 wrote: post #76

Earlier quoted context omitted.

What browser do you use?

For reading HTML, I use various versions of links 1.x and links 2.x, patched to meet personal preferences. Of course links can make HTTP requests, as well as display HTML, but I use a variety of programs to make HTTP requests. When I use links to make HTTP requests, it is always through a loopback-bound proxy. For commercial use of the www of course I am forced use a popular graphical web browser like everyone else.…

I had campus security called on me because I was using an acoustic coupler on a payphone to a free dial-up provider to browse the internet via links. Luckily the security guard understood what I was talking about and was chill, but he couldn't understand why I wasn't just using the campus WiFi.

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

#108

Post by Self-Perfection »

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…

That is way alternative frontends for bloated websites exist. For instance, one can read twitter via nitter, which uses zero JavaScript. Check how fast it loads: https://nitter.privacy.com.de/SpaceX/status/1571950786896330...

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

#109

Post by lowwave »

makeitdouble wrote: post #66
lowwave wrote: post #37

Earlier quoted context omitted.

> IMHO the easiest way to "make websites faster" is to stop enabling "web developers" to do the things that make them slow. 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 compani…

I see it as a rare case of "hate the players not the game" 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…

For sure, I agree that the ajax UI/UX offered by gmail is a game changer. And all those features that makes it convenient for users, can be accomplished without compromising security/privacy. What I don't like are companies proposing standard disguising as a some convenient feature, where in reality is just a racket to mine data from the users.
Post reply on HN