Welcome to Beyond the Cascade

A blog focused on content and user first

Table of Contents

Introduction

For the past few years I have always wanted to start writing, but I never got around to it. I won’t even try to talk myself out of it, I was just too lazy and comfortable procrastinating.

With 2023 starting with my first ever workshop, I decided it’s time start writing and sharing my knowledge, thoughts and ideas about new CSS & HTML related features landing in browsers as well as accessibility, sustainability, performance and UI / UX related topics.

What is it with this website?

Although it may not look like it, I’ve put a lot of effort into developing this site. We’ll take a look at the technologies later, so let’s start with the most obvious part, the visuals.

While developing this site and getting some feedback from colleagues and friends, I was often asked what I was thinking when I created this design. Mostly I heard sentences like “It’s not very special” or things like “It looks boring” and yes, I totally agree that it is! But that’s the point. This is meant to be a blog, a website designed and developed purely to make the content I create as accessible and user-friendly as possible. It is in no way meant to be a portfolio or a personal website.

In the past I have often heard companies talk about things like Green IT and website performance, but when I look at the websites they build, almost all of them miss the mark completely. I didn’t want to be one of them, and that’s how I ended up with what you’re looking at right now.

Now, let’s dive deeper into the internals of this site.

Typographie

While most pages use Google or Adobe fonts, I decided to use a system font stack. So what is a system font stack? Modern Font Stacks describes it like this:

The fastest fonts available. No downloading, no layout shifts, no flashes — just instant renders.

And that in my opinion nails it. When you use non-system fonts like Google or Adobe Fonts, you are usually serving the fonts to the user, so they have to download additional resources.
When you use a system font stack, you are simply reusing the fonts that are already on the user’s device:

In short, this site uses system fonts only, as there is no advantage to using external fonts, other than being more visually appealing.

Colors

One could argue that the design looks dull because it’s main color is black, but there is a simple reason for that as well as for the rest of the colors seen throughout the site and it’s called OLED.

Most smartphones and more and more laptops have OLED screens. OLED screens compared to its predecessors LCD and LED omit the additional background lighting needed because of that OLED screens have the ability to be only partially lit which significantly reduces the power consumption.

There are a lot of articles and research on this topic with different results on how much energy is actually saved depending on the device, screen brightness as well as the application used to test with. Generally speaking, and as a result of all the articles, it can be said that dark mode and darker themes generally save energy.

On the other hand, you may have noticed that the font is not pure white. Since white is the brightest color, it has the highest power consumption, and since it’s well known that a combination of black background and white foreground is hard on the eyes and therefore hard to read for a long time, I darkened it a bit, turning it into a really light gray, while still staying within WCAG Level AAA conformance for maximum contrast and readability.

Images

Even though this article won’t contain any images, I had to plan in advance how to tackle the problem of images being by far the largest resource on most websites today. The 2022 Web Almanac came up with the following resolutions:

A look at the median weight of the most common resource content types making up the weight of pages shows images are the largest contributor, at 1,026 KB for desktop pages; 811 KB for mobile. JavaScript is the next largest contributor for both desktop and mobile page loads. — The 2022 Web Almanac

To ensure that the size of the image resources on this page doesn’t get out of hand, several optimizations have been made and precautions have been taken.

Resizing

First and foremost, and in my opinion the most important optimization, is automatic resizing. This is where another part of the design comes into play. Not only does the boxed content increase readability by being narrow and centered, but it also provides a guideline for how large images need to be at max. With a maximum box size of 690px, images can easily be automatically resized to that size and compressed at the same time to further reduce size.

Image conversion

While png and jpeg have done an amazing job over the past few centuries, it is time to say goodbye and accept that we have had better options for serving images for quite some time. In addition to being resized and compressed, all images are converted to AVIF. At first, WEBPs were also generated, but as AVIF compatibility increased, I figured that creating a third duplicate of the same image could be easily avoided, because in case a user visits from a browser that doesn’t support AVIF, we still have the original image from 1. as a fallback.

Responsive images

You might think that responsive images are the last and most obvious step to complete the number of possible easy automatable optimizations, but while it is a good thought, I actually decided against creating an additional set of images, here is why.

Most of today’s devices have a render scaling of 2x or 3x, which means that a “CSS pixel” is actually 2x2 / 3x3 pixels in size. On the other hand, when the browser itself determines which image to load, e.g. from a srcset, it takes these smaller pixels into account to ensure a sharp image. Since most mobile devices are somewhere between 375px - 414px wide, this means that the browser would try to load images larger than our maximum width of 690px anyway. One could argue that I could even increase the maximum to make the image look as good as possible on mobile devices, but for now I’m happy with the current solution.

Performance

If you take a look at the Network tab in your development tools, you might notice something strange. The entire website, ignoring resources like images, is loaded via a single request. No calls for CSS and JavaScript, no tracking scripts and not even a favicon. Let’s take a look at how and why I did this.

General

From a technology standpoint this is blog is based on Astro. All pages are rendered during build time using SSG and served via Cloudflare Pages. Hosting the blog on Cloudflare Pages not only leverages their edge network for faster response times but also automatically runs on 100 percent renewable energy (Green Hosting with Cloudflare Pages). Blog posts are written in Markdown / MDX and managed inside of a Astro Content Collection, therefore all content pages are dynamically generated according to their Markdown files. Schemas for the frontmatter of the Markdown files, to ensure compatibilty, are defined using zod.

Scripts

In short. This site doesn’t use or need any kind of client-side JavaScript. There are no trackers or functionalities that would require any kind of script to run. Of course, since this site is built with Astro and statically generated in advance, there is some JavaScript that runs once during the build process, but otherwise there is no JavaScript whatsoever.

CSS

Since the entire CSS is smaller than 2.5kb / 2kb gzipped, I decided to inline it to further reduce load times. Of course, parts of those 2.5kb could be cached so that they can be reused on multiple sites, but I felt that this might be too extreme, considering that the HTML alone is larger than that and cannot be cached.

Favicon

After all that tweaking, all that was left was the favicon. It already looked like it does now and was therefore only a few bytes in size, but I was annoyed that I still had 2 requests in my network tab. After a little research I found out that you can inline and base64 encode a favicon, so I ended up compressing a 16x16 square with 0% quality and maximum effort and base64 encoding it. The result: a 83byte inline favicon.

Summary

Even though the design and the blog don’t look like much at first glance, a lot of thought went into choosing the different technologies, colors and layouts. Even every line of CSS was evaluated multiple times for the need to further reduce the overall standard page weight. That’s why I’m excited to finally launch and provide guides, thoughts on content regarding all the topics already mentioned.

Thank you for reading to the end. Til next time!

Cheers,
Quentin ❤️