9 ms·
A 14kb page can load much faster than a 15kb page (2022)
- palata 1y agoFortunately, most websites include megabytes of bullshit, so it's not remotely a concern for them :D.
- Hamuko 1y agoI recently used an electric car charger where the charger is controlled by a mobile app that's basically a thin wrapper over a website. Unfortunately I only had a 0.25 Mb/s Internet plan at the time and it took me several minutes just staring at the splash screen as it was downloading JavaScript and other assets. Even when I got it to load, it hadn't managed to download all fonts. Truly an eye-opening experience.
- fouronnes3 1y agoWhy can't we just pay with a payment card at electric chargers? Drives me insane.
- Hamuko 1y agoThese chargers have an RFID tag too, but I'd forgotten it in my jacket, so it was mobile app for me. There are some chargers that take card payments though. My local IKEA has some. There's also EU legislation to mandate payment card support. https://electrek.co/2023/07/11/europe-passes-two-big-laws-to-make-ev-charging-a-whole-lot-better/ https://electrek.co/2023/07/11/europe-passes-two-big-laws-to...
- DuncanCoffee 1y agoIt wasn't required by law and the ocpp charging protocol, used to manage charge sessions at a high level between the charger and the service provider (not the vehicle) did not include payments management. Everybody just found it easier to manage payments using apps and credits. But I think Europe is going to make it mandatory soon(ish)
- zevv 1y agoAnd now try to load the same website over HTTPS
- xrisk 1y agoYeah I think this computation doesn’t work anymore once you factor in the tls handshake.
- aziaziazi 1y agoFrom TFA: > Also HTTPS requires two additional round trips before it can do the first one — which gets us up to 1836ms!
- supermatt 1y agoThis hasn’t been the case since TLS1.3 (over 5 years ago) which reduced it to 1-RTT - or 0-RTT when keys are known (cached or preshared). Same with QUIC.
- aziaziazi 1y agoGood to know, however "when the keys are know" refers to a second visit (or request) of the site right ? That isn’t helpful for the first data paquets - at least that what I understand from the site.
- jeroenhd 1y agoWithout cached data from a previous visit, 1-RTT mode works even if you've never vistited the site before (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/#1-rtt-mode https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/#1-rtt-mode). It can fall back to 2-RTT if something funky happens, but that shouldn't happen in most cases. 0-RTT works after the first handshake, but enabling it allows for some forms of replay attacks so that may not be something you want to use for anything hosting an API unless you've designed your API around it.
- 1y ago
- moomoo11 1y agoI’d care about this if I was selling in India or Africa. If I’m selling to cash cows in America or Europe it’s not an issue at all. As long as you have >10mbps download across 90% of users I think it’s better to think about making money. Besides if you don’t know that lazy loading exists in 2025 fire yourself lol.
- jofzar 1y agoIt really depends on who your clients are and where they are. https://www.mcmaster.com/ https://www.mcmaster.com/ was found last year to be doing some real magic to make it load literally as fast as possible for the crapiest computers possible.
- kosolam 1y agoThe site is very fast indeed
- actionfromafar 1y agoI want to buy fasteners now.
- kosolam 1y agoFasterners, as fast as possible
- A_D_E_P_T 1y agoDo you have any idea what they actually did? It would be interesting to study. That site really is blazing fast.
- gbuk2013 1y agoQuick look: GSLB (via Akamai) for low latency, tricks like using CSS sprite to serve a single image in place of 20 or so for fewer round-trips, heavy use of caching, possibly some service worker magic but I didn't dig that far. :) Basically, looks like someone deliberately did many right things without being lazy or cheap to create a performant web site.
- paales2 1y agoOr maybe we shouldn’t. A good experience doesnt have to load under 50ms, it is fine for it to take a second. 5G is common and people with slower connections accept longer waiting times. Optimizing is good but fixating isn’t.
- 9dev 1y agoThe overlap of people that don’t know what TCP Slow Start is and those that should care about their website loading a few milliseconds faster is incredibly small. A startup should focus on, well, starting up, not performance; a corporation large enough to optimise speed on that level will have a team of experienced SREs that know over which detail to obsess.
- andrepd 1y ago> a corporation large enough will have a team of experienced SREs that know over which detail to obsess. Ahh, if only. Have you seen applications developed by large corporations lately? :)
- achenet 1y agoa corporation large enough to have a team of experienced SREs that know which details to obsess over will also have enough promotion-hungry POs and middle managers to tell them devs to add 50MB of ads and trackers in the web page. Maybe another 100MB for an LLM wrapper too. :)
- hinkley 1y agoDon’t forget adding 25 individual Google Tag Managers to every page.
- elmigranto 1y agoRight. That’s why all the software from, say, Microsoft works flawlessly and at peak efficiency.
- simgt 1y agoAside from latency, reducing ressources consumption to the minimum required should always be a concern if we intend to have a sustainable future. The environmental impact of our network is not negligible. Given the snarky comments here, we clearly have a long way to go. EDIT: some reply missed my point, I am not claiming this particular optimization is the holy grail, only that I'd have liked for added benefit of reducing the energy consumption to be mentioned
- qayxc 1y agoIt's not low-hanging fruit, though. While you try to optimise to save a couple of mWh in power use, a single search engine query uses 100x more and an LLM chat is another 100x of that. In other words: there's bigger fish to fry. Plus caching, lazy loading etc. mitigates most of this anyway.
- vouaobrasil 1y agoEngineering-wise, it sometimes isn't. But it does send a signal that can also become a trend in society to be more respectful of our energy usage. Sometimes, it does make sense to focus on the most visible aspect of energy usage, rather than the most intensive. Just by making your website smaller and being vocal about it, you could reach 100,000 people if you get a lot of visitors, whereas Google isn't going to give a darn about even trying to send a signal.
- qayxc 1y agoI'd be 100% on board with you if you were able to show me a single - just a single - regular website user who'd care about energy usage of a first(!) site load. I'm honestly just really annoyed about this "society and environment"-spin on advise that would have an otherwise niche, but perfectly valid reason behind it (TFA: slow satellite network on the high seas). This might sound harsh and I don't mean it personally, but making your website smaller and "being vocal about it" (whatever you mean by that) doesn't make an iota of difference. It also only works if your site is basically just text. If your website uses other resources (images, videos, 3D models, audio, etc.), the impact of first load is just noise anyway. You can have a bigger impact by telling 100,000 people to drive an hour less each month and if just 1% of your hypothetical audience actually does that, you'd achieve orders of magnitude more in terms of environmental and societal impact.
- ksec 1y agoMissing 2021 in the title. I know it is not the exact topic, but sometimes I think we dont need the fastest response time but consistent response time. Like every single page within the site to be fully rendered with exactly 1s. Nothing more nothing less.
- sangeeth96 1y agoI think the advise is still very relevant though. Plus, the varying network conditions mentioned in the article would ensure it’s difficult if impossible to guarantee consistent response time. As someone with spotty cellular coverage, I can understand the pains of browsing when you’re stuck with that.
- ksec 1y agoYes. I don't know how it could be achieved other than having JS rendered the whole thing, wait until time designated before showing it all. And that time could be dependent on network connection. But this sort of goes against my no / minimal JS front end rendering philosophy.
- AStonesThrow 1y ago[dead]
- the_precipitate 1y agoAnd you do know that .exe file is wasteful, .com file actually saves quite a few bytes if you can limit your executable's size to be smaller than 0xFF00h (man, I am old).
- cout 1y agoAnd a.out format often saves disk space over elf, despite duplicating code across executables.
- crawshaw 1y agoIf you want to have fun with this: the initial window (IW) is determined by the sender. So you can configure your server to the right number of packets for your website. It would look something like: ip route change default via <gw> dev <if> initcwnd 20 initrwnd 20 A web search suggests CDNs are now at 30 packets for the initial window, so you get 45kb there.
- sangeeth96 1y ago> A web search suggests CDNs are now at 30 packets for the initial window, so you get 45kb there. Any reference for this?
- ryan-c 1y agoI'm not going to dig it up for you, but this is in line with what I've read and observed. I set this to 20 packets on my personal site.
- darthShadow 1y ago* https://sirupsen.com/napkin/problem-15 https://sirupsen.com/napkin/problem-15 * https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/ https://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-p...
- sangeeth96 1y agoThanks!
- londons_explore 1y agobe a bad citizen and just set it to 1000 packets... There isn't really any downside apart from potentially clogging up someone who has a dialup connection and bufferbloat.
- notpushkin 1y agoThis sounds like a terrible idea, but can anybody pinpoint why exactly?
- deleted 1y ago[deleted]
- austin-cheney 1y agoIt seems the better solution is to not use HTTP server software that employs this slow start concept. Using my own server software I was able to produce a complex single page app that resembled an operating system graphical user interface and achieve full state restoration as fast as 80ms from localhost page request according to the Chrome performance tab.
- mzhaase 1y agoTCP settings are OS level. The web server does not touch them.
- austin-cheney 1y agoThe article says this is not a TCP layer technology, but something employed by servers as a bandwidth estimating algorithm. You are correct in that TCP packets are processed within the kernel of modern operating systems. Edit for clarity: This is a web server only algorithm. It is not associated with any other kind of TCP traffic. It seems from the down votes that some people found this challenging.
- jeffbee 1y agoYet another reason that QUIC is better.
- firecall 1y agoDamn... I'm at 17.2KB for my home page! (not including dependencies) FWIW I optimised the heck out of my personal homepage and got 100/100 for all Lighthouse scores. Which I had not previously thought possible LOL Built in Rails too! It's absolutely worth optimising your site though. It just is such a pleasing experience when a page loads without any perceptible lag!
- ghoshbishakh 1y agorails has nothing to do with the rendered page size though. Congrats on the perfect lighthouse score.
- Alifatisk 1y agoDoesn't Rails asset pipeline have an effect on the page size, like if Propshaft being used instead of Sprockets. From what I remember, Propshaft intentionally does not include minification or compression.
- firecall 1y agoIt’s all Rails 8 + Turbo + Stimulus JS with Propshaft handling the asset bundling / pipeline. All the Tailwind building and so on is done using common JS tools, which are mostly standard out of the box Rails 8 supplied scripts! Sprockets used to do the SASS compilation and asset bundling, but the Rails standard now is to facilitate your own preferences around compilation of CSS/JS.
- firecall 1y agoIndeed it does not :-) It was more a quick promote Rails comment as it can get dismissed as not something to build fast website in :-)
- apt-apt-apt-apt 1y agoYeah, the fact that news.ycombinator.com loads instantly pleases my brain so much I flick it open during downtime automonkey-ly
- gammalost 1y agoIf you care about reducing the amount of back and forth then just use QUIC.
- eviks 1y agoHas this theory been tested?
- justmarc 1y agoDoes anyone know have examples of tiny, yet aesthetically pleasing websites or pages? Would love it if someone kept a list.
- hackerman_fi 1y agoThere is an example link in the article. Listing more examples would serve no purpose apart from web design perspective
- justmarc 1y agoWell, exactly that, I'm looking for inspiration.
- FlyingSnake 1y agoThere’s https://512kb.club/ https://512kb.club/ which I follow to keep my website lightweight
- wonger_ 1y ago10kbclub.com, archived: https://archive.li/olM9k https://archive.li/olM9k https://250kb.club/ https://250kb.club/ Hopefully you'll find some of them aesthetically pleasing
- adastra22 1y agoThe linked page is 35kB.
- susam 1y agoI just checked my home page [1] and it has a compressed transfer size of 7.0 kB. / 2.7 kB main.css 2.5 kB favicon.png 1.8 kB ------------------- Total 7.0 kB Not bad, I think! I generate the blog listing on the home page (as well as the rest of my website) with my own static site generator, written in Common Lisp [2]. On a limited number of mathematical posts [3], I use KaTeX with client-side rendering. On such pages, KaTeX adds a whopping 347.5 kB! katex.min.css 23.6 kB katex.min.js 277.0 kB auto-render.min.js 3.7 kB KaTeX_Main-Regular.woff2 26.5 kB KaTeX_Main-Italic.woff2 16.7 kB ---------------------------------- Total Additional 347.5 kB Perhaps I should consider KaTeX server-side rendering someday! This has been a little passion project of mine since my university dorm room days. All of the HTML content, the common HTML template (for a consistent layout across pages), and the CSS are entirely handwritten. Also, I tend to be conservative about what I include on each page, which helps keep them small. [1] https://susam.net/ https://susam.net/ [2] https://github.com/susam/susam.net/blob/main/site.lisp https://github.com/susam/susam.net/blob/main/site.lisp [3] https://susam.net/tag/mathematics.html https://susam.net/tag/mathematics.html
- welpo 1y ago> That said, I do use KaTeX with client-side rendering on a limited number of pages that have mathematical content You could try replacing KaTeX with MathML: https://w3c.github.io/mathml-core/ https://w3c.github.io/mathml-core/
- BlackFly 1y agoKatex renders to MathML (either server side or client side). Generally people want a slightly more fluent way of describing an equation than is permitted by a soup of html tags. The various tex dialects (generally just referred to as latex) are the preferred methods of doing that.
- mr_toad 1y agoServer side rendering would cut out the 277kb library. The additional MathML being sent to the client is probably going to be a fraction of that.
- smartmic 1y agoIf I understood correctly, the rule is dependent on web server features and/or configuration. In that case, an overview of web servers which have or have not implemented the slow start algorithm would be interesting.
- mikl 1y agoHow relevant is this now, if you have a modern server that supports HTTP/3? HTTP/3 uses UDP rather than TCP, so TCP slow start should not apply at all.
- hulitu 1y ago> How relevant is this now Very relevant. A lot of websites need 5 to 30 seconds or more to load.
- throwaway019254 1y agoI have a suspicion that the 30 second loading time is not caused by TCP slow start.
- ajross 1y agoSlow start is about saving small-integer-numbers of RTT times that the algorithm takes to ramp up to line speed. A 5-30 second load time is an order of magnitude off, and almost certainly due to simple asset size.
- gbuk2013 1y agoAs per the article, QUIC (transport protocol underneath HTTP/3) uses slow start as well. https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery-26.html#name-slow-start https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery...
- gsliepen 1y agoA lot of people don't realize that all these so-called issues with TCP, like slow-start, Nagle, window sizes and congestion algorithms, are not there because TCP was badly designed, but rather that these are inherent problems you get when you want to create any reliable stream protocol on top of an unreliable datagram one. The advantage of QUIC is that it can multiplex multiple reliable streams while using only a single congestion window, which is a bit more optimal than having multiple TCP sockets. One other advantage of QUIC is that you avoid some latency from the three-way handshake that is used in almost any TCP implementation. Although technically you can already send data in the first SYN packet, the three-way handshake is necessary to avoid confusion in some edge cases (like a previous TCP connection using the same source and destination ports).
- ilaksh 1y agohttps://github.com/runvnc/tersenet https://github.com/runvnc/tersenet
- tgv 1y agoThis could be another reason: https://blog.cloudflare.com/russian-internet-users-are-unable-to-access-the-open-internet/ https://blog.cloudflare.com/russian-internet-users-are-unabl... > ... analysis [by Cloudflare] suggests that the throttling [by Russian ISPs] allows Internet users to load only the first 16 KB of any web asset, rendering most web navigation impossible.
- notpushkin 1y agoHmm, could Cloudflare increase packet size (or initial window, or perhaps turn some other knob) for Russian traffic specifically?
- Alifatisk 1y agoI agree with the sentiment here, the thing is, I've noticed that the newer generations are using frameworks like Next.js as default for building simple static websites. That's their bare bone start. The era of plain html + css (and maybe a sprinkle of js) feels like it's fading away, sadly.
- zero_shift 1y agoI think that makes sense. I have done the hyper optimised, inline resource, no blocking script, hand minimised JS, 14kb website thing before and the problem with doing it the "hard" way is it traps you in a design and architecture. When your requirements change all the minimalistic choices that seemed so efficient and web-native start turning into technical debt. Everyone fantasises about "no frameworks" until the project is no longer a toy. Whereas the isomorphic JS frameworks let you have your cake and eat it: you can start with something that spits out compiled pages and optimise it to get performant _enough_, but you can fall back to thick client JavaScript if necessary.
- timeon 1y agoIt is bit sad that web is optimized for developer not the user. Even with blog barely anyone would develop further.
- fleebee 1y agoI think you're late enough for that realization that the trend already shifted back a bit. Most frameworks I've dealt with can emit static generated sites, Next.js included. Astro feels like it's designed for that purpose from the ground up.
- austin-cheney 1y agoYou have noticed that only just recently? This has been the case since jQuery became popular before 2010.
- chneu 1y agoArguably it's been this way since web 2.0 became a thing in like 2008?
- hackerman_fi 1y agoThe article has IMO two flawed arguments: 1. There is math for how long it takes to send even one packet over satellite connection (~1600ms). Its a weak argument for the 14kb rule since there is no comparison with a larger website. 10 packets wont necessarily take 16 seconds. 2. There is a mention that images on webpage are included in this 14kb rule. In what case are images inlined to a page’s initial load? If this is a special case and 99.9% of images don’t follow it, it should be mentioned at very least.
- hsbauauvhabzb 1y agoAlso the assumption that my userbase uses low latency satellite connections, and are somehow unable to put up with my website, when every other website in current existence is multiple megabytes.
- ricardobeat 1y agoThere was no such assumption, that was just the first example after which he mentions normal roundtrip latencies are usually in the 100-300ms range. Just because everything else is bad, doesn't invalidate the idea that you should do better. Today's internet can feel painfully slow even on a 1Gbps connection because of this; websites were actually faster in the early 2000s, during the transition to ADSL, as they still had to cater to dial-up users and were very light as a result.
- sgarland 1y ago> Just because everything else is bad, doesn't invalidate the idea that you should do better. I get this all the time at my job, when I recommend a team do something differently in their schema or queries: “do we have any examples of teams currently doing this?” No, because no one has ever cared to try. I understand not wanting to be guinea pigs, but you have a domain expert asking you to do something, and telling you that they’ll back you up on the decision, and help you implement it. What more do you want?!
- throwup238 1y ago
- youngtaff 1y agoIt’s not really relevant in 2025… The HTTPS negotiation is going to consume the initial roundtrips which should start increasing the size of the window Modern CDNs start with larger initial windows and also pace the packets onto the network to reduce the chances of congesting There’s also a question as to how relevant the 14kb rule has ever been… HTML renders progressively so as long as there’s some meaningful content in the early packets then overall size is less important
- maxlin 1y agoThe geostationary satellite example, while interesting, is kinda obsolete in the age of Starlink
- theandrewbailey 1y agoStarlink is only 1 option in the satellite internet market. There are too many embedded systems and legacy infrastructure that its not reasonable to assume that 'satellite internet' means Starlink. Maybe in 20 years, but not today.
- maxlin 1y agoThat's like saying vacuum tubes are only one option in the radio market. The quality of connection is so much better, and as you can get a starlink mini with a 50GB plan for very little money, its already in the zone that just one worker could grab his own and bring it on the rig to use on his free time and to share. Starlink terminals aren't "infrastructure". Campers often toss one on their roof without even leaving the vehicle. Easier than moving a chair. So, as I said, the geostationary legacy system immediately becomes entirely obsolete other than for redundancy, and is kinda irrelevant for uses like browsing the web.
- 3cats-in-a-coat 1y ago"Obsolete" suggests Starlink is clearly better and sustainable, and that's a very bold statement to make at this point. I suspect in few decades the stationary satellites will still be around, while Starlink would've either evolved drastically or gone away.
- maxlin 1y agoI can easily say they are obsolete. The same way old tech is obsolete. Sure, given a catastrophe, eventually maybe we'll be driving around in easier-to-fix old cars and such, and making communications with whatever simpler analog methods. For the use highlighted, geostationary satellites are absolutely obsolete, unless a catastrophe happens. Questioning my premise is like saying its perfectly logical to plan your kitchen around eating MRE's because "they aren't obsolete". Today's satellite internet isn't yesterday's satellite internet.
- LAC-Tech 1y agoThis looks like such an interesting articles, but it's completely ruined by the fact that every sentence is its own paragraph. I swear I am not just trying to be a dick here. If I didn't think it had great content I wouldn't have commented. But I feel like I'm reading a LinkedIn post. Please join some of those sentences up into paragraphs!
- GavinAnderegg 1y ago14kB is a stretch goal, though trying to stick to the first 10 packets is a cool idea. A project I like that focuses on page size is 512kb.club [1] which is like a golf score for your site’s page size. My site [2] came in just over 71k when I measured before getting added (for all assets). This project also introduced me to Cloudflare Radar [3] which includes a great tool for site analysis/page sizing, but is mainly a general dashboard for the internet. [1] https://512kb.club/ https://512kb.club/ [2] https://anderegg.ca/ https://anderegg.ca/ [3] https://radar.cloudflare.com/ https://radar.cloudflare.com/
- FlyingSnake 1y agoSecond this. I also find 512kb as a more realistic benchmark and use it for my website. The modern web has crossed the rubicon long time ago for 14kb websites.
- mousethatroared 1y agoA question as a non user: What are you doing with the extra 500kB for me, the user? > 90% of the time in interested in text. Most of the reminder vector graphics would suffice. 14 kB is a lot of text and graphics for a page. What is the other 500 for?
- nicce 1y agoIf you want a fancy syntax highlighter for code blocks with multiple languages on your website, that is alone about that size. E.g. regex rules and the regex engine.
- masfuerte 1y agoAs an end user I want a website that does the highlighting once on the back end.
- filleduchaos 1y agoText, yes. Graphics? SVGs are not as small as people think especially if they're any more complex than basic shapes, and there are plenty of things that simply cannot be represented as vector graphics anyway. It's fair to prefer text-only pages, but the "and graphics" is quite unrealistic in my opinion.
- zelphirkalt 1y agoMy plain HTML alone is 10kB and it is mostly text. I don't think this is achievable for most sites, even the ones limiting themselves to only CSS and HTML, like mine.
- 3cats-in-a-coat 1y agoThis is about your "plain HTML". If the rest is in cache, then TCP concerns are irrelevant.
- silon42 1y agoYou must also be careful not to generate "get-if-modified", or such checks.
- MrJohz 1y agoDepending on who's visiting your site and how often, the rest probably isn't in cache though. If your site is a product landing page or a small blog or something else that people are rarely going to repeatedly visit, then it's probably best to assume that all your assets will need to be downloaded most of the time.
- 3cats-in-a-coat 1y agoWhile it'd be fun to try, I doubt you can produce any page at all that's total 14kb with assets, even back at the dawn of the web in the 90s, aside from the spartan minimal academic pages some have. And where loading faster is completely irrelevant.
- MrJohz 1y agoThe homepage for my blog is apparently 9.95kB, which includes all styles, some JS, and the content. There is an additional 22kB font file that breaks the rule, but when I first designed the site I used built-in browser fonts only, and it looked fine. There are no images on the homepage apart from a couple of inlined SVG icons in the footer. Looking at the posts themselves, they vary in size but the content/styles/JS probably average around 14kB. You've also got the font file, but again a more minimal site could strip that. Finally, each post has a cover image that makes up the bulk of the content size. I don't think you're ever going to get that under 14kB, but they're also very easy to load asynchronously, and with a CSS-rendered blur hash placeholder, you could have an initial page load that looks fairly good where everything not in the initial 14kB can be loaded later without causing FOUCs/page layout shifts/etc. For a magazine site or a marketing site, the 14kB thing is almost certainly impossible, but for blogs or simple marketing pages where the content is more text-based or where there are minimal above-the-fold images, 14kB is pretty viable. For reference, my blog is https://jonathan-frere.com/ https://jonathan-frere.com/, and you can see a version of it from before I added the custom fonts here: https://34db2c38.blog-8a1.pages.dev/ https://34db2c38.blog-8a1.pages.dev/ I think both of these versions are not "spartan minimal academic pages".
- nottorp 1y agoSo how bad is it when you add https?
- xg15 1y ago> Also HTTPS requires two additional round trips before it can do the first one — which gets us up to 1836ms! Doesn't this sort of undo the entire point of the article? If the idea was to serve the entire web page in the first roundtrip, wouldn't you have lost the moment TLS is used? Not only does the TLS handshake send lots of stuff (including the certificate) that will likely get you over the 14kb boundary before you even get the chance to send a byte of your actual content - but the handshake also includes multiple request/response exchanges between client and server, so it would require additional roundtrips even if it stayed below the 14kb boundary. So the article's advice only holds for unencrypted plain-TCP connections, which no one would want to use today anymore. The advice might be useful again if you use QUIC/HTTP3, because that one ditches both TLS and TCP and provides the features from both in its own thing. But then, you'd have to look up first how congestion control and bandwidth estimation works in HTTP3 and if 14kb is still the right threshold.
- toast0 1y agoModern TLS adds one round trip, unless you have TCP fast open or 0-RTT resumption; neither of which are likely in a browser case, so call it 1 extra round trip. Modern TLS includes TLS 1.3 as well as TLS 1.2 with TLS False Start (RFC 7918, August 2016). And TLS handshakes aren't that big, even with certificates... Although you do want to use ECC certs if you can, the keys are much smaller. The client handshake should fit in 1-2 packets, the server handshake should fit in 2-3 packets. But more importantly, the client request can only be sent after receiving the whole server handshake, so the congestion window will be refreshed. You could probably calculate how much larger the congestion window is likely to be, and give yourself a larger allowance, since TLS will have expanded your congestion window. Otoh, the important concept, is that early throughput is limited by latency and congestion control, and it takes many round trips to hit connection limits. One way to apply that is if you double your page weight at the same time you add many more service locations and traffic direction, you can see page load times stay about the same.
- Palmer22 1y ago[flagged]
- thierrydamiba 1y agoWhat is this and why is it the top comment? Appears to be spam for scammers. Stay away and please flag.
- tomhow 1y agoDiscussed at the time: A 14kb page can load much faster than a 15kb page - https://news.ycombinator.com/item?id=32587740 https://news.ycombinator.com/item?id=32587740 - Aug 2022 (343 comments)
- mikae1 1y 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. How about a single image? I suppose a lot of people (visitors and webmasters) like to have an image or two on the page.
- coolspot 1y agoAs long as your page doesn’t wait for that image, your page is going to be shown faster if it is 14kb.
- tonymet 1y agoSoftware developer’s should be more aware of the media layer . I appreciate the author’s post about 3g /5g reliability and latency. Radio almost always retries, and with most HTTP your packets need to arrive in order. A single REST request is only truly a single packet if the request and response are both < 1400 bytes. Any more than that and your “single” request is now multiple requests & responses . Any one of them may need a retry and they all need to arrive in order for the UI to update. For practical experiments, try chrome dev tools in 3g mode with some packet loss and you can see even “small” optimizations improving UI responsiveness dramatically. This is one of the most compelling reasons to make APIs and UIs as small as possible.
- deleted 1y ago[deleted]
- zigzag312 1y agoI agree. There's some good information in the article, but 14kb web page is a poor example. API requests would be a better example.
- tonymet 1y agoIt’s extreme. But you can still apply to UI. Getting initial paint elements under 14k is good. Eg index.html with the css needed to draw .