> 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 :).
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'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.
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?
> 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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
> 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.
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
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!).
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.
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.
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
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.
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).
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 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.
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.
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.
> 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
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?
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.
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.
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.
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.
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".
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.
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.
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.
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.
> 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.
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).
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.
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).
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).
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.
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
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.
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.
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?
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.
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.
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.
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.
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.
355 comments
[ 0.18 ms ] story [ 380 ms ] threadOf 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 :).
https://tools.pingdom.com/#60b4b3d98d400000
""
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.
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?
> 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.
Guidelines: "Anything that good hackers would find interesting.".
Also, it's not a problem with the original article, it uses units correctly - it's a problem with the title, and with some comments.
Also known as evolution.
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.
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.
https://developers.google.com/search/blog/2022/08/helpful-co...
Good to hear. But whether Google can achieve it is another thing.
Quotes I like:
"content created primarily for search engine traffic is strongly correlated with content that searchers find unsatisfying."
No shit! I hope some of the websites I've worked on get signaled up the rear end! I've warned site owners not to use too much SEO content, but the forces of copy-cat SEO tactics are stronger than individual developer advice.
"Are you writing to a particular word count because you've heard or read that Google has a preferred word count? (No, we don't)."
I wish Google had been more plain speaking in the past about this. Better late than never I suppose.
(Disclaimer: I worked on optimizing this story template awhile back)
https://restofworld.org/2022/right-wing-osint-propaganda-in-...
It’s by no means 14kb but represents trade offs on performance and design.
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.
> HN could put the CSS and JS into the generated HTML file and still stay under 14kB
At the expense of caching those resources that stay static. With http/2 the benefit of merging into one resource should be negligible anyways.
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.
When I open a reddit page on mobile, I usually open it in a new tab to give the browser time to load it. When I open a HN page, it's instant.
https://imgur.com/a/hg1gp0a
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.
[1]: https://plaintextsports.com/all/2022-08-24/
[2]: https://plaintextsports.com/wnba/2022-08-24/conn-dal
[3]: https://plaintextsports.com/mlb/2022-08-24/laa-tb
There are lots[1] of small, "class-less" CSS libraries that would keep your site as small (or smaller, with tree-shaking in a modern build system) and it would end up much more user-friendly.
1. https://css-tricks.com/no-class-css-frameworks/
It fits nicely into the smol web
I think you are! It's less work to keep it simple, than to make it heavy then try to pare it back.
[1] https://en.wikipedia.org/wiki/Teletext
HTTP/3 formally replaces TCP with QUIC.[0] Google have been using QUIC in production for quite a while (since 2013!) and it’s enabled by default in every browser except Safari[1] so it’s understandable how there could be some confusion here.
[0] https://datatracker.ietf.org/doc/html/rfc9114
[1] https://caniuse.com/http3
EDIT: yep, as posted above: https://news.ycombinator.com/item?id=32588850
[0] https://datatracker.ietf.org/doc/id/draft-ietf-quic-recovery...
Basically QUIC avoids a case where your image #2 waits for image #1 (head of line blocking). It loads both images in parallel streams. In classic HTTP, TCP was asked to load image #1, then it was asked to load image #2 and TCP have to provide responses in order. So even if a single TCP segment of image #1 is lost, image #2 will have to wait. Browsers try to open multiple TCP connection to avoid head of line blocking, but there is a limit to that.
QUIC also combines TCP and TLS handshakes, so initial latency should be improved somewhat
[1] https://datatracker.ietf.org/doc/html/draft-ietf-quic-recove...
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.
Many sites today will load 10MB of JS and custom font crap alone, just to show a few paragraphs of text.
I don't think the point is the size itself, but it's the content vs. bloat ratio.
If it’s a gallery photo for a site promoting a photographers skill or library, nah…
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.
In the US as of 2020, it was 3KG CO2 per GB Data.
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.
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.
> Bandwidth is extremely carbon intensive.
and the reasoning that supports that statement.
Given that they could be streaming 1080p video instead, I think viewing a few photos is a relatively harmless hobby
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.
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.
Original image: https://0x0.st/o9x5.png
JPEG (200 KB): https://0x0.st/o93i.jpg
AVIF (100 KB): https://0x0.st/o9xC.avif
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.
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.
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.
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.
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.
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:
https://afontenot.github.io/image-formats-comparison/#air-fo...
https://afontenot.github.io/image-formats-comparison/#citroe...
https://afontenot.github.io/image-formats-comparison/#festa-...
Document-Policy explainer: https://github.com/wicg/document-policy/blob/main/document-p...
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.
Someone should invent an HTML tag for putting images on a page.
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.
https://stackoverflow.com/questions/37940282/changing-the-st...
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.
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.
The only annoying thing about turning off fonts is the weird settings ProtonMail and GitHub use.
https://prnt.sc/zoPQiiPKIeZy
For others wondering how:
about:config
gfx.downloadable_fonts.enabled (set to to FALSE)
https://simonhearne.com/2021/layout-shifts-webfonts/
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.
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".
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.
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.
edit: No, it's not. It deals with TCP window but 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.
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.
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?
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).
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.
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
Visitors will simply block them :)
The HTML itself is several hundred kB? Something’s very wrong there…
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.
Check out the page in the web inspector! Simple websites have the bonus of being easy to poke at.
Delivery in 78 years [1,2]
[1] https://bowtieduck.com/traditional/kurimu-x-the-bow-tie-duck...
[2] https://ibb.co/W5B50d8
Edit: So it turns out it is not duck you’re selling.
FTFY. That is why they are packed full of ads.
I still use it.
So, sure, this is awesome but it might not be something worth optimizing for if you want to make money.
Edit: I wrote this after reading some comments. The article is interesting and not an attack on its author.
edit: nevermind, svg is 13kb, don't know what I was mistaking there.
[0] - www.reciped.io
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.
This is really interesting, and would be pretty easy I think. I'll look into this.
Though if you're using vue3, I think tailwind or fontawesome will have better methods.
https://tsk.bearblog.dev/