Self-imposed 14 kB limit on my website

Designing a website to obey the 14kB rule & be fast

After reading the endtimes devs write up on the 14kB rule I thought it would be interesting to apply that knowledge and make a test blog/site.

The 14kB rule is for the first transmission control protocol (TCP). The rule usually only apply to the HTML of a page put I thought why not push it for everything on the page. So the main components to consider on any page can be boiled down the simple building blocks, and we can build up from there.

So we should be counting the bytes of each page if we want to see any real advantages over a large amount of pages. There are some basic Types we must consider if we want to reduce the size and increase the speed of the page. From smallest to largest is favicon, HTML, JS, CSS and images.

The favicon is a simple and easy place to start. It may seem weird to start with the favicon image, but I think it helps show the difference for one single item first. The favicon can be an SVG and or ICO file type with it better to have it an SVG and an ICO as a fallback if not supported the size should be around 324B to 500B, but this is heavily depended on the style of what you want to display. Some websites do not have a favicon which is fine, but this depends on how you’re serving the page as it can return a 404 page instead of the favicon which now becomes the size of that 404 pages which for some pages can be many KB just to say nothing.

The possible things you can do just with HTML could be an entire thing on its self but for this discussion, is the first point were a lot of work can be done to reduce page size. This depends heavily on the size of the page and the desired contents you wish to display, but we can control some aspects to help reduce the load time and the transfer size. Most of the improvements to size reduction can be achieved by automation, depending on what you use to make the webpages I am using HUGO, which includes minifying as an option

Minifying is a simple tool that can be used on the generation of the HTML to remove whitespace and repeating text. Leading to a reduction in size.

Java Script

This is the easy place to reduce the size of webpages, as with the use of many frame works it includes a lot of unused packages and dependences that are not need or used. So the best option is to really see what is need for that page with most of the pages only truly needing a static site approach were most websites do not need JavaScript. You may see that this very website uses JS so what gives, this website could be just a purely static site. And that is correct, but Its use on this site is only for the view and is not needed for the site to operate. The main three functions given to the JS which are to remember the dark mode selected, cached-image reveal and to pre-catch other pages on the site. Each of these functions are to help the user to have a faster experience navigating and to convince of automated dark mode. But the site does not need it to function and that’s the trade-off, the user downloads 2.76kB of JS for the first load and that is cached across the site.

The image enemy

Images take considerable amount of space compared to other webpage resources so shrinking them down as much is possible is key to even consider reaching the 14kb.

The first step I took was to make a use the HUGO’s automated image handle with the assets’ folder. As you can place any image you want into the page and HUGO when building the site can automatically convert the images for you which is needed for growth of the website and my sanity. So with the basic automation we have a smaller web image made from the original which maybe the JPEG or PNG image. However, with this reduction of image size I am getting around 70KKiB per image which is fantastic for normal websites, but we want to reach the goal of 14kB per page. The answer was simply don’t. Make it a separate request, and make the image that we load a placeholder. As we are already automating the image convention we can also have it make a placeholder image as well. With some simple CSS blurring and heavy compression the placeholder image can be reduced to around 250B. Now that we are at this size we can now inline this into the HTML. Which we can also automate with HUGO.

Cached-image reveal Giving the user more control over the contents of the page is a double sword edge. As the user no longer needs to download any image if they do not want to however it is a layer of friction but to what level is unknown as the action is to simply click on the placeholder to fetch it.

The overlying architecture and the use of constraint for performance

The use of JavaScript was at the start avoided as it adds complexity to a static site which does not need it. But I then decided it could be used to make the experience seem faster rather than slower as it usually does on most sites.

  1. Remember the user’s theme
  2. Prefetch/cache likely next pages.
  3. Turn navigation into an instant main swap.
  4. Page must still function without JS.

Server side compression. This is the final step we can take to further reduce the size of the page by using GZIP or Brotli to compress the files before serving. This option changes depending on how you host the static site, which Cloudflare pages automatically picks and does this for you along with the images and other assets the page needs, but this all relies on the previous work we just did.

In the end of this did I reach the goal of pages under the limit of 14kB. Is this truly needed ? Most likely not, but it was intersting.

Reference https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/