Live data from Hacker News

A 14kb page can load much faster than a 15kb page

endtimes.dev

281–290 of 356 posts

Re: A 14kb page can load much faster than a 15kb page

#281
post #95

I wonder if anyone has studied the impact of latency on user behavior while considering the impact of user expectations from their typical connection speed. Whenever I see an article about page speed optimization, the assumption is that a user will give up if a page takes too long to load, ans that everyone gives up after X seconds. Usually X is about 7s based on a Nielson article from years and years ago. The thing…

I don’t have a citation handy, but this is something that Google has famously studied. They claimed years ago that a tiny increase in the loading time of the Google home page led to a measurable decrease in the number of searches (like, a few percent). Not everyone is operating “at Google scale”, of course, but in aggregate the effect is real and faster-loading pages have better metrics. So, most satellite internet u…

We ran some A/B tests where we intentionally slowed our site down (at the webserver page generation level) by set percentages (0%, 10%, 25%, and 33% IIRC). Those would be against a baseline page generation time of around 2000ms, so the slowdowns were not small.

All tests showed a drop in traffic, conversion, and average session value indistinguishable from zero. Our hypothesis is that our site (where a converting visitor is on average designing and ordering a custom product) is one where the difference between 30 minutes and 31 minutes is not meaningful and a lot of the time is spent in the web-based document editor. It would not generalize to a "give me a quick search result", "sell me an item from a warehouse shelf", or "let me argue with someone on a forum".

This was of course disappointing, because we ran this test as a sanity check after having done an extensive project to improve the page speed across the main conversion funnel. The project was technically successful, but a business zero (probably for the same hypothesis as above), so we decided to test in the other direction, because that's easier to implement than to force faster pages.

Re: A 14kb page can load much faster than a 15kb page

#282
post #277

Earlier quoted context omitted.

Easier in what sense? If you find the most esoteric feature and then claim it's easier for that purpose, that doesn't count! If you're going to claim it's easier to configure than nginx you have to make a fair comparison by comparing not the features that you care about, but instead the features that define the system as a whole.

I would think automatic support for TLS, no configuration necessary, would qualify?

You mean?

  certbot --nginx

Re: A 14kb page can load much faster than a 15kb page

#283

Earlier quoted context omitted.

Yeah, it's just waiting on the server for most of that time in the first screenshot. Static (or cached) sites are going to be a lot faster than sites that have to re-render things every time.

endtimes.dev is on netlify I believe and a static site, correct ?

Oh, maybe. I don't know. I'm just saying the waterfall is green, so it's waiting on the server most of the time, and I'm not sure why else that would be other than location.

Trying it myself, I can't reproduce that though. The first takes 40ms to connect to the server and 3ms downloading the page. The second take 40ms to connect, 40ms downloading the HTML, and then another 2000–3000ms downloading all the other assets.

Re: A 14kb page can load much faster than a 15kb page

#284
post #228

Are there any reason why we cant have TCP slow start initial window to 100 packets or higher? I could easily see 95% of internet could be 150KB page on first load.

wouldn't the default mtu of 1500 bytes in most routers negate that? Maybe things have changes since hte last time i thought about mtu but at one time it was 1500 bytes.

Re: A 14kb page can load much faster than a 15kb page

#285

Earlier quoted context omitted.

1MB per photo is fine. It's the content after all. Many sites today will load 10MB of JS and custom font crap alone, just to show a few paragraphs of text. I don't think the point is the size itself, but it's the content vs. bloat ratio.

Omg just disabling custom fonts in Firefox speeds up the internet so much!

After reading this fine tip, I did the same thing. Thank-you for the suggestion.

For others wondering how:

about:config

gfx.downloadable_fonts.enabled (set to to FALSE)

Re: A 14kb page can load much faster than a 15kb page

#286

That's only doable with a text-centric website. I'm currently finishing a photography section for my personal website, and the gallery pages are several hundred kBs in size, while single photo page is almost 1MB in size (provided you load it on a 28" screen; browser will load smaller variants on smaller screens). Most of that weight is the thumbnails (and almost-full-size photo in the latter case). The only JS I have…

>the gallery pages are several hundred kBs in size The HTML itself is several hundred kB? Something’s very wrong there…

No, the whole page, i.e. HTML + CSS + photo thumbnails etc. It's dominated 90+% by the photo thumbnails, which is expected.

Re: A 14kb page can load much faster than a 15kb page

#287
post #282

Earlier quoted context omitted.

I would think automatic support for TLS, no configuration necessary, would qualify?

You mean? certbot --nginx

You are missing the steps to install, setup, cronjob, for certbot.

What about HTTP->HTTPS redirection, etc?

Same for secure cipher selection.

All of that Caddy gives you in 1 line of config (i.e. domain name)

Re: A 14kb page can load much faster than a 15kb page

#288

Earlier quoted context omitted.

Omg just disabling custom fonts in Firefox speeds up the internet so much!

how do you disable fonts? Plugins?

about:config gfx.downloadable_fonts.enabled (set to false)

Re: A 14kb page can load much faster than a 15kb page

#289

Is the post joke? Are there any network technical who can explain that the packet can have different size and modified by different routers inside chain of path from source to destination? I mean some kind of absurd topic. And everyone instead of reading ethernet standard and teaching materials about this OSI level, start to debate about this thing.

https://www.cloudflare.com/learning/network-layer/what-is-mt...

if you had a router between you and the webserver you're accessing and it's MTU is 100 bytes then the largest packet getting through it is 100 bytes. The router will break larger packets into max 100 byte packets and send them through.

"This process is called fragmentation. Fragmented packets are reassembled once they reach their destination."

The default MTU for routers is 1500 bytes which is probably the 14-15kb limit was picked.

/it's been 20 years since i was really into networks so maybe things have changed with the default MTU...

Re: A 14kb page can load much faster than a 15kb page

#290
post #243

Earlier quoted context omitted.

Folks, b is bits, B is bytes. For someone who deals with IT/telecomm the careless use of bits, bytes, B, b, kB/s, kb/s, kbps, MiB/s, Gbit is a source of confusion, because all those abbreviations have a very specific and distinct meaning. And whenever someone writes something not very obvious (eg Gbit for line speed, or kb for a size of a file or network transfer chunk), I need to figure out if they don't understand…

I think this case-sensitive byte/bit distinction was always a bad idea, and what you're experiencing is the consequence of a bad idea, not stupid people. For example sometimes MESSAGES ARE WRITTEN IN ALL CAPS. Now what does your B mean? Just write b for byte and bit for bit and there's no ambiguity.

Good idea, if indeed everyone would do that.

As it is, you're introducing a competing standard where lowercase b suddenly has a new meaning, making it incompatible with everything that was already written correctly in the past. Maybe it's a better system in the end, but is it worth breaking compatibility and trying to convince millions of people in the industry of a new better standard?

Post reply on HN