Post pobrano z: Delivering WordPress in 7KB
Over the past six months, I’ve become increasingly interested in the topic of web sustainability. The carbon footprint of the Internet was not something I used to give much thought to, which is surprising considering my interest in environmental issues and the fact that my profession is web-based.
The web in a warming world
As a brief recap, I attended MozFest in London last year. In between sessions, I was scanning a noticeboard to see what was coming up, and I spotted a session entitled, „Building a Planet-Friendly Web.” I felt a little dumbstruck. What on Earth was this going to be about?
I attended the session and the scales fell from my eyes. In what now seems obvious — but at the time was a revelation — I learned of the colossal energy demand of the Internet. This demand makes it the largest coal-fired machine on Earth, meaning that its CO₂ emissions are probably at least equivalent to global air travel. More and more people are coming online, but this, coupled with the rise of ever more obese websites, means that the Internet’s energy demands are growing exponentially. Every additional byte transferred means more energy, which in most countries means more CO₂.
It is widely accepted that we should avoid printing emails to save trees, but this leads to a false assumption that the web is a green medium. I’m afraid to say, it is not.
Is there another way?
The good news is, it needn’t be this way. Since 2009, Greenpeace has been auditing Internet companies on their energy usage, and lobbying them to improve by way of their Clicking Clean campaign. The Green Web Foundation has an ever-growing database of hosting companies who use renewable energy, or who are at least committed to being carbon neutral. And new tools are emerging to help those working on the web measure the environmental impact of our products.
There are also some great resources out there such as Tim Frick’s Designing for Sustainability, three year’s worth of talks from the SustainableUX conference, and peripheral material that, while not explicitly focused on sustainability, can help us build lower carbon websites.
Enter Susty WP
I decided to challenge myself to see how efficiently I could package a WordPress website. While I was at it, I thought, “Why not make the website about sustainability and WordPress?” I know, WordPress/sustainability inception. Cool, huh?
And so, sustywp.com is born. With its accompanying theme, Susty. I’m rather chuffed to say I managed to get the load of the homepage down to 7KB of data transfer. I did actually get it down to 6KB, but the meta stuff added by Yoast bumped it up almost a whole KB! 😛 However, given I’m trying to spread a message, I deemed this to be an acceptable trade-off.
Before I get into the nuts and bolts, I just want to share a few headline facts:
- sustywp.com scores 100/100 on performance via Google’s Lighthouse.
- It gets straight A’s on webpagetest.org.
- It devastates most benchmarks, with an average time to first byte (TTFB) of about 0.15s, and fully rendered within 0.5s.
- It’s hosted in a data center which is 100% powered by renewable energy.
So, how does it work?
The remarkable thing about this is actually how mundane it is. Heavily inspired by Heydon Pickering’s evangelizing about writing less damn code, and projects like Brad Frost’s Death to Bullshit, I embarked on a root and branch pruning of Underscores, removing everything I possibly could. And to be clear, it’s not as though Underscores is full of cruft. It’s a very lean starting point for building a theme. I’m a great admirer of it and thoroughly endorse using it. However, it includes certain assumptions that didn’t chime with my spartan goal of making the smallest possible WordPress site.
Such as, you ask?
Nav? No. Sidebar? Get rid of it. Classes? Not in my socialist utopia.
Given the constraints I had set, anything making it to the DOM had to have a very good reason to be there. With this being an experiment, I took the somewhat radical approach of relegating the navigation to its own page. This is wonderfully liberating and means I didn’t have to go through the almost always disappointing dance of wondering how I would make it look presentable, hide it for the many users who won’t care, make sure it’s robust enough to be infinitely long with never-ending dropdowns, etc.
This means less HTML, less CSS, and definitely no JavaScript! Win, win, win.
As for the sidebar? Well I’ve always had an aversion to sidebars, so that was an easy thing to remove. Susty has no widget area. I’m sure it’ll get over it.
Is there more fat we can trim? Well, if we’re going to have hardly any HTML, and we want minimal CSS, do we really need all those classes? I wanted to try my hand at writing CSS in the way it was intended to be used, instead of bowing to the class-ititis and div-ititis that pervade the industry.
You might not need web fonts
Alongside images, video and JavaScript, the other item that has become a significant factor in bloated websites is web fonts. Given that it’s now a Silicon Valley fashion for every startup to commission its own typeface as a first order of business, it seems as though every website you visit incurs downloading a bunch of font files. It may not seem so bad to tack on a hundred kilobytes for some nice type, but when you multiply this by the many different people visiting your website across different devices and browsers, fonts can easily account for hundreds of megabytes of data transfer — if not gigabytes/terabytes/petabytes for higher traffic websites.
Custom web fonts are also a potential antipattern for our users, for whom:
- Page loads are slowed down as they see either a flash of unstyled text or, potentially even worse, no text while the font loads.
- By the time the font has loaded, they don’t notice or care.
If you do have to use custom fonts or are in combat with the flash of un-styled text, font-display is an new property designed to instruct the browser how to handle font downloads. This post goes into it even more.
Almost every device these days has a half-decent set of fonts installed, so why not compose a stack of potential fonts you’d like to see, ending with either “serif “ or “sans-serif.” Or embrace those default fonts altogether with a system font stack.
I wanted Susty to have a bit of a Swiss Style aesthetic, so my font stack ranges from the perfectly proportioned Helvetica (which all Apple devices have by default) to sans-serif, by way of Arial, Frutiger and Nimbus Sans L.
As an Ubuntu user, I see Arial, which is perfectly pleasant. On my Android devices I see the default sans-serif font (Droid Sans I believe), which actually works rather well on mobile — you’d almost think that’s what it was designed for!
What else? Standard stuff. Few or no images and SVG where possible
Beyond this, it’s really just the standard. The homepage of sustywp.com has no images and just one SVG which is loaded inline rather than by an HTTP request. The CSS is minified. Everything gets Gzipped. The server is tuned with NGINX and Fast-CGI cache to serve content from memory.
Bonus SPA-like features without the work or code
When I was boring my girlfriend, Daisy, with my plans, I asked her how she felt conceptually about a website not having a navigation, and it instead being on its own page, found via a „menu” button. She thought it sounded ok. So, when I came to show it to her, I watched eagerly as she clicked the menu link. Her response was that she didn’t really think about clicking to see the menu, and the menu appearing, as changing pages. This confirmed one of my fears that my previous obsession with eliminating page loads when building Single Page Apps (SPAs) is something that only really bothers web developer-y types. Most people don’t really notice it or think about it. So, if you make your website lightning fast, the page loads themselves are almost imperceptible anyway.
With that being the case, I figured why not just pretend it was a menu overlay? So, I added a cross dismiss button and a tiny bit of JavaScript to take you from the menu back to the previous page if you click it. (I did initially implement this in PHP using the $_SERVER superglobal and HTTP_REFERER, but this breaks when using something like FastCGI cache to serve pages (i.e. those pages there is no $_SERVER superglobal.)
There’s still more to come
We all know that things can always be better. Here are a few of the things I’m working on to improve Susty:
- Finish reading Jeremy Keith’s book Going Offline so I can implement a Service Worker and make Susty even more performant.
- Look to see how I can implement Gutenberg. It’s going to add a bunch of kilobytes and that makes me sad! 😉
- Currently, sustywp.com is hosted in one data center in London, and served globally from that location. This means that someone in Wellington, New Zealand is not going to get the full experience! I have a longer-term plan of establishing my own little CDN of edge servers (each one hosted by a 100% renewable energy powered host in each location that I can find one) just running NGINX and serving cached versions of the site. This is a simplified way of how we do things on WordPress.com VIP.
In conclusion
Susty is an example of taking sustainable design techniques to an extreme. I’m not suggesting that we should all start building websites with this exact method. But I do think sustainability should be a much higher priority in the web design industry. It’s good to think about saving any kilobytes we can, and to think in terms of kilobytes rather than megabytes. If you do want to use a JavaScript interface library, why not try out Choo.js, which has React-like features and comes in at just 4KB. Remember, NASA managed to put a man on the moon with about 50KB of data storage at their disposal.
The best thing about all this is that efficient websites means faster websites, which means:
- Happier users
- Better search engine placement
- Happier servers
The post Delivering WordPress in 7KB appeared first on CSS-Tricks.
