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.
English is my second language, and the comma separating that particle from the rest of the sentence makes it pretty explicit even for me that it is talking about the platform, at the same semantic level as “powerful”, “extensive” and “to serve your sites […]”.
Yes, but the incongruousness of telling me what language something is written in in its sales one-liner makes me think it must be pitching itself as "especially for apps written in Go", because who thinks I am going to pick a tool because it is written in Go? "Try ElasticSearch, written in Java!"
I avoid new server software written in languages with too many footguns such as c or php. Nginx gets a grandfather exception, but I'm not sure I would have extended one to caddy.
> 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.
Have you used Caddy for reverse proxying compared to nginx? It's infinitely easier. Two lines per site, https built in, dynamic upstreams are handled by default, HTTP 2 enabled (maybe nginx does HTTP 2 by default,; not sure).
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 have a feeling you're think we're attacking nginx. I can't speak for the other poster, but I have huge respect for nginx. It's a great piece of software and it's what I'd reach for in production.
I'm not sure that Caddy is a good choice for production, but for my hobby work it is just so much easier to use.
I looked into nginx as a replacement for Apache a few years ago and gave up because of the weird dichotomy between open-source nginx and commercial nginx. There seemed to be a lot of FUD about the OS version coming from the commercial people so I moved on.
With the announcement a couple of days ago that the commercial nginx folks are embracing OS again I might take another look.
The paid version (nginx plus) has a few additional features that you often end up needing/wanting (the dashboard for example, for ops users) in enterprise environments.
For what its worth, I switched from nginx to Caddy years ago and haven't looked back - Caddy's built in support for LetsEncrypt and zero configuration for the most common reverse proxy scenarios is just too compelling to ignore now - the speed and ease with which one can throw up an SSL front end with valid letsencrypt cert is amazing.
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.
Even for media focused websites, this 14KB rule is probably still worth following.
Not for the whole web page, obviously. But you should still be aiming to maximize the impact of that first 14KB.
Ideally you want to deliver enough for the first layout and paint, so that someone can quickly see the frame of the webpage and then you want to minimize the amount of visual changes caused by subsequent data. Ideally the first 14KB should be enough to do the final layout. It might not have any images, but the dimensions of images should he hardcoded in the html or css so the layout won't reflow as the images come in.
Maybe it's worth putting in placeholder colors behind the images that complement the general color scheme of the image and make the load less virtually jarring?
And if 14KB isn't enough for the final layout, the bytes need to be prioritized for "above the fold", to maximize the chance that any layout changes happen off screen where the user hasn't had time to scroll to yet.
This block post is perhaps a little absolutist in it's title. But the advice seems useful for everyone and people shouldn't give up just because there is no way they could possibly make their pages small enough.
Even if not media focused, Is 14KB possible with modern web JavaScript frameworks? Asking as someone who builds only text focused web applications with very little vanilla JavaScript if absolutely necessary.
Is there number, data, lab test session that proves it's worthwhile ? I sometime feel like these are all KPI detached from conversion but since it can be measured we do measure it.
You can easily do a very simple test yourself to see whether (and in which cases) this is worthwhile:
In your browser, open dev tools, go to the network tab and enable throttling. For fun, set it all the way down to GPRS speed.
Next, refresh that blog, you'll nearly instantly see the web page.
Then, refresh the HN home page, quite quickly, you'll see the list of articles in a bare-ish HTML page and a little later it becomes pretty when the CSS is loaded.
Finally, open any modern news site, since a news site is supposedly text-centric, it should be a fair comparison. I picked CNBC and it took 30 seconds for the first text to become readable.
I live in a country with ubiquitous broadband and near full coverage of 4/5G mobile internet, so for my country, this is a non-issue. Because of this, one of our most popular news sites takes nearly a minute to become readable at GPRS speeds. When I visit more rural areas in other European countries, this leads to me being unable to visit most web sites that were made for my country and it's extremely frustrating. Especially if you're in a bind and quickly want to find some information, because Google also takes ages to load over slow internet and is nearly unusable (and so is DDG, in case you want to try an alternative).
> in no way does it deal with customers conversion, retention rates and all those things.
Those metrics would only be meaningful if the average visitor knew how fast websites and computers can be, and if there are well-known alternatives to your site. Having standards is preferrable to aiming for mediocrity imho.
YouTube probably has decent retention rates but it's a bloated pile of UX hell that people use for a lack of alternatives. Maybe that's why Google manages to make it even worse over time without realising they're digging a second Mariana trench of quality.
> Those metrics would only be meaningful if the average visitor knew how fast websites and computers can be, and if there are well-known alternatives to your site. Having standards is preferrable to aiming for mediocrity imho.
Of course visitors don't care about commercial and marketing metrics.
They clearly rely on other metrics to decide whether or not visit or stay on a site. And my question still stands: who has numbers or data that show that those 14kb pages perform better in regard to the commercial metrics than heavier pages ? And I mean in the field data, not a synthetic test.
> And my question still stands: who has numbers or data that show that those 14kb pages perform better in regard to the commercial metrics than heavier pages ? And I mean in the field data, not a synthetic test.
A trivial search will find you tons of heavily reviewed research that shows web page performance directly impacts e-commerce conversion/sales and this is widely known in the industry. This article laid out a solid technical explanation for why staying under 14kb can have substantial improvements in performance. You refusing to see the connection there, or are you disputing it?
It will vary between industries and target markets. The best thing to do is a/b test it by synthetically giving your customers a slow loading page and seeing how it affects your metrics. I’ve only worked one place that was brave enough to do this and client loading speed was highly correlated to conversion rate.
I'm using icon font to show a grid of icons, where each icon can be clicked to toggle it "on" or "off". Example: https://i.imgur.com/EHYHVDw.png
When I was implementing this, I initially experimented with the img tags – easy to implement, easy to have multi-color icons. But the grid can potentially have 100s of rows, potentially resulting in 1000+ of img tags. When testing with img tags, my site became noticeably sluggish (on a quick desktop PC). With icon fonts, the icon grid is basically lines of text, and the browser can render it with no noticeable performance impact.
I write a framework, not an app. In any event, I need to allow others to style my icons with their own colors. Hence I use a font. Is there a way to use SVG sprites or something, while also letting people control the stroke color with css? Seems yes: dont put CSS in the svg. But why not just use a font?
Yes, you can even put `color: currentColor` in your SVG file and then color it exactly the same way as your fonts (it'll use the current text color).
Why not? I don't know, you're asking the wrong person, I use a CSS font too. My reasons are (a) last time I looked into putting SVGs into a sprite-map to avoid 1000 HTTP requests it was a shitshow (not well supported), and (b) Chrome and other browsers would sometimes align the SVG on a half-pixel causes the edges to be a little blurry, whereas fonts get special treatment to ensure they are crisp. That was years ago tho.
If you can create a customized font file that is tiny and only has the icons you actually use, sure.
But the "wrong tool for the job" point still stands, users with custom fonts disabled (for performance or accessibility reasons) will not be able to see your icons.
Thanks for the tip! For others wondering how you can do this, go to Settings -> Fonts -> Advanced, and uncheck "Allow pages to choose their own fonts...".
What's the substitute to not using custom fonts? Or is there a better way to load it? I'm having a hard-time convincing our brand team to defaulting to a system font.
For most things just using the user's configured font is almost as good, if not better. For cases where you really want to make something stand out custom fonts can be nice but you can also try using "font stacks" that the user has already installed.
In general I recommend using the default font for "body text" because you know it is something that the user finds easy to read. For headings, buttons and smaller strings of text you can be more creative but even then you can consider things like trying system fonts first and deferring the custom font load until after the content.
> In general I recommend using the default font for "body text" because you know it is something that the user finds easy to read.
A lot of users don't know how to or can't change the default font. For instance, I have no idea idea how to change the default font on my phone, or even if I can. It's probably better to say "at least you know it's something that was selected to be at least tolerably usable by most people, which cannot be said of the design team's fancy spindly small-x font".
Convince the brand team to pick a couple fallback system fonts and swap the brand font in after it has loaded.
You will have a bit of content reshuffling no matter what you do but it's better than the alternative.
There are directives to do this in pure CSS but I seem to remember they had some unfortunate implementation bugs so when I did this it was easier to do it in JS.
There is some interesting things you can do with font-display and other css properties. E.g hide text for up to 100ms, if custom font has loaded swap to it, if not use fallback font.
This is simply false, even if you mean using AVIF.
Here's a test case, using a moderate sized (3000x2000) image. Nothing ridiculously huge or anything, and it's not an especially complex image. I'm linking the best I can do for both JPEG (at 200 KB) and AVIF (at 100 KB). If you can create a passable versions of these images at 100 KB with either codec (or WEBP for that matter), please do show us how.
Maybe JPEG XL will get us closer, but not all the way there, that's for sure: https://0x0.st/o9xd.jxl - JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage.
> JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage.
It's better than AVIF at low bitrates. I did a comparison of the latest builds 3 months ago, and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p). It's a bit subtle, but I could see it. Once browsers ship full support (at least Firefox + Chrome), I'll be on board.
> and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p)
bpp = bits per pixel, not bytes. At 1080p, "0.05-0.1 bpp" is 13-26 KB. Much smaller than what you were testing. Might want to recheck your sizes, if you are actually looking at 0.5 bpp it would not surprise me at all that you found JPEG XL superior.
At very small sizes like 0.1 bpp the results are debatable, but I think AVIF is a pretty clear winner if you aren't too bothered by blurring. Samples at 0.15 bpp:
I tried it out on my own site, and through trial-and-error I found that Chromium does in fact treat the "max-bpp" Document-Policy directives as bytes-per-pixel.
I could be wrong; my memory has faded. Please correct me if this is the case.
I'm not sure what HTTP headers have to do with anything. Using "bpp" to mean bits per pixel is extremely common in image encoding. See e.g. https://en.wikipedia.org/wiki/Color_depth where an uncompressed image is often 24 bpp (8 bits per channel). It's also common to use bitrate (rather than byterate) in audio encoding, see e.g. https://wiki.hydrogenaud.io/index.php?title=Bitrate
You replied to a thread about a photography website. I don't think 720p images are the norm for that use case.
In any event, I don't think the AVIF result at 250 KB is acceptable for photography either: https://0x0.st/o93a.avif - There's a ton of smearing and blurring that's very obvious when you're viewing the image at full size.
3000x2000 basically means "fullscreen on a retina display @ full resolution". You can only reasonably show one picture like that at a time. So it's completely OK to have the currently displayed picture at that resolution/size.
But all photo should be loaded at a much lower size, initially, and only downloaded at full size the the user puts them in full screen.
I know lazy loading is in vogue, but as a user it only ever seems to create problems for me. I’d much rather the website download all the images ahead of time on page load, so I don’t have to wait for full quality versions each time I full screen a different image.
This is the restaurant equivalent of : "We are at an all you can eat buffet, let me take 10 plates even if I only realistically will eat 4, so that if I want any more I don't have to stand up again".
While the other way (loading each image as you view them, or lazy) is functionally equivalent to waiting in line for each separate dish, which isn't quite so fun.
Maybe gallery sites could consider offering a preference to load all images upfront if you intend to view them all.
A good example would be housing sites, where viewing higher quality photos of each listing is a primary use case.
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.
We create 40kg of CO2 a day each through our diet, transport, consumption and other energy use. The idea we need to target our energy burden on Internet routers is absurd.
I lament the day this becomes policy to regulate average internet usage due to a few religious fanatics who fail to understand that higher levels of CO2 enrich the Earth, and that science has been sabotaged to suit political ambitions fueled by fear porn.
The US average is 15 metric tons and that's production-based, ie counting exports and not counting imports. If you count imports and stop counting exports it would be higher. Now the US does rank highly in this measure but that's also where the 'typical' HN reader is. The typical reader is also well off which can make a huge difference(flights etc).
The bandwidth used for single images is dwarfed... massively by streaming video content... I don't think it's a use case that is worthy of excessive time/effort to optimize for size because of bandwidth cost/effects.
edit: I'm not saying don't do it if you can get away with a smaller image dimension, or do basic optimizations... but if your concern is the environmental impact from a simgle high-resolution image from a photography site, you're putting the emphasis in the wrong place.
I don't agree with the reasoning presented.
It takes the estimate for the amount of energy that it takes to run the internet infrastructure and clients (141GW * 8765h in a year = 1235865 GWh), divides it by the amount of data transferred yearly (241 billion GB) and gets to 5.12kWh/GB.
You might argue that if people download more data, more equipment needs to run to enable it, but really all this energy consumption is happening regardless of my PC being idle or saturating its fiber pipes with torrents. If your website weights 14kb, all this same equipment needs to be on for my PC to load it.
The website usage on the client side is more to do with resource usage. Unnecessary usage of Javascript is often what makes websites laggy.
You computer will normally down-clock (you can turn this off in the bios) when under lighter loads.The difference between a JS-free webpage and a bloated web page that uses multiple JavaScript with extra Javascript for ads and tracking could be around 10W/H to 40W/H on Desktops.
Maybe, or maybe the new equipment is much more efficient than the one it's replacing. It sounds true, but you can't really tell if it is or not, and really my annoyance is in saying it costs any estimated amount of energy, or carbon, to transfer 1GB of data. It does not, the transfer itself is basically cost-less. What costs money is running the infrastructure that makes it possible, and that's much harder to measure.
What matters is the marginal consumption. It should be really small. Averages don't mean much. I can download one GB of Data for almost free, I doubt I would burn 3 kg of CO2 doing that
Yeah if you're trying to fit the WHOLE web page into 14kb.
But you can get ALL the text there and have the images load in after. The first time I used a the static site generator Gatsby I was super weirded out by the blurry image that showed up upon first load of an Img. It will quickly resolve into a full quality image, ofc, but the point is a relevant metric is also time to first contentful paint.
Also the JS will load the rest of your pages while you're idling on the first page, so that's nice. It's not just good enough to have lazy-loading content, your strategy will have to change depending on how users use your site. Let's say 99% of people scroll to the right in a circular gallery of pictures. You should only really load pictures to the right.
Optimize your images ( use imgix by example or thumbor ( open source version) . Lazy load the images below the fold. For the images above the fold, use 103 Pre Hints headers ( as well as for your css and js). Make sure to inline your critical css . Use http2. Your website won't be much lighter ( picture will be ), but it will be way faster.
I dont really think it matters as long as all resources are present to layout the site (html, css, synchronous js). As long as the img tag have width and height specified so they dont cause a reflow when loaded, i dont think it matters if they load a little later.
Tell me you didn't read the article without telling me you didn't read it.
The point is to have your initial page load under 14kB to get the most utility out of the initial TCP window size. It doesn't say you need to have an entire site fit into 14kB.
With GZip compression you could easily get a 50-60kB HTML document under 14kB. In 50kB you can easily have OpenGraph metadata, links to alternate representations (RSS etc), link/script tags for external styles and scripts, some base level inline CSS, and some actual useful content. In your initial 14kB sent over the line you can tell the consumer everything they'll need to load the rest of the page's content.
If the content is a blog post or news article it would not take too much effort to fit all of the text content into 50-60kB and progressively enhance it with CSS and JavaScript with minimal content repaints. A few lines CSS in a style tag will give you perfectly readable text content and allow for images and such to load without repaints.
Even an image gallery can have a useful 14kB initial load with img tags containing a height and width and single line of CSS to give them some default background color or pattern before an image loads. Even if you want to do a bunch of stupid effects that can all be done with JavaScript loaded after the initial small TCP window loading.
The idea is to give a browser something useful in the brand new connection so it can start loading and rendering. If the first few packets contain a usable scaffold of a larger more involved page, even users with shitty connections can have something besides a blank page to look at. Done right they could have an actual useful page even if none of the extra content loads.
I don't think a site where the key content is large (relative to text) can be expected to deliver that content super fast.
However, quickly loading the bulk of the website and perhaps having a placeholder for the image that has yet to load will still make the site better. I remember seeing something that allowed you to create really blurry placeholders that are tiny, but I can't find it now.
Even for text-centric sites fitting everything in 14kB is not always feasible if you use custom fonts. My site is text- and math-centric, but it uses some fonts (Crimson + bold and italic variants, plus the KaTeX fonts used for math). Each font is about 30kB big for a total of 180kB.
I would like to improve, but I feel like the fonts are essential for the look and feel, so I'm not willing to give up the fonts, so I guess the ~200kB is the lower limit for me.
(Of course, the fonts are cached on the next page load, so my site does load very fast after opening the first article. Only thing that bothers me is the layout jump-around due to font
That's correct, but it's important to keep in mind that JPEG XL is tuned for high quality images. If your baseline is heavily compressed JPEGs or AVIF images, switching to JPEG XL might save you nothing at all. However, if you're starting from 4+ MB high resolution JPEGs, and looking to save bandwidth while keeping the same quality, JPEG XL is vastly superior to anything else (including AVIF and WEBP).
JPEG-XL is not really any better than WEBP. You need to be using AVIF "significantly smaller", just a shame that Google's online AVIF compressor sucks so-much (Wrong compression mode and uses the AV1 default artifact blending (Chroma Sharpening which is not really sharpening or even just for Chroma but actually sets the artifact blending. 0 is default for AV1 and tries to hide all artifacts, increasing to 3 which shows all artifacts).
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).
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.
most satellite internet users won’t give up just because your page is slow
My point is that 'slow' is a relative measure against other websites, not an objective value. So long as your website is faster than a typical website then users won't give up. Trying to be faster than average is worthwhile, but trying to be as fast as possible might not bring any additional value.
It's also possible (likely, in my opinion) that the website itself is important too. People expect Google to be fast because it's made by the biggest internet company there is, and perhaps because the page itself is very simple. It's just a textbox on a page. Surely it should be fast. That doesn't mean people have the same expectations for grannys-discount-wool.com.
This is a complex problem that probably doesn't have a straightforward answer. Using the mantra 'make your website as fast as possible' means you won't get it wrong, so it's worth doing, but you almost certainly get diminishing returns for that effort as you optimize for things like shaving off milliseconds and bytes.
Unless you're Google.
Although... that said... if Google really thought sites should be as fast as possible, wouldn't they make a smaller GoogleTagManager.js script?
This is a complex problem that probably doesn't have a straightforward answer. Using the mantra 'make your website as fast as possible' means you won't get it wrong, so it's worth doing, but you almost certainly get diminishing returns for that effort as you optimize for things like shaving off milliseconds and bytes.
Yeah, that's fair. My point (really just repeating hearsay -- I should check that Google research still stands up!) is just that load time optimization apparently has a bigger benefit than you might expect, and the diminishing returns don't kick in until much later than you'd expect. Edit to add: and the post being discussed has a good point that there's a performance shelf at ~14KB, so a small improvement can have a big impact.
Although... that said... if Google really thought sites should be as fast as possible, wouldn't they make a smaller GoogleTagManager.js script?
A good question! They're definitely not the most consistent. The left hand says one thing, some of their thousand right hands do the exact opposite...
Might be a competition thing. It would take a big delta in time-to-load for me to switch from Google to Bing. But if wsj.com takes 1s more than cnn.com maybe next time I pull out my phone on the train I'll switch publications.
>My point is that 'slow' is a relative measure against other websites, not an objective value.
No, it is an objective measure that is rooted in human biology and psychology. Our perception of HCI is based on various response time limits, that define whether we consider interactions seamless or retaining our attention. For the websites those response time limits are often hit in various circumstances, even in urban areas of developed countries (e.g. poor cellular network coverage in a building results in reduced speeds and higher bounce rates).
>My point is that 'slow' is a relative measure against other websites, not an objective value. So long as your website is faster than a typical website then users won't give up.
You're competing against more than other web sites, and data shows this isn't true at all in any case. There are certain "thresholds" beyond which users will stop visiting much more frequently, but yeah.
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.
Was it linear though? I understand how you can lose 50% revenue by 5 seconds delay per click. But thinking that this has no “breakpoints” is naive.
Also, personally when shopping for e.g. jeans and tshirts I’d rather just wait for all items (json) and thumbnails to load (they can do that in bg except for the first page) and then filter/search/pagination would work instantly. You can lose half a hour in total by dealing with these shitty filtering sidebars which reload everything every time. Why aren’t e-shops then just semi-local apps over an on-demand synchronizable full-blown localstorage db? Nobody does this sort of precaching. Do they know how much revenue they are losing? It doesn’t add up.
That's a claim that they made in 2006. Could there be a reason why Amazon said that a slow website would have a massive impact on ecommerce sales back then? Was there some other Amazon product that would greatly benefit from people believing they had to use the fastest hosting service possible for their online store?
Well then, since Google these days is slow as hell on slow internet, I guess users with slow internet are no longer important.
When trying to find something on Google while visiting smaller towns in Germany, it's often down right unusable. Then again, I've been used to broadband and 4G for many years now.
Page / ad impressions is another metric for google; that's one reason why they have made such big improvements in the speed of internet and browsing with Chrome, their own DNS, HTTP/2 and 3, etc; the reasoning being that the faster people can browse, the more ads they will see, the more revenue Google gets. And it bought them a lot of goodwill.
But this may apply on a smaller scale too. For Amazon, it's giving people less time to rethink their impulsive decision.
At one of my recent jobs (EU-wide consumer healtech) we managed to reduce bounce rate by addressing a number of issues indicated by DevTools, mostly focusing on time to render and time to interact. It indeed positively impacted conversion and I guess this is a common knowledge among marketing teams by now, that this works.
I think it's fairly obvious that a faster website is better. I'm not disputing that. What I'm saying is that there is a point where improving your website when it's already better than competing websites stops giving you enough value to be worthwhile. If you're in the bottom half of websites then you're giving up money and you need to improve. If you're in the top half, or top quarter, or whatever then maybe that engineering effort could be used to generate more revenue in more effective ways than just cranking up perf.
You could probably improve speed forever and always see a measurable improvement, but if that's costing more than you're seeing in added conversions, or you're doing it instead of improving features that would net a greater return, then you're doing the wrong thing.
>What I'm saying is that there is a point where improving your website when it's already better than competing websites stops giving you enough value to be worthwhile.
There's indeed a point where optimizations stop yielding meaningful results, but it is certainly not connected to the performance of competitor websites. As soon as an user lands on your website, only its own performance and accessibility matters and positive ROI can still be achieved well beyond the point when your start doing better than competition.
Where did you get this idea about competing websites from?
Not competing website but other average website in general. Say that averagely HN load for 1000ms and it's positioned around top 15% fastest. And if your website load for 1100 ~ 1200ms will be okay. OP's point is, if you're able to speed up to range of 800 ~ 900ms it may not resulting in much higher conversion.
However if your site is at 1800ms range it's worthwhile to increase to 1200ms range
I don't think that it works this way. If bounce rate matters for you, because your website is part of sales conversion funnel, then you do not benchmark against random "average" website like HN, because you do not build your site the same way, your audience is likely different from many different angles and you cannot really measure the response time under representative conditions (because you likely do not know them). The only sensible benchmark you can have is the performance of your own website. It makes sense to collect some low hanging fruits, but further optimizations generally make sense when you have enough traffic to reach statistic significance in A/B tests. And those tests will not always result in more optimized version, because content matters too and better content may outperform faster version in terms of conversion, so it will often be two steps forward and one step back.
> 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.
Seeing things like "SportsShoes.com found that faster-than-average mobile visits were 41% more likely to convert than slower-than-average visits." suggests I might be right...
Back in 2006, Amazon found that every 100ms of delay cost them 1% of sales. Google similarly found that a 500ms increase caused search traffic to drop 20%.
These are older anecdotes, but there's no reason to think that people have gotten more patient as internet connections have become high-speed.
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
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!
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.)
Any recommendations for running a blog efficiently with posts that include images? I've cut my website down to some very basic styling, but since it's a personal blog, my picture is on the front page. That picture takes up more space than I'd like, but I feel like it's important for readers to see me on the front page.
Maybe I should just remove it? But I still have a lot of blog posts that include multiple images, and I don't want to reduce them to tiny thumbnails -- they're nice photos!
IMO if you want a personal pic on your blog it could make sense to move it to your About page.
For actual blog posts/other content that contains pictures, it makes sense that those take up more space than 14kb - probably nothing to worry about there.
If you can, it might be good to try ensure you load the images after other aspects (CSS, HTML text content) are loaded, per the blog post. But all in all it likely isn't a big issue.
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.
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.
> Folks, tomato is a fruit, celery is a vegetable. As someone who deals with botany, the careless use of...
> And whenever someone writes something not very obvious (eg Fruit salad for apples oranges and grapes...
One day, people will learn that their specialised understanding of terms, when not synchronised with an entire world of users, need to be viewed in the lens of the audience in which it sits.
In the layperson's sphere, even to the technical professional, the counting of bits is incredibly rare. The fact that the telecoms industry has crafted this case-based confusion is (naively) foolish or (cynically) immoral.
If you're not willing to presume that articles by the layperson are likely to be referring to bytes unless otherwise clarified, unfortunately that unwillingness is where the problem lies - not with the people using the language as shared with the 99.9% of the rest of the world.
That said, you do have our sympathies for your confusion. There are lots of words that our industry have introduced to the world and immediately lost the nuance of, and it will only continue.
Please, continue to bang the drum with your colleagues. Telecoms professionals should be completely precise where that precision matters. Here it does not - and the drum is just distracting noise.
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.
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?
The issue, I think, is that the web has become a kind of lowest common denominator app platform, which isn't really what it was originally designed for.
> 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 :).
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.
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.
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
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.
Sure, I’ll also go ahead and find the oldest possible version of Firefox compatible with my operating system, open several hundred tabs, and probably just unplug my router too while I’m at it
> 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.
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?
Or have the server adapt based on page size. Even if starting with 10 packets at a time is optimal when sending an arbitrarily large payload, it's probably not optimal for an 11-packet payload - just send the whole thing at once.
I don't know enough about web servers to know why the good ones don't already do this. I suppose it may be reading data from a stream where it doesn't know the size up front.
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]
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.
There is a reason for this limit. It is intended to avoid congesting the network and avoid packet loss. Yes, when you always yell your counterpart is a lot less likely to miss your message but don‘t be surprised if people around you get upset.
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".
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.
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.
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.
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.
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.
> 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.
I've been working on an implementation of Arc in SBCL which is much faster and also will easily let HN run on multiple cores. It's been in the works for years, mainly because I rarely find time to work on it, but it's all pretty close to done.
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.
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.
"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.
Tangentially related: 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.
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.
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.
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.
Nice site. I am also in a similar position, now rewriting our website to make it modern and fast. Like your site that its snappy, but found something odd.
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?
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
Slightly OT. Speaking of Reddit, I am genuinely curious, do developers of the Android app never test the app or something? I was nagged into installing the app (sorry, I am not as persistent as your typical HN user), but it is actually so much slower than the website, and the content usually just don't load altogether. To be clear, I am on very fast Internet.
Reddit is the only service I know of that seems to want to sell you ads, but also goes out of your way to make your life much worse.
If you've got a good amount of bandwidth available you should try Sync. It's an unofficial app but it's built around the ability to prefetch posts and comments. It seems to batch requests in some way, so when you've got a good connection you can get quite a lot of stuff loaded for when your connection dips later (i.e. a train).
That said, there's still more waiting involved than with visiting HN but that's probably because Reddit is much more graphics focused.
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.
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.
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.
In my rural unit in the densest area of Seattle, I routinely have to hold my phone slightly to the left or all network requests are a crapshoot. I also often have to force quit the browser just to resume any network requests. If your website requires that much hand holding, most people don’t know how to do it even if they know they need to or want to.
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.
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..
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!).
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.
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.
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?
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.)
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 :-)
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.
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.
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 ?
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.
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.
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?
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!
> 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.
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!
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.
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.
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...
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.
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.
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/
[2] https://github.com/GoogleChrome/lighthouse/issues/10023#issu...