22 ms·

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

• spoonjim 4y ago
  One of my favorite stats is that a VisiCalc screenshot is larger than the VisiCalc executable.
• pvinis 4y ago
  Interesting poat, but what I really liked is the layout, font, bottom tags section, link to dev.to, etc. Very cool!
• xwdv 4y ago
  Does this mean your website should also only use HTTP for maximum speed.
  • 18amxn18 4y ago
  • immibis 4y ago
    I guess so. The OP replied and said yes, but he's banned for being an anti-semite and a COVID minimizer, so I'll say it again for those who have dead comments hidden. It's a shame that you can't have both speed and security. One possibility is to have a subdomain, insecure.blah.com, that doesn't redirect to HTTPS by default.
    • xwdv 4y ago
      For a static site HTTPS is wholly unnecessary.
      • immibis 4y ago
        Correction: for a static site HTTPS is less useful. It's not like having a <form> magically attracts the hacker known as 4chan. For each case you would have to consider what can happen with and without HTTPS. Cat pictures: probably fine either way; the worst someone will do is inject bitcoin-mining javascript; or they may inject phishing, or porn and ruin your site's reputation. Actually this can even be useful sometimes as some ISPs may inject "we are having an outage" or "please remember to pay your bill". Hacker News is a dynamic site with about the same characteristics. Now imagine you are Wikileaks. Static, yes. Encryption required? You tell me. Worse: The onion address and bitcoin donation link were replaced with ones pointing to the NSA. Worse: The NSA can see who's accessing what, instead of just who's accessing. Actually, an attacker can use your cat picture preferences to build up a profile of you, and perhaps identify you on different networks.
    • 18amxn18 4y ago
• est31 4y ago
  > Most web servers TCP slow start algorithm starts by sending 10 TCP packets. Of course big names that run CDNs have fancy custom stuff that directly puts data into mmaped regions for the network card to use, but generally, it's the OS handling TCP connections, and this means that the web server, a user space process, only interacts with the TCP connection through a streaming API. It can't issue individual TCP packets or ACK packets or anything. Raw socket access requires superuser privileges in unix. Outside of that it's a great article. Didn't know about this particular trick :).
  • Retr0id 4y ago
    "web server" can refer to the whole box, as opposed to the userspace software in particular, so it's not wrong per-se.
  • unmole 4y ago
    The statement makes sense if you take web server to mean a logical unit including the underlying kernel.
• agraddy 4y ago
  This is a really great breakdown of the TCP slow start algorithm. I always try to keep sites as lean as possible, but this was an aspect of TCP that I wasn't familiar with but will definitely be keeping it in mind in the future.
• indigodaddy 4y ago
  Is the dev.to version of this article under 14k I wonder?
  • indigodaddy 4y ago
    Nope 803k https://tools.pingdom.com/#60b4b3d98d400000 https://tools.pingdom.com/#60b4b3d98d400000
  • DitheringIdiot 4y ago
    Definitely not — i've added a warning to the article.
• Yhippa 4y ago
  I'm getting 62 bytes over the network and 31.4 kilobytes uncompressed. This page has more content than most pages I visit that are megabytes in size. I wish there was an incentive to go back to smaller web pages in general.
  • tyingq 4y ago
    62 bytes is surely not right :) I see your 31.4kb uncompressed, but 9.6kb over the wire.
    • spcebar 4y ago
      This comment is 62 bytes and I haven't said anything of value.
      • lionkor 4y ago
        compressed (100% compression ratio): ""
    • jagrsw 4y ago
      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 the terms they use, and I should use the more likely meaning, or they know what they're talking about and I assume they really meant what they'd written.
      • okasaki 4y ago
        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.
• chinabot 4y ago
  Wow a web page that appeared the second I pressed the link, I guess he practices what he preaches.
  • doliveira 4y ago
    Yes, it's sad how we've come to get impressed by this
    • MrDunham 4y ago
      Sadly it’s likely to only get worse. Google‘s new "helpful content" updates have the SEO world in a frenetic search for unique images, videos, etc. to stuff into articles. If I remember right Google even states that it prefers to see those in content and articles… Further exacerbating the challenge of creating helpful content that loads quickly if you ever want it to get seen
      • exodust 4y ago
        I had to look up what you meant and found Google's blog post: https://developers.google.com/search/blog/2022/08/helpful-content-update https://developers.google.com/search/blog/2022/08/helpful-co... Good to hear. But whether Google can achieve it is another thing. Quotes I like: "content created primarily for search engine traffic is strongly correlated with content that searchers find unsatisfying." No shit! I hope some of the websites I've worked on get signaled up the rear end! I've warned site owners not to use too much SEO content, but the forces of copy-cat SEO tactics are stronger than individual developer advice. "Are you writing to a particular word count because you've heard or read that Google has a preferred word count? (No, we don't)." I wish Google had been more plain speaking in the past about this. Better late than never I suppose.
  • scottmf 4y ago
    I just went to theguardian.com and it opened immediately. This kilobyte fetishism on here is ridiculous.
    • 4y ago
• fragmede 4y ago
  FWIW, the HN frontpage is 33kB. It's one of the better performing websites I frequent.
  • calibas 4y ago
    It's only 8kB compressed.
    • ThreePinkApples 4y ago
      A fresh load of the page (according to Chrome) is 21.5kB transmitted, 59.1kB uncompressed. That's when loading with nothing cached. The HTML is just 7.9kB, but then the CSS is 2.2kB, JS is 2.3kB, and the favicon is 7.9kB which is a bit funny (but it's of course irrelevant for the actual page). HN could put the CSS and JS into the generated HTML file and still stay under 14kB for the initial load, which then would give you almost everything needed to render the page except a few gifs.
      • bawolff 4y ago
        Favivon isn't blocking the initial request so it really shouldn't matter. > HN could put the CSS and JS into the generated HTML file and still stay under 14kB At the expense of caching those resources that stay static. With http/2 the benefit of merging into one resource should be negligible anyways.
        • SahAssar 4y ago
          > With http/2 the benefit of merging into one resource should be negligible anyways. That's not true, by including them in the HTML you save an extra round trip for requesting them. That's what HTTP2 Push was supposed to solve, but it's being deprecated & removed.
          • bawolff 4y ago
            That's a fair point.
• smarkov 4y ago
  Honestly, "should" is a bit of a click-baity exaggeration. In this day and age where internet speeds are faster and more stable than ever, these kinds of tips should be at the very bottom of your optimisations checklist. I don't care if your website takes 3 seconds to load or 5, what I do care about is that once the website has loaded, my inputs respond as quickly as possible. Reddit for example is total garbage when it comes to responsiveness, clicking on a post literally freezes the page for 1+ seconds on a fairly capable PC.
  • brailsafe 4y ago
    Well, the primary utility is different, and they have memory leaks throughout, but conceptually it's still the website loading slowly.
  • notriddle 4y ago
    Bandwidth is getting better more quickly than latency is. TCP slow start requires a round trip to speed up, and if you want that to improve, you need to reduce latency. Increasing bandwidth won’t help.
  • spcebar 4y ago
    Yes, but you should also be mindful that if your site is being viewed by an international audience. A 3 second load time on an average local internet connection can be a minute long load time elsewhere in the world.
    • markdown 4y ago
      .. or on a train in a tunnel in your very own city.
  • worldofmatthew 4y ago
    Mobile data is very inconsistent when in rural areas. The best speed I got in an urban areas was around 800Mbit/s but I have seen speeds in some rural areas closer to 1Mbit/s to 3Mbit/s. That is in the UK, not a 3rd world country.
• CodeIsTheEnd 4y ago
  Shameless self-promotion: the homepage of plaintextsports.com is 5.2kb today [1], an in-progress WNBA game (4th quarter) is 11.2kb [2], and an extra inning MLB game is 8.8kb [3]. I wasn't aware of this size threshold, and I'm not at this level of optimization, but I'm always pleased to find more evidence of my playful claim that it's the "fastest website in the history of the internet". [1]: https://plaintextsports.com/all/2022-08-24/ https://plaintextsports.com/all/2022-08-24/ [2]: https://plaintextsports.com/wnba/2022-08-24/conn-dal https://plaintextsports.com/wnba/2022-08-24/conn-dal [3]: https://plaintextsports.com/mlb/2022-08-24/laa-tb https://plaintextsports.com/mlb/2022-08-24/laa-tb
  • smt88 4y ago
    It's very small, but it's difficult to scan and painful to read. You could easily use built-in HTML structures to make it actually readable. Your site is, in my opinion, as much a deviation from the old readable web as the over-designed modern sites are. There are lots[1] of small, "class-less" CSS libraries that would keep your site as small (or smaller, with tree-shaking in a modern build system) and it would end up much more user-friendly. 1. https://css-tricks.com/no-class-css-frameworks/ https://css-tricks.com/no-class-css-frameworks/
    • conductr 4y ago
      The Light Mode toggle pretty much fixed it for me. Dark Mode on this was harsh and difficult to scan/read
      • YLE118 4y ago
        I found it easy to read on my phone in light mode, still easy to skim in dark mode but the losing team text is too dark and I have to focus to read it.
    • bee_rider 4y ago
      It looks like it is designed to be a sidebar.
    • 4y ago
• csnover 4y ago
  > There is an idea that the 14kb rule no longer holds true when using HTTP/2. I've read all I can about this without boring myself to death — but I haven't seen any evidence that servers using HTTP/2 have stopped using TCP slow start beginning with 10 packets. HTTP/3 formally replaces TCP with QUIC.[0] Google have been using QUIC in production for quite a while (since 2013!) and it’s enabled by default in every browser except Safari[1] so it’s understandable how there could be some confusion here. [0] https://datatracker.ietf.org/doc/html/rfc9114 https://datatracker.ietf.org/doc/html/rfc9114 [1] https://caniuse.com/http3 https://caniuse.com/http3
  • doliveira 4y ago
    Doesn't QUIC have some version of it? I assume it still needs to implement congestion control on top of UDP EDIT: yep, as posted above: https://news.ycombinator.com/item?id=32588850 https://news.ycombinator.com/item?id=32588850
• strken 4y ago
  The relevant QUIC draft recommends a similar window[0], so HTTP/3 looks like it will behave the same. [0] https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery-26.html#section-b.1-2.2 https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery...
  • skerit 4y ago
    Oh really? Here I thought QUIC would put an end to all this.
    • 3pm 4y ago
      My understanding is that QUIC will not help much if your page is self contained (no references to outside resources). Because this page is the only resource and QUIC is all about parallelizing multiple resources. In regards to congestion control QUIC is very similar to TCP [1]. Basically QUIC avoids a case where your image #2 waits for image #1 (head of line blocking). It loads both images in parallel streams. In classic HTTP, TCP was asked to load image #1, then it was asked to load image #2 and TCP have to provide responses in order. So even if a single TCP segment of image #1 is lost, image #2 will have to wait. Browsers try to open multiple TCP connection to avoid head of line blocking, but there is a limit to that. QUIC also combines TCP and TLS handshakes, so initial latency should be improved somewhat [1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-12#section-2.1 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recove...
• nnx 4y ago
  Is this still valid advice for HTTP/3 based on UDP?
• kikki 4y ago
  Unrelated, but I found reading this post very easy. Something about the colors and font choices worked well for my brain which struggles recently to parse most long-form content..
  • pyjamafish 4y ago
    While the colors and font choices are good, I think the more significant factor here is good organization: there's a logical layout, use of subheadings, and short paragraphs (in this case, very short--many paragraphs are single sentences!).
• GrumpySloth 4y ago
  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 is 6 lines (before minifying) on single photo pages which allow you to go to next or previous photo with keyboard arrows. I don't use any CSS frameworks, just a single hand-written CSS file. I don't have any tracking, analytics, social media features or anything of this sort. So if even a personal site being done with no deadlines, no pressure from management to include analytics etc. can't do it, because it wants to display a bunch of photos, then I don't think we can expect "web-scale" websites to achieve it.
  • hcarvalhoalves 4y ago
    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.
    • worldofmatthew 4y ago
      1MB per photo is massive. Its easy to compress photos down to 100KB or less.
      • NavinF 4y ago
        Wat. 1MB per photo is tiny when the photo is the content. You need ~100KB for a high quality 512x512 WebP. AVIF will be slightly better but still doesn’t have universal support. We’ve had 4K (8MP) screens for a decade now and normal DSLRs shoot 25MP so you can zoom in.
        • worldofmatthew 4y ago
          Bandwidth is extremely carbon intensive. Someone viewing a couple of few 25MP images online could use 20g to 100g of CO2 (depending on compression).
• issung 4y ago
  What CSS does the author use to achieve that "sketchy" effect on the orange headings?
  • csande17 4y ago
    Looks like it's an SVG filter using <feTurbulence> and <feDisplacementMap>, similar to the example on https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feTurbulence#example https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feT...
  • stcont 4y ago
    It’s a filter derived from the first SVG element on the page. Check out the page in the web inspector! Simple websites have the bonus of being easy to poke at.
• julienmarie 4y ago
  It's true but not realistic as soon as the website is more than a blog or a static content website. The goal of good web building is to manage to deliver the most value to consumers and the business, and removing what's not needed, and if you add anything, you make it on a performance oriented way. Bloat will always infiltrates itself, so you must clean again and again. I operate e-commerce websites and we went through multiple iterations with two goals in minds : performance ( speed / core vitals / seo ), and developer productivity (I'm basically the only tech guy, and I'm also the CEO managing 10 people). Our current e-commerce stack runs 99% on Phoenix Live view. As our market is only in 1 country (Philippines) we optimize for round trip network with servers the closest possible ( no decent hosting company in the country so we host in HK at datapacket on a beefy dedicated ). Site loads in less than a second, navigation is nearly immediate thanks to live view. We removed most JS trackers as we built our own server side tracking pipeline in Elixir that sends unified data where it's needed ( it took us like 2 days to build ). Since that move Google loves us and we are the top ranking website for our niche in the country on all our key products. One key thing also is that our target market is wealthy so they enjoy fast data / connection, this helps in terms of determining our target. Performance is not absolute. It's relative to your product, your market and your location.
  • MichaelDickens 4y ago
    Hell, my blog is static HTML (mostly) but my most recent post is 40,000 characters in Markdown before adding HTML tags, that's already too big even just as text.
    • twobitshifter 4y ago
      in the old days, you'd paginate
    • towawy 4y ago
      Have you gziped it? The website of in OP is 30k uncompressed of HTML.
  • lawgimenez 4y ago
    I’m from Philippines I wonder what your e-commerce does. But I agree there is no decent web hosting here.
• wiradikusuma 4y ago
  So 14kb for 1 file? (Index.html) meaning we should ensure that the supporting assets (css, js, images) are set non-blocking so at least people can see the content first?
• gcau 4y ago
  Some kind of actual measurements/tests would be nice, like put up a 14kb and 15kb+ page and measure them to demonstrate the apparent speed difference really exists.
• pkilgore 4y ago
  The athletic.com routinely takes 2-5 seconds to load a page on my mobile phone connected to a 600MBPS down line (when it doesn't 500). I still use it. So, sure, this is awesome but it might not be something worth optimizing for if you want to make money.
• alexmingoia 4y ago
  https://sumi.news https://sumi.news HTML is ~14KB when transferred with compression. The CSS is ~30KB. I could probably slash that in half if I optimized.
  • jandrese 4y ago
    Does the CSS get cached?
    • alexmingoia 4y ago
      Yeah, it's a separate file. But because I'm using tailwindcss, the HTML actually has a huge number of classes. I'm not sure how much that matters with compression though.
  • alexmingoia 4y ago
    I should add that this depends on your subscribed sources. My page is ~13KB today, but it could be up to ~60KB if you have a lot of headlines. Most of the HTML is actually tailwindcss classes repeated for each headline. I wonder how much size I could save by replacing them with a single class-name. I assume it wouldn't make much difference to the compressed size.
• scottmf 4y ago
  There's much more to a fast website than ttfb/fmp on a single page load with a cold cache. The fact this kilobyte fetishism on HN is still so rife in 2022 is ridiculous. Edit: I wrote this after reading some comments. The article is interesting and not an attack on its author.
• coin 4y ago
  What about the headers?
• soperj 4y ago
  This made me check my own site[1], the page itself is tiny(3kb). It's the images that get me, and they're svgs. Gotta be something wrong there too, an svg shouldn't be 75kb. edit: nevermind, svg is 13kb, don't know what I was mistaking there. [0] - www.reciped.io
  • SquareWheel 4y ago
    75% of your download time is jQuery and webfonts. You'll need to review your own code to see if jQuery can be eliminated, but the fonts are probably an easier fix. You're serving them locally which is good, but changing to woff2 would help. Looks like you make a lot of use of the Gibsoni-Italic, so it's probably worth keeping. If it were only here or there, I'd say nix it and rely on font synthesis instead. If you're really dedicated, you could subset them to eliminate glyphs that you're not using on your website. They're pretty large fonts for just latin characters.
    • soperj 4y ago
      > If you're really dedicated, you could subset them to eliminate glyphs that you're not using on your website. They're pretty large fonts for just latin characters. This is really interesting, and would be pretty easy I think. I'll look into this.
      • antifa 4y ago
        I used this to not include an entire copy of font awesome: https://fontello.com/ https://fontello.com/ Though if you're using vue3, I think tailwind or fontawesome will have better methods.
  • jacooper 4y ago
    I think lazy loading should solve it really.
• memorable 4y ago
  My site is not under 14KB (15.17KB of HTML, to be precise), but it loads pretty damn fast and I'm proud of it. https://tsk.bearblog.dev/ https://tsk.bearblog.dev/
• quickthrower2 4y ago
  I wonder... am I good if the static render is < 14kb, but I load React etc. and hydrate for progressive addition of interactivity? Probably for a blog, if the readable content is in that static render, it would be a reasonable experience. A couple of seconds later the cool interactive parts come to life. === PageSpeed Insights scores: Performance: 100% First Contentful Paint: 0.9 s Time to Interactive: 0.9 s Speed Index: 0.9 s Total Blocking Time: 0 ms Largest Contentful Paint: 0.9 s Cumulative Layout Shift: 0 Meh. Not bad. Ok it's very good. Perfect. When you click around, it doesn't seem like a traditional client/server app, but like a SPA. Without being one!
  • Cyberdog 4y ago
    > I wonder... am I good if the static render is < 14kb, but I load React etc. and hydrate for progressive addition of interactivity? Ten years ago, we had a best practice in client-side web development called progressive enhancement. The idea was that you load a web page which is fully functional without JavaScript, then use JS to add whatever glitzy client-side interaction you want to add - but importantly, just as enhancement, so whatever needed to be done on the page could be done, perhaps in an uglier or more awkward way but still doable, before a single line of JavaScript runs. It sounds like you might have rediscovered this concept, and if so, yes, good, please do it. I'm not sure if React will even let you work this way, though.
    • quickthrower2 4y ago
      React doesn’t stop you (it is just a library) but doesn’t help you either. NextJS helps with this kind of thing by letting you statically generate server side the first render in React (you can load data in prior from a source if needed) and then you can CDN that page. You could also do this in rails but NextJS saves you needing say a moustache or ERB version of the same page for the static render. You use the same code for build time, back end runtime and front end. Lovingly called isomorphic programming or as cynics call it: monoglot! I knew of the progressive enhancement concept but what I didn’t know was the 14kb thing. It is motivating me to experiment!
• armchairhacker 4y ago
  Do you get the benefits if your HTML and CSS are under 14kb, but your images and JS requests aren't?
  • Cyberdog 4y ago
    Yes, so long as your page is readable/usable with just HTML and CSS. If that 14kb just loads a progress animation while JS loads and then starts doing a bunch of AJAX queries and DOM manipulation in the back end before you can even see anything on the page, you're still barking up the wrong user-unfriendly tree.
• EVa5I7bHFq9mnYK 4y ago
  For reference, average web page size today is 3MB.
• leke 4y ago
  The network tab says my site is 145b cached as I get my content sent from github.
  • onion2k 4y ago
    Whenever someone talks about page weight they mean from a cold start with an empty cache.
• personjerry 4y ago
  Why your website should have less than 11 fonts in the first 3 sentences: So I can read it
• punkpeye 4y ago
  What platform did you use to build your website? I like how fast it loads!
  • ithrow 4y ago
    some new hot framework called 'plainHtmlandCss'
• Joyfield 4y ago
  kb != kB.
• douchescript 4y ago
  14 kB HTTP site. What about the SSL?
• zinodaur 4y ago
  I like the idea mentioned in the article of increasing the number of packets sent in the slow start - as far as I know you could just crank that from the server side TCP stack to something much larger, right?
  • blfr 4y ago
    Yeah, now that most of us control the server, is this an option?
    • bawolff 4y ago
      Never tried it, but its listed as an option at https://linux.die.net/man/8/ip https://linux.die.net/man/8/ip
      • blfr 4y ago
        Seems fraught with potential issues. Can I do this just for nginx?
        • LinuxBender 4y ago
          Possibly but I've never tried this. One could create a virtual routing table and apply ACL's for the nginx listening ports then apply the initcwnd and initrwnd routing changes to that virtual table.
    • LinuxBender 4y ago
      Yes. This is what I use on my hobby sites and home network. About a decade ago I was using 16 when the default changed to 10 from 3. This is with fq_codel+cdg. Most prefer bbr for servers but I have my own quirky use cases. ip route change local 127.0.0.0/8 dev lo initcwnd 128 initrwnd 128 ip route | grep default | while read p; do ip route change $p initcwnd 32 initrwnd 32; done I would suggest performing significant testing from high latency connections before making changes on anything important. i.e. iperf3/nuttcp from a VM in another country. This would also be a good time to get numbers from different congestion control algorithms and default qdiscs. e.g. net.ipv4.tcp_congestion_control and net.core.default_qdisc [1] [Edit] I should also add that changing these values may require different methods depending on the distribution. [2] [1] - https://www.kernel.org/doc/Documentation/sysctl/net.txt https://www.kernel.org/doc/Documentation/sysctl/net.txt [2] - https://serverfault.com/questions/546523/linux-initcwnd-and-initrwnd-via-etc-sysctl-conf https://serverfault.com/questions/546523/linux-initcwnd-and-...
• onion2k 4y ago
  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 is tbough, a user who frequently uses satellite Internet or a 2G mobile connection will learn that pages take a while to download over that connection, and they will adjust their expectations accordingly. Satellite Internet users aren't giving up on pages every 7s. They're waiting because they know the page will load slowly. I suspect most users wait for a page if most pages are slow. So long as your website is no slower than the average then you're probably not losing many visitors. Obviously that's not to say you shouldn't make your website as fast as you can. You should. Everyone will appreciate the effort. But don't assume that knocking a few seconds off the TTI time will actually impact your conversion metrics. It probably won't (but only a proper study can prove it either way).
  • johnchristopher 4y ago
    > 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. N=1 but I think I am quicker to close a tab with a website that does lazy loading and/or hide stuff for a blink second or three just after showing me the thing I am here for than a tab with a slow loading.
    • fvold 4y ago
      N=2
  • iainmerrick 4y ago
    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 users won’t give up just because your page is slow, but some of them will, and even the ones that persevere will likely appreciate a faster page.
• WantonQuantum 4y ago
  Some sites break the TCP standard by sending the whole contents of the landing page without waiting for the first ACK even it's more than 10 packets.
  • hawk_ 4y ago
    How do they do that? Do they use some nonstandard tcp stack?
    • jacooper 4y ago
      You can change TCP slow start on Linux. https://stackoverflow.com/questions/17015611/how-to-disable-tcp-slow-start-in-linux https://stackoverflow.com/questions/17015611/how-to-disable-...
      • hawk_ 4y ago
        > break the TCP standard Oh ok, but then is it really breaking the standard as OP claims?
• lionkor 4y ago
  I find my own site [0] to be quite fast, since most of it is pretty aggressively cached and its hand-written. Mobile is slightly broken, but still. [0] https://kortlepel.com https://kortlepel.com
• 4m1rk 4y ago
  The writer is not considering that each asset will be a separate connection or am I missing something?
• rozenmd 4y ago
  Neat, I was wondering why https://hackernews.onlineornot.com https://hackernews.onlineornot.com loads so fast (<14kb)
• Linda703 4y ago
  [dead]
• allanrbo 4y ago
  Love how this person's blog itself consist of single HTTP requests per page load. No extra css, images, scripts, or anything! This blogger cares about web perf!
  • maratc 4y ago
    And that single HTTP request is 9.5Kb in size. The guy seems to be practicing what he preaches!
    • LoganDark 4y ago
      I am extremely impressed by this. I probably wouldn't have noticed if not for these comments, but the page loads in ~36 ms for me. That's blazingly fast. (Edit: it's 36 ms with a connection already open. From scratch, it's about 176 ms, still extremely impressive.)
  • jacooper 4y ago
    Yup the speed was refreshing, refreshing from all the dumb news sites which take for ever to load.
    • donohoe 4y ago
      Yeah, fast loading news sites are few. Here is a list to show how bad (and sometimes good) they get: https://webperf.xyz/ https://webperf.xyz/ I maintain this so let me know if any news sites I should add!
      • jacooper 4y ago
        Its not loading on my phone for some reason, but its working on my PC. I would suggest adding Al Jazzera.
      • byyll 4y ago
        https://nltimes.nl https://nltimes.nl
  • 4y ago
• lgats 4y ago
  what’s the average size you get when un-gzipping 14kb of html?
• Ayesh 4y ago
  A typical HTTPS RSA certificate is about 3.9kb. ECDSA certificates with ECDSA cross-signed with an RSA root will be around 2.9kb. So this 14kb of HTML response should leave some room for the certificates too.
  • bawolff 4y ago
    Although isn't there a roundtrip between certificate exchange and actual data being transmited? So i would presume that wouldn't matter
  • alexchamberlain 4y ago
    HTTPS requires an extra couple of round trips (to do the handshake and exchange keys etc). I don't think the whole thing can be optimised to 1 round trip, unfortunately.
    • danpat 4y ago
      It's possible, but not without security implications: https://blog.cloudflare.com/introducing-0-rtt/ https://blog.cloudflare.com/introducing-0-rtt/
      • SahAssar 4y ago
        That's only for session resumption though. 0-RTT does not speed up the first visit
• anonyfox 4y ago
  Aside from the raw size, there are more optimizations that can be done while still having a modern-ish visual result (Shameless self plug: https://anonyfox.com/blog/need-for-speed/ https://anonyfox.com/blog/need-for-speed/ )
• shultays 4y ago
  Once you lose the autoplaying videos, the popups, the cookies, the cookie consent banners, the social network buttons, the tracking scripts, javascript and css frameworks, and all the other junk nobody likes — you're probably there. Wouldn't videos and images (I guess css/js files as well?) loaded separately and be part of other messages?
• hoten 4y ago
  Another optimization in the same vein: make sure the first KB contains the <meta charset> element, to avoid false-starts in the HTML parser. In fact, it's actually specified as an _error_ in the spec to have it come after 1KB! It's mentioned in passing on the Lighthouse docs for the charset audit[1], but here's a great breakdown by hsivonen[2]. Of course, in the headers is even better. Point is, try not to have too much cruft before the charset. [1] https://web.dev/charset/ https://web.dev/charset/ [2] https://github.com/GoogleChrome/lighthouse/issues/10023#issuecomment-575129051 https://github.com/GoogleChrome/lighthouse/issues/10023#issu...
  • nousermane 4y ago
    > Of course, in the headers is even better. Yes, much better. And given prevalence of UTF-8 this days, why not just hard-code your webserver to add such header everywhere: - Apache <VirtualHost ...> <Directory ...> AddDefaultCharset utf-8 ... - nginx http { charset utf-8; ... - Caddy: done already with no explicit config required, yay!
    • tracker1 4y ago
      Have to say, I absolutely love Caddy as a general webserver and reverse-proxy. Lightweight, easy to configure, relatively flexible, sane defaults.
      • rockostrich 4y ago
        I was skeptical coming from running my home server with nginx as a reverse proxy for a bunch of services, but caddy is a joy to use.
      • soheil 4y ago
        > easy to configure, relatively flexible, sane defaults Compared to what? You think nginx is not easy to configure or has insane defaults somehow? Really baffled why people come out of the wood work to pile on beautifully architectured designs in favor of some random project they happen to like or just because it's written in a language they have a special affinity for like Go or something.
• iamsaitam 4y ago
  Interesting find. On the other hand, it's not a one size shoe fits all metric. If the interaction with your website is mainly reading text, then sure it's a valid take. Otherwise you should really just forget about it and use focus on other best practices for providing a good early user experience.
• merpkz 4y ago
  so the hot takeaway here is that CSS must absolutely be embedded in HTML header so that browser does not make two requests to start rendering page in question. Also if page is using TLS and it most likely is, this all falls apart because initial handshake will do at least one round trip and kill all the speed of loading resource.
• anigbrowl 4y ago
  Great piece. took me back to the figuring out TCP at 2400 bps back in the dial-up era. The bit on satellites made me wonder if there's room for storage servers/relays in space.
• lenkite 4y ago
  content-length: 31367 for this page, so looks like the author couldn't do it either. How can us mere mortals ? A more realistic target: https://512kb.club/ https://512kb.club/
  • Alducer 4y ago
    They mention in the article that the 14 kb performance cliff applies to compressed size - I believe 32kb is the uncompressed size here
• deleted 4y ago
  [deleted]
• kukx 4y ago
  "b" in kb means bits. While the uppercase letter "B" denotes bytes. There is almost an order of magnitude difference between these two units! Usually 1B = 8b.
• tlarkworthy 4y ago
  This is to minimize the round trips, I think a saner solution is have content served from many edge locations nearer the user so the impact of a roundtrip is so much less. Consumers and business users definitely want jazzy websites and 14kb is not able to do much.
• motoboi 4y ago
  So cute to see this in the era of JavaScript frameworks. I remember 10 years ago this being a thing and google keeping theirs at 14kb. Today, if not server side rendered, you'll need react lib or equivalent to load your site and boi, that's a little over 14kb.
• immibis 4y ago
  14kB, what is that? I thought the web had a minimal file size of the entire original DOOM game.
• tambourine_man 4y ago
  >There are other used of the web uses >This this maximum is not set by Double this
• layer8 4y ago
  Note that you have to count the HTTP headers in those 14600 bytes, not just the HTML.
• tamsaraas 4y ago
  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.
  • chasd00 4y ago
    https://www.cloudflare.com/learning/network-layer/what-is-mtu/ 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...
  • tehbeard 4y ago
    Who exactly is running networks with smaller max packet sizes? Doesn't seem to make sense as it would increase overhead, I can only see it happening at the edge for IoT devices, maybe.
• ksec 4y ago
  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.
  • baobob 4y ago
    About 10 years ago it was possible to observe non-RFC behaviour from (IIRC) google.com doing exactly this. I don't know if they still do it
  • strken 4y ago
    If you're interested in why it was originally increased to 10 segments, here's the RFC: https://www.rfc-editor.org/rfc/rfc6928.html https://www.rfc-editor.org/rfc/rfc6928.html. That was a decade ago, but I have no idea if the underlying fundamentals have changed since then. It's possible they still need to protect really bad connections, e.g. those in developing countries.
  • andai 4y ago
    Many CDNs use a bigger value: https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/ https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-p...
  • chasd00 4y ago
    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.
• truth_seeker 4y ago
  Don't you forget "Content-Encoding: gzip" in HTTP header.
• k3liutZu 4y ago
  Crying in MB of JS
• nzach 4y ago
  What does this means, if anything, for API calls between services in a microservices context ? Should we worry about this specific size threshold when making calls between services on kubernetes or the kubernetes ecosystem is smart enough to avoid this slow start problem ?
• bradley_taunt 4y ago
  Or just go absolute foolishly extreme and have your website under 1kB total ;) https://1kb.club https://1kb.club
• jillesvangurp 4y ago
  Of course with HTTP3, we'll get TCP out of the equation as that uses UDP/Quic underneath. If you pick the right CDN/hosting/web server, you can benefit from that right now. Supported on essentially all relevant phones, browsers, etc. So, why wait? If you care about performance, upgrading your infrastructure is probably the first thing you should do, not the last thing. Mostly, the only effect of bigger download sizes is a higher chance for things to go wrong on flaky networks (e.g. on mobile) and a slight delay with the application initializing. On the first visit. The second visit, you can have all the assets cached and it matters much less. At that point the only thing slowing you down is what the application does. It's 2022. An article arguing how to get the most out of obsolete versions of HTTP (<3) and TCP seems a bit redundant as you shouldn't be using either if you can avoid it. Also, anything using less bytes than the commodore 64 that I had 40 years ago had in memory is interesting but also a bit of an exercise in being overly frugal. You should reflect on the value of your time and effort. There's a notion of diminishing returns that are very expensive. Such is the nature of optimization. Sometimes a millisecond is priceless. But mostly it's irrelevant. People have 5G and 4G phones these days capable of downloading many orders of magnitude more data per second than that. Download size is probably the wrong thing to focus on for most applications. I get it, engineers are deeply passionate about optimization and minimalism. And I appreciate what can be done with very little CSS and HTML from a technical point of view. But it's just not relevant to me on my work projects. I'd rather spend time on adding value than obsessing over saving a few kilo bytes here and there. People pay for one thing and barely even notice the other thing. I ship a quite bloated SPA to customers. It comes in around 10MB and takes a couple of seconds to get going. It's fine; it's not a problem. I could double that size and nothing would happen. Nobody would complain. We sell it for lots of money because of what it does, not because of how large or small it is. The value of halving that size is close to 0$ for us. The price of doubling the size is also close to that. The price of sacrificing features on the other hand would be a massive loss of value. Our sales team would object. And yes, we use a Google Cloud's load balancer and their CDN that does all the right things. If it mattered, I might find slightly faster options. But it just doesn't. And 10MB is actually not that bad on a decent network and nothing compared to what our application does after it loads in any case. Which would be doing lots of json API traffic, downloading map tiles and images, etc. In short, if you are not on a good network, using our app is going to suck. The initial download size would be the least of your problems in that case. And if you are on a decent network, the app loads quickly and feels very responsive. Our app simply requires a decent network. And decent networks are a widely available commodity.
• majke 4y ago
  Shameless plug https://blog.cloudflare.com/when-the-window-is-not-fully-open-your-tcp-stack-is-doing-more-than-you-think/ https://blog.cloudflare.com/when-the-window-is-not-fully-ope... I recently wrote a piece about specifically this mechanism (though looked from the receiver side). Basically on linux you can work around this initcwnd limit (if you have to, for whatever reason), by tuning buffer sizes, initcwnd obviously, and rcv_ssthresh.
• deleted 4y ago
  [deleted]
• mahoro 4y ago
  BTW you can also open multiple connections and fetch 14kb from each of them quickly
• patrickaljord 4y ago
  Even google.com is 45kb. HN is 8kb and it's almost text-only with almost no js, almost impossible for any website nowadays.
• sokoloff 4y ago
  Headline restates the sizes in a way that makes them somewhere between ambiguous and wrong. The article gets the unit correct (B for bytes) while the headline swapped in b for B, which is generally bits.
• subhashchy 4y ago
  This is very cool. In the age if bloated JS frameworks and Bulky Desktop sites loaded on Mobile devices, its refreshing to see someone putting efforts to make the pages fit in a single MTU. However, just page size is half the story. Look at the screenshots below - #1 - Here you can see this page (9KB) - 110ms - https://i.imgur.com/qeT2Az0.jpg https://i.imgur.com/qeT2Az0.jpg #2 - Another page, 29 KB in size - 42ms. https://i.imgur.com/tWsLGr1.jpg https://i.imgur.com/tWsLGr1.jpg Both on same network (Internet), same computer. 1st one (This article) is served by Netlify and AWS (Static hosting). 2nd is an ecommerce store on Dukaan (ecommerce platform for India), I am affiliated with.
  • reitanqild 4y ago
    Tangential: is there a law for websites like there is for countries? If a country includes the word "Democratic" in the name, it probably isn't. If a website says "We value your privacy", it probably doesn't.
  • mminer237 4y ago
    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.
    • subhashchy 4y ago
      endtimes.dev is on netlify I believe and a static site, correct ?
      • mminer237 4y ago
        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.
• dreamcompiler 4y ago
  The section on satellite internet should probably be updated to clarify that LEO satellite networks like Starlink orbit at 1/100 the distance of GEO satellites, so the parts of the latency calculation involving uplink and downlink become much less important. (The rest of the numbers in the latency calculation still apply.)
  • erinaceousjones 4y ago
    It is nice that they thought of "oil rig bros" though. I can't imagine the publically funded research ships I've worked on will even legally/politically be allowed to use Starlink even when within good coverage areas of it, at least not for a long time due to institutional pressures, and there's a risk that people see Starlink as "the" new shiny satellite provider and assume that's the worst-case latency/bandwidth target! Like - our 2mbps internet connection shared between ~50 people does _actually work_, the Internet is _fine_, but so much of the WWW is frustratingly broken - not just because of large page sizes (we have caching proxies onboard, large downloads are fine), but predominantly because of so much parallel loading, servers being impatient with connect/read timeouts, DNS servers treating us like a DDoS attack, a lack of progressive enhancement (page blank = hanging waiting on a font to load from jsdelivr...). Seeing people still focusing on the nitty gritty like optimising for page loads given TCP slow-start is nice to see from a "LITERALLY accessible all over the world" standpoint :-)
    • dreamcompiler 4y ago
      Why would Starlink be a more difficult sell politically than one of the GEO providers?
• 3pm 4y ago
  I think 14KB 'rule' is less relevant these days, but is a good mnemonic to "put the most critical data at the start of the page". Even if this page has to be large, browsers are streaming it and can start processing before it is fully consumed. https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/ https://www.tunetheweb.com/blog/critical-resources-and-the-f...
• levpopov 4y ago
  This is mostly nonsense, you can easily check for yourself. Load up the OP's page with Chrome dev tools network tab open. Connection start: 90ms (60ms of which is SSL handshake) Request/Response: 30ms request / 30ms response So the whole post is about yak shaving not splitting the 30ms response portion of a request that already takes 5x that (150+ms). Sure it's a bit faster, but your users will not notice the difference between a 14kb page and a 15kb page over https (which you hopefully have on).
• stasm 4y ago
  Tangentially related: https://js13kgames.com https://js13kgames.com is currently going on -- the challenge is to build an HTML/CSS/JS game which compresses down to 13,312 bytes or less.
• sdeziel 4y ago
  Nice article! However some numbers are a bit off: The IPv4 overhead is normally 20 bytes but can reach 60 bytes with many options. For TCP, it's between 20 and 60 bytes as well. Just ran a quick tcpdump on Linux and curl's TCP connection uses 32 bytes TCP headers (12 bytes of options).
• effnorwood 4y ago
• barrystaes 4y ago
  > That leaves 1460 bytes per TCP packet. 10 x 1460 = 14600 bytes or roughly 14kB! Where does the 10 suddenly come from?
• BobMit 4y ago
  Come on with those optimizations. the internet is getting faster and I still see articles on how to optimize the website.
• kamban 4y ago
  I read it. This is new to me, and I guess one needs to remove so many tags and tracking tools. I hope it only counts to a single server. What happens with the data loaded from CDNs?