Personally, the biggest drawcard for static sites on another WordPress install — and probably the biggest reason I wanted to work for CloudCannon — was the promise of reducing overall energy expenditure (both in terms of page weight and computation time). As in) and my own excessive reliance on PHP, proprietary databases and teetering tech stacks.
Minimal computing and #leanweb
By the time I moved to #leanweb, I had already read some concrete position statements by Alex Gill and Jennery Sayers, who were focusing on what they and others call minimal computing – what their working group calls this. Describes the type:
Computing done under some set of critical constraints of hardware, software, education, network capacity, power, or other factors. … Minimal computing is also an important movement similar to environmentalism, seeking balance between profit and cost in related fields.
In an ideal world, we would want all of our websites to function equally well regardless of network capability or user knowledge – from site creation, through various edits and all manner of changes to protection. than, in high- and low-bandwidth scenarios. As many tools as possible.
What are your current constraints?
Of course, we always have constraints: if it’s not the time, it’s usually our own energy or enthusiasm to learn a new approach, or find a balance between cost and benefit.
But I think that collectively, as part of the static site community, we can overcome a lot of common hurdles, or at least make significant improvements to the dynamic render-on-demand status quo:
- When it comes to site creation, the barrier to entry, via a static site generator (or a CMS that supports an SSG), is lower than ever, as more developers are moving to modern static websites. . With an ecosystem of commercial and open-source tooling around generators, SSGs are becoming more accessible to non-technical users.
- Static sites, being flat file structures, are inherently protected, without reliance on opaque database structures or vendor lock-in. (And versioning via a Git-based CMS like CloudCannon gives an easy way to track all your site changes over time.)
- CloudCannon’s visual and content editor views help a lot with the editing side of things, without adding dependencies beyond a few configuration files.
This leaves us with one major hurdle to work around below: variable user bandwidth. The solution to this constraint is obvious: lose weight of our page, However, how to get there? Well, for most developers, traveling is half the fun.
In a recent episode of CloudCannon’s Static Feedback webinar, Jost van der Schee and I discussed how to implement constraints in our workflows, and what bandwidth and page weight mean for the user experience in terms of speed and satisfaction. While we focused on the almost philosophical approach of knowing the purpose of each line of code, we didn’t expand the scope of our conversation to search for rankings that depend on low page loads, not slow but enjoyable Visiting fine-tuning websites, page by page and tool by tool.
Before I dive in today, it’s worth noting that I’m not advocating for all sites to be aggressively minimalist like the Musk Foundation, or Low-Tech Magazine’s self-hosted, off-grid and I’m not advocating for a solar-powered site as transparently sustainable. However, there are comparatively large bandwidth and data savings we can make on our websites and the devices we use on them, simply by keeping bandwidth constraints at the forefront of our minds.
Tools to reduce the weight of your page
1. Image and Video Optimization
It’s one of the most impressive changes you can make to your bandwidth usage, but you’re probably always trying to balance acceptable size against acceptable quality. Where your project sits on this spectrum is up to you, but there are a number of tools and approaches that can help:
Use formats like webp and avif — This is an offline solution, but deciding on an efficient modern format for your property is an excellent first step.
Use a Service Like ImageOptim For offline preparation of single or multiple images, once settled on your preferred image format.
Image Management Tools within your SSG -Jost talks Hugoconf on resizing all images in the Hugo project, targeting resources at a certain size, and using render hooks for images within Markdown content. Other SSGs will have different solutions: if you’re using Jekyll, for example, a plugin like jekyll-image-size Open Graph link tags, img-tags, a range of image sizes for different screens with CSS will help generate And HTML props.
2. CSS Optimization
If you’re building your CSS by hand, using only the exact classes you need, you’ll still find that the size of your CSS file grows as your site grows. But it doesn’t need to grow much – you can remove unused classes with a tool like Purge CSS.
This may be a point of contention for Artisan purists, but even if you are committed to the artistic approach, I would recommend expanding your ‘knowledge toolkit’ to include Tailwind CSS. It has excellent documentation, which really helps you get your head around what you’re doing behind the scenes. Yes, its development build is big by design, but optimizing for production tree-shake very efficiently, up to the point that most CSS files, compressed, won’t exceed 10kb. As their docs put it:
Think of the Tailwind like a giant box of Lego – you throw it on the floor and build what you want to build, then when you’re done you put all the pieces back into the box. You didn’t use
Adam Wathan, creator of Tailwind, has written a great article on the transition from the ‘traditional CSS’ to the ‘utility-first CSS’ that Tailwind enables, and while changing lanes can take some time, you’ll probably find that the fact That utilities provide another set of constraints, which help enforce consistency for team development.
3. Minify Your HTML and JS
When it comes to minifying HTML and JS, your performance gains are likely to be low, as these tools remove unnecessary whitespace, newlines, comments, and indentation as well as crunching variable names. You can easily find manual shortening tools in a basic web search; For my SSG of choice, Hugo, I’ll be using Hugo Pipes and Resources. Minify CSS, JS, JSON, HTML, SVG, and XML in one command to minify.
4. Zipping Your Files
Gzip identifies repeating strings within your files, and replaces them with a single token, resulting in significant size and pageweight savings. With mining, the result is perfectly readable to browsers, but not exactly friendly to human readers – but that’s okay, as both mining and gzipping are part of your build process. Still confused about the difference? See Chris Coyer’s excellent article comparing the two approaches. Chris gives an example of Bootstrap’s CSS file (147KB): small, it’s 123KB; gzipped, it’s 22KB; And combining both the approaches, it’s just 20KB.
5. Bundling JS
6. Consider Performance and Additional Site Functions
You probably already have a set of tools for additional site features that you habitually change, but the artistic approach is about consciously creating new habits. Here are some of my favorite tools and common ways to optimize performance:
Search page for site search — Steady search that scales incredibly well for sites up to 100k+ pages. PageFind is built with fewer network requests as the primary bottleneck, and still manages to deliver an extremely polished performance.
Inspect your sites and see your network traffic — Try using a tool like web.dev/measure — It’s a good habit to stick to anything before you publish. (And if you have the luxury of coworkers to double-check your optimization strategy, it’s amazing how much of a difference it can make at this point.)
Agree the odds with your team – If you develop as part of a team, one of the best ways to reduce the weight of your site is to make sure everyone on your team is on the same page. It’s a valuable conversation to have every few months, and it will help shape the guidelines you all use for your best practices.
Page weight and sustainable web design
I recently read with great interest the manifesto of a new web design agency, DoDonut. Their stated mission – their primary obstacle, laid bare to view of the web – is to create a positive environmental impact, largely by reducing emissions related to the products they design. They include an inspiring carbon calculator on their homepage, directly equating the page weight to CO₂ emissions, and refer to the environmental value of removing as little as 50kb from a site with reasonable traffic.
The Dodonut also comes with a great pedigree; Not an entirely new entity, it is part of Bejamas, the 2021 Jamstack Agency of the Year. So with this wealth of steady growth knowledge, a ready supply of helpful developer tooling, and above all a willingness to reduce page weight, things are looking good for both Dodonut’s customers and the planet.
Where should I start?
I would start by assessing how much external code you are sending. Look at your favorite techniques – what are you using because you’ve always used it? What you know is inefficient, but you do it anyway?
Alternatively, you can just start shortening and zipping where you’re not already, or look for other easy wins. Why not start with your own images. Perhaps you’ll optimize one at a time, and reduce your page weight to just 20kb. It’s still a good start! Or maybe you go all out, and aim for a full website No bigger than 100kb. You will remember that constraints are shifting goals we can set for ourselves on a per-project basis – we have to start somewhere, and what you consider to be ‘best practice’ can grow should be further developed.
For now, we know that The extra page weight makes for a sub-optimal user experience, reduces SEO rankings, and contributes to emissions., And taking all these factors into account, we have a productive constraint. So let’s get creative with this.