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
Great project!
Wouldn’t it make sense to make a black variant with white text? It would reduce the power used by the lights in a display..
Thanks Jan! I know why you’re saying that, but most of the research into this has found that only CRT monitors consumed significantly less power to render black. For most modern displays, the difference between the two is negligible. And some devices actually consume more power to show black rather than white! There’s a good – if somewhat dated – article about this here: https://www.scientificamerican.com/article/fact-or-fiction-black-is/
I like the fact that you have looked into this!
Jack, you are certainly right. But might I add that OLED displays, mostly used on smartphones, actually use less power when displaying black because the individual pixels can be turned off. I realize this is a bit of an edge case but it might get more common in the future. Great article by the way!
Yes, this is true, and something worth considering. Thank Snd!
Traditional LCD screens have a bright white polarized light behind all the pixels that is always on, and pixels individually can ‘shut’ their window to dim the light, which requires an additional tiny amount of electricity. This is done by crystals that bend the polarization of light of a certain color, depending on the electrical current they receive. The bent light beams then pass through a polarized filter which you can compare with prison bars. You can shove a book through prison bars only vertically, not horizontally
What a pleasure to read this article. I don’t know what to say. I’d say the time of environmental sustainable themes (EST) has dawned!
I’d go for a white on black / dark version for quite the different reason: It’s better for your bloody eyes! ;)
Sustainability alone doesnt mean anything if usability and accessibility gets pushed aside.
Aside of that: Underscores is a very decent helper when it comes to “reduce to the max”. I’m going to start working on a client site today, and try to reduce its insane bandwidth waste of space by porting the currently theme over to underscores, with a clean, custom-build Bootstrap underneath, throwing out about 60 – 70% of the web performance nightmares thanks to the over-complexity and bloat such a “multi-functional” WordPress theme is usually throwing around. Its definitely not coming out at 7 kb, more like 575 kb at best, and approx 800 at worst, but thats quite the difference to 2 (!) MB for a simple imprint page or even 6,7 MB (!) for the home page (which even doesnt contain much; just a simple slideshow, plus an image gallery).
Nevertheless, sustainability could be a big topic and reason to convince your clients to eg. NOT use a mega-bloated, chunky multi-purpose theme, but something more lean, clean, and thus normally also less complex, leaving more room for extension. Oh, and of corpse for usability and accessibility. So indirectly, sustainability is part of both these topics – usability improves the overall handling of the site, accessibility lets you understand it better .. and sustainability avoids making the site totally bloated. So its a new name with a slightly different perspective for something as old as the web: speed / loading time optimization :)
cu, w0lf.
Thanks for the comment!
This point doesn’t seem to agree with the studies around this topic: https://ux.stackexchange.com/questions/53264/dark-or-white-color-theme-is-better-for-the-eyes#answers
Having said that though, I’m very much a fan of light on dark. Hence the colour scheme of my blog. And I use a dark theme for my text editor.
Totally agree on the rest. :)
As I’m STRONGLY near-sighted, it is, especially during night times, a whole different level of torture having to read dark text on screaming bright backgrounds. After turning and fine-tuning my whole preferred GUI to white-on-dark contrasts, and also using a dark background color scheme in my favorite IDE, live has become so much more joyful. The same goes for e-book reading – Moon+ Reader with an adjusted Nighttime scheme .. just about perfect!
Of corpse, having the real thing in your hand is still unbeatable. No inertial illumination, but full reflection, while still being able to control the level and strength of this illumination? I’d wish computer displays could do that ..
It certainly is a matter of contrast, too, but that should be a logical given. If not: Stop instantly working on sites, stand up, and bang your head repeatedly against a wall until you pass out. If you did it hard enough, you might even be considered for a Darwin award. Would certainly make my live a lot easier :)
Aside of that, there is this lovely saying about statistics: Never trust one if you didnt forge it yourself ;)
cu, w0lf.
Nice post, Jack. I would like to list a similar project that I created for the students in India. It’s https://examsmate.in, a fully functional WordPress based website with Homepage Size of 10 KB (The logo takes 3.3 KB). It also performs 100/100 on Google PageSpeed.
It may load slow at your end as it’s hosted on Digital Ocean Bangalore Data Center (India) but here, it opens blazingly fast.
Here are the things that I did to make it happen:
Removed extra CSS and the JS included in the theme. Used CSS Shorthands.
Removed the extra classes from WordPress Navigation Items and Article Titles (post_class).
Used very short class names wherever possible.
Removed extra Yoast SEO Meta Tags.
Removed WP Bloat.
I was so conservative while minimizing the code that I used 700 instead of bold, used 3 digits Color Codes instead of 6 ones, used “Red” instead of #f00 :D
Still, looking forward to minimize the size further.
Whilst I’m all for reducing any carbon footprint, I’s asking myself would I want to view page after page of just text, irrespective of whether it’s black on white or the reverse and the answer comes up as a resounding NO.
I want to see images and videos and learning more by interacting with a beautiful site. I remember the first web pages that came out, so am not interested in going backwards.
Surely we should be moving towards using a better/newer form of power to host the internet; solar, wind, wave or something yet to be found, then trying to take web pages back to the dark ages.
I don’t mean this in a confrontational way, but have you actually read the article? Or read the content of sustywp.com? In the concluding paragraph of the article I said:
My point is that we implement a lot of unnecessary cruft on websites, and that it has an environmental impact.
I’d point to a website like DotYork as an example of a site hitting an almost perfect balance. The whole thing loads in a few hundred kilobytes, and it looks great. It isn’t just page after page of just text, and at no point have I called for that.
No, I dont think you did read any more than maybe half of the first paragraph of the article.
Its all about web speed and loading performance optimization, which as a nice side effect leads to lower the power-consumption based impact on nature. Think of nuclear power plants, which lead to nasty by-products which have to be safely put away for centuries, or the ugly results of a coal powered power plant .. also this coal has to come somewhere, too ..
Less is more, form follows function, and also KISS.
nuff said,
cu, w0lf.
Firstly, the article is more about how the web is built than its content. It is not true that you need heavyweight implementation to provide the best content or experience. Native browser features are better than ever, you can do everything (that your users need) with hardly any code.
On the subject of content and user experience, I don’t think anybody is campaigning to take web pages back to the dark ages, but the opposite. It’s about making an enemy out of the unnecessary. Working to the needs of your users and not your stakeholders.
Your users don’t need a specific font, they don’t need the hero imagery, they don’t need unconventional interaction. They don’t need to agree to cookies, they don’t need you to track them, use their information for marketing purposes, or to see uncontrolled third-party advertising. They don’t need exit survey pop-ups, interaction-blocking transitions, or their session to time out. They don’t need to prove they’re not a robot, download your smartphone app, or to wait days or even weeks to be unsubscribed from a mailing list.
This is the dark age, right now.
This is cool. Nice work! I took a similar approach with my site, but just motivated by the awesome user experience of having barely perceivable page loads. I kept the nav to increase the discoverability of my content. My gzipped home page was only 1.5kb. I wrote up some notes at https://nattaylor.com/blog/2017/new-theme/
But it is 35kb on Gt Matrix. Overall, amazing article for a junior like me who has started to learn coding.
Yeah, for some reason GTMetrix loads a load of stuff that browsers don’t. For example the
rel="icon"links. For some reason it also looks as thoughdashiconswas getting loaded too. No idea why that has started happening but I’ve added some extra code to force it to never happen.Thanks!
Have you checked out itty.bitty.site by Nicholas jitoff? His site allows for website creation without the use of a server (well technically for the website creator) using the URL to create the site. IMO X number of sites need Y number of servers as oppose to his idea where any X number of people can run a 2000-4000kb site on his 1 server. Seems pretty energy efficient. Am I being naive? What is your opinion?
Amortised costs are great until the point where you saturate the bandwidth for that one site. The only way to overcome that would be with a network. If you went peer to peer, it would not only depends on seeders (which is what load balanced servers are in a non-peer HA setup), but also would likely set a floor of above 6kb. It’s a very interesting idea though.
Yeah, itty bitty is a neat project. I think there are some great applications for it, but you’ll hit limitations if you tried to run a blog through it for example. And if you ever need to make an edit to a page, you change its URL. It’s great for one-off pages/projects though.
I Love this. A very cool project.
A Serviceworker might also save users the round-trip to the server and save on repeat downloads speeding up that saving more energy (although there is a floor, it might even impact how lightweight you can get the hosting).
Thanks Lewis! That’s in my to-dos at the end of the article.
I actually have the Service Worker up-and-running on my local environment, I’m just trying to work out the best strategy for cache invalidation!
Cool project! Will be interesting to see how it plays out with gutenberg. Also, it would be neat if the menu page itself was a special page/post type still editable via gutenberg (so you can create menu sections and style that page a bit more).
Sure you could do all this to every website but each and every person can reduce their carbon footprint so much more by going vegan.
Animal agriculture is responsible for 18 percent of greenhouse gas emissions, more than the combined exhaust from ALL transportation.
I am a vegan. See What else can I do? on sustywp.com. :)
The thing is, you can’t force your audience to go vegan, but you can force them to view a low-drag, high-performance site – and they’ll enjoy it!
Given the goals, this is a project that only works if you don’t care about having anything but a barebones website (as you suggest in your conclusion) – so its not clear to me how this would be useful other than within the confines of this post. Also, in terms of energy consumption you’re still running a full CMS on a server – you could likley switch to a CMS like Kirby and make a larger difference. I guess I was hoping for something more insightful – but you certainly raised my awareness of energy usage and I appreciate that.
Hmm. So you’re saying there’s nothing you can take from this post that you could apply to pre-existing sites that could be made significantly more efficient? In that case I guess I’ve failed you. I’m writing another article that goes into more detail about a lot of this stuff.
That’s a fair point about Kirby, though I would say that the idling costs of running WordPress are very low. The server running sustywp.com typically sees CPU usage around 1-3%. I’d say that in most cases, the vast majority of the people viewing a website aren’t administrators, and if you have good policies around caching etc., WordPress itself hardly gets touched. Something in the region of 99% of the traffic to sustywp.com is served from Nginx’s FastCGI Cache. So in my case, switching to Kirby would only bring very meagre gains.
Curious on your thoughts about optimizing images for devices with hi-res displays like an iphone. We have typically doubled the resolution of images so that they look crisp and clear on an iphone. The problem with this it also increases the size of the image. What techniques do you use to keep files small but still look amazing on these types of devices?
Hi Robert, sorry for the slow reply. There are some good thoughts on this in Adam Silver’s article Designing for actual performance. I’ll paraphrase him here:
I’d also recommend checking out the Apache and Nginx PageSpeed Modules which can take care of a lot of this stuff automatically. Although I was previously aware of these modules in an abstract sense, the comment from M S below caused me to revisit them and discover quite how fantastic they are.
Yours is an important lesson however we should not reduce the function of the web to 1990 standards to tackle this problem. People who don’t understand the technology want a coffee maker than cooks breakfast and reports the news. We have to find a happy medium between functional, enjoyable, unique websites and efficient, intelligent execution of the technology.
If I wanted to read a screen of monochromatic text without images or other special features I’d read a book.
In life it is almost never the right answer to leap to one extreme or another.
Have you read the article?
Now exactly sure if this would help meet your objectives here but what about something like:
https://getshifter.io/
Yes, this is interesting, but if you configure your server with something like Nginx’s FastCGI cache, the results are almost exactly the same.
Would you mind if I had a shot porting this to Ghost?
Not at all Phil, it’s GPL licensed so you can knock yourself out doing whatever you like!
I have sent you a pull request that demonstrates how SVG ‘should’ be written…
I noted in your repository that you had already had a go at removing the cruft from the SVG icon, I went over it again using ‘8 bit’ techniques (I designed a lot of weather icons for TV back in the day).
If you look at my amended SVG it uses just the stroke and not the fill. I coded it up in a text editor, not one of those Adobe bloat-behemoths. Or even Inkscape for that matter. These tools don’t expose you to the basic shapes, they create bloated filled paths instead of what you need. With icons you also want to make something maintainable, i.e. with adjustable settings so you can control the curves. Circles are the classic, imagine a search icon, the magnifying glass is one circle and one line. The line has a thicker stroke and rounded end caps, the circle has transparent fill and a thinner stroke than for the handle. This can be achieved in two lines of SVG, a ‘circle’ and a ‘line’. You can group these and rotate them by 45 degrees, shifting them up a bit in the viewbox to get the finished thing looking good. None of the numbers need be floating point. As far as maintainability is concerned it is very easy to look at the circle and line and amend it. Basic arithmetic may be needed.
The thing is that an Adobe tool will spew out something entirely different for this simple circle and line, as required for this basic search icon. The circle will be drawn as an outer path made of many, many points, typically fifty or so, then the transparent bit in the middle will be defined with another fifty point path. And the handle will probably have a minimum of twelve more points. Rather than simple and easy to maintain integers these will be specified in three decimal places! So the bloat is horrendous.
Hand crafting icons is worth the effort as these icons are important. The bloated ones might look right and they might compress down with automated tools, however, if you push the bloated circle through such a tool and remove the decimal places you will get something that is a polygon that has many sides, not a true circle. By definition icons need to be simple. So it makes no sense to use bloated tools and a toolchain that places any adjustments in the hands of the person doing graphic design where only they can tweak them by going back to some ‘illustrator’ file. Designers need to step up and design icons properly, in SVG, using SVG primitives, not whatever their expensive Apple computer and expensive Adobe software churns out.
That sounds like a rant but accessibility should apply for coders too, having images called ‘assets’ and in proprietary formats only editable by people that went to art school goes against accessibility.
Icons should also be in CSS as data urls. See Lea Verou’s CSS secrets on how to do this. The benefit of this approach is that it is just the one stylesheet that needs to be downloaded. Furthermore the icons are decoration to buttons and links, not content. Modern browsers support pseudo elements and loading icons this way is not a hack. The document can also be cleaner. An icon set does not need to be styled, as can be done if using inline SVG.
When an SVG is content, e.g. instructions, diagrams etc. then the inline approach has benefits – no supplemental download, ability to use and re-use symbols, animation, styling etc. These can be loaded as images for those that have no javascript or inlined if javascript is available. There are other strategies, really one needs to think outside of the toolchain and think what is best for accessibility, download speed and so forth before deciding on inline, in-css, external or javascript-inlined.
Another point for the minimal, green website – mod_pagespeed. This can compress a document removing white space, comments and plenty of other chaff such as quotes around attributes when they are not needed for an element.
However, the best benefit of mod_pagespeed is that it enables images to be simply uploaded as is by the client/content creator for src_set images to be generated. These src_set images are for the device so your 4K gaming rig gets a different image to your person on an iphone. The bandwidth saving from this is huge. It also avoids fiddling around in Adobe products getting allegedly optimised images and it also avoids having to use a third party to optimise them for a price.
Images also should be served from a cookieless static domain, with cache settings set correctly, again with the service worker helping out serving what is available in local storage/cache.
Anyway, the debate has started and I think ‘green webpage design’ needs to be up there with ‘responsive design’ as a marketable buzzword. Perhaps with competitions for delivering ‘full fat wordpress’ or other CMS in as few bytes as possible.
Thank you so much M S. This comment is quite simply amazing. I heartily accept the rebuke and pretty much wholly agree with you.
I actually didn’t make the logo, I acquired it via The Noun Project (which I realise I should credit somewhere!) And unfortunately, my artistic skills mean I can barely design an icon in Inkscape, let alone code one by hand. However, you’ve definitely piqued my interest and I’m certainly going to look into the basics of coding SVGs by hand. It blew my mind that you were able to reduce it in size to less than a third of what it was.
I do think that The Noun Project is a fantastic resource, and I take my hat off to all the designers that share icons on it. But equally, it would be great to see more people embracing the benefits of producing SVGs by hand in a text editor.
Also, thank you for drawing my attention back to the PageSpeed modules. I’ve been peripherally aware of them for some time, but haven’t really looked at what they can do closely for a few years. I also didn’t know there was an Nginx module, which is preferential for me as I typically don’t use Apache in my setups these days.
Once upon a time there was a theme developed for reducing database queries too which is named “Frank”. You should also mention the backend of worpdress. Nice article thanks on behalf of world :)
Great work – this has made me think… – I also love your FAQ section on the site. Great stuff
This is really cool! Since you used us as an example, and in case you’re curious, the site is pretty blazingly fast down here in Wellington.
Thank you Jack for all your hard work and this post. Early in my career I wrote embedded C code where every byte was important for both performance and size. Resorting to assembly to optimize performance as needed. During an extended recovery of illness, I self-taught myself web development and did a few free lance jobs. Now nearing retirement, I revisited web development to see what cool things have happened while I was away. I learn best by example, both good and bad, so I have been looking at CSS/JS/HTML code of various sites.
I was aghast how few sites minify CSS and JS. Many not even removing comments. Probably very few that bother to gzip. These techniques have been supported since almost the dawn of the internet. As you pointed out so well, it’s not only about best performance, but also about environmental sustainability.
Not to single out or belittle the effort everyone has done developing WP, but it has extremely over bloated code on both server and client side. I fear it has evolved to the “something for everyone and nothing for anyone” state. The evolution of faster internet and computers has allowed us developers to get sloppy and lazy, We need to write clean and lean code, not faster computers. Unfortunately, some of this is due to financial pressures and deadlines that constrain developers.
To that ends, I have been developing a theme for my own WP blog site instead of trying to use an existing theme. I started with blank-slate theme. You have inspired me to begin again with _s theme and trimming it down as you did. I also plan to experiment with serverless and faas approaches as these too seem to be more efficient and environmentally sustainable.
The only thing missing from this article is the added benefit of battery usage on mobile devices.
With all the bloat, as well as front end rendering instead of server side nowadays, mobile devices take a big hit on battery usage.
Good read!
Thanks, good to see optimisation efforts on today’s bloated web. My site’s custom theme is readable in <1s (2s on 3G), JS not required, just dependency-free enhancement. Regards.
What a fun project idea! Great article and I found some new, useful information to take back to my clients. Thanks.
It’s hard for us as humans to be good listeners. We’re usually composing our response before our companion has even finished a sentence. Take heart. Most of your readers are impressed by your work on this. We totally got your intent above all to make us THINK!
I used to get so mad at the speed tests that would tell me to optimize an image so i could save a whopping 12kb! I wondered how many hours and calories do I have to invest to get that 100% score? How many man hours do we waste every time google changes the SEO algorithms? What kind of drag is that on our economy?
Once I understood “render blocking resource” and all the other jargon it got easier and kind of fun to see how crazy fast a site could load. Adding the electricity used into the equation should help explain the importance of performance.
Am I the only one who encounters folks who act like I’m selling snake oil when I suggest their site should be optimized? Seems like roughly a 1/4 of the people I talk to immediately think it’s a gimmick.