A 14kb page can load much faster than a 15kb page
endtimes.dev
endtimes.dev
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.
[2] https://github.com/GoogleChrome/lighthouse/issues/10023#issu...
Yes, much better. And given prevalence of UTF-8 this days, why not just hard-code your webserver to add such header everywhere:
- Apache
<VirtualHost ...>
<Directory ...>
AddDefaultCharset utf-8
...
http {
charset utf-8;
...
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.
Also, you could asked all your questions without being incendiary and making assumptions about why people like Caddy. Nobody mentioned Go except you.
certbot --nginxWhat about HTTP->HTTPS redirection, etc?
Same for secure cipher selection.
All of that Caddy gives you in 1 line of config (i.e. domain name)
If we allow your example, then caddy wins hands down because it also makes me rich because it fronts the websites that make me money.
But that would be ridiculous thing to claim Caddy does, because it doesn't do that itself.
nginx: https://github.com/shepherdjerred/servers/tree/8688ba2086d87...
caddy: https://github.com/shepherdjerred/servers/tree/main/zeus/con...
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.
(And Caddy is an excellent choice for production. Or so says the many companies now powering half a million sites with it!)
With the announcement a couple of days ago that the commercial nginx folks are embracing OS again I might take another look.
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.
"Caddy is a powerful, extensible platform to serve your sites, services, and apps, written in Go"
That could confuse developers thinking they can only develop apps in Go with caddy?
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.
For others wondering how:
about:config
gfx.downloadable_fonts.enabled (set to to FALSE)
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.
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).
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.
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.
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?
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...
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).
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.
Coincidently, AWS also launched in 2006.
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.
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.
But this may apply on a smaller scale too. For Amazon, it's giving people less time to rethink their impulsive decision.
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.
These are older anecdotes, but there's no reason to think that people have gotten more patient as internet connections have become high-speed.
https://www.contentkingapp.com/academy/page-speed-resources/...
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.
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?
However if your site is at 1800ms range it's worthwhile to increase to 1200ms range
[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...
(Edit: it's 36 ms with a connection already open. From scratch, it's about 176 ms, still extremely impressive.)
Here is a list to show how bad (and sometimes good) they get:
I maintain this so let me know if any news sites I should add!
I would suggest adding Al Jazzera.
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!
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.
""
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.
Load up the OP's page with Chrome dev tools network tab open.
Connection start: 90ms (60ms of which is SSL handshake) Request/Response: 30ms request / 30ms response
So the whole post is about yak shaving not splitting the 30ms response portion of a request that already takes 5x that (150+ms).
Sure it's a bit faster, but your users will not notice the difference between a 14kb page and a 15kb page over https (which you hopefully have on).
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 :).
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.
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.
EDIT: yep, as posted above: https://news.ycombinator.com/item?id=32588850
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
[Edit] I should also add that changing these values may require different methods depending on the distribution. [2]
[1] - https://www.kernel.org/doc/Documentation/sysctl/net.txt
[2] - https://serverfault.com/questions/546523/linux-initcwnd-and-...
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.
[1]: https://plaintextsports.com/all/2022-08-24/
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.
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.
https://stackoverflow.com/questions/17015611/how-to-disable-...
Oh ok, but then is it really breaking the standard as OP claims?
https://blog.cloudflare.com/when-the-window-is-not-fully-ope...
I recently wrote a piece about specifically this mechanism (though looked from the receiver side).
Basically on linux you can work around this initcwnd limit (if you have to, for whatever reason), by tuning buffer sizes, initcwnd obviously, and rcv_ssthresh.
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.
I could easily see 95% of internet could be 150KB page on first load.
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.
I remember 10 years ago this being a thing and google keeping theirs at 14kb.
Today, if not server side rendered, you'll need react lib or equivalent to load your site and boi, that's a little over 14kb.
Delivery in 78 years [1,2]
[1] https://bowtieduck.com/traditional/kurimu-x-the-bow-tie-duck...
Edit: So it turns out it is not duck you’re selling.
FTFY. That is why they are packed full of ads.
(Shameless self plug: https://anonyfox.com/blog/need-for-speed/ )
However, just page size is half the story.
Look at the screenshots below -
#1 - Here you can see this page (9KB) - 110ms - https://i.imgur.com/qeT2Az0.jpg
#2 - Another page, 29 KB in size - 42ms. https://i.imgur.com/tWsLGr1.jpg
Both on same network (Internet), same computer.
1st one (This article) is served by Netlify and AWS (Static hosting).
2nd is an ecommerce store on Dukaan (ecommerce platform for India), I am affiliated with.
If a country includes the word "Democratic" in the name, it probably isn't.
If a website says "We value your privacy", it probably doesn't.
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.
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.
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.
https://www.tunetheweb.com/blog/critical-resources-and-the-f...
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.
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 :-)
The IPv4 overhead is normally 20 bytes but can reach 60 bytes with many options. For TCP, it's between 20 and 60 bytes as well.
Just ran a quick tcpdump on Linux and curl's TCP connection uses 32 bytes TCP headers (12 bytes of options).
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 ?
Check out the page in the web inspector! Simple websites have the bonus of being easy to poke at.
A more realistic target: https://512kb.club/
I still use it.
So, sure, this is awesome but it might not be something worth optimizing for if you want to make money.
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.
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!
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.
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!
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.
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...
Doesn't seem to make sense as it would increase overhead, I can only see it happening at the edge for IoT devices, maybe.
uses
>This this maximum is not set by
Double this
Where does the 10 suddenly come from?
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.
Edit: I wrote this after reading some comments. The article is interesting and not an attack on its author.