You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey gang! Love the website and the idea behind it.
I wanted to do a dive into your site's frontend performance. Whereas I normally would call attention to things that would improve experience for the users, here I'll instead focus on things that reduce energy consumption.
A lot of this won't be possible easily, I'm sure, because of Solar essentially being a themed version of the main lowtechmagazine.com site. Hopefully, these findings apply to both sites, then :) Some of this will require a build process that you may not have setup. Feel free to email me at firstname.lastname @ gmail
Use multiple sizes for large images. Requires one-time server-side processing of uploaded images, but you'd make up for it in bandwidth costs. I'd expect most of your traffic is mobile: sending over 50-60% reduced image sizes on >50% of hits is a big difference. You can do this with <picture>
A fast follow from that is to Inline image height/width values. This provides the browser an aspect ratio and permits it to precalculate layout information. Currently, when images load in, text and elements are moved. This isn't going to reduce energy costs on your side but it's a good thing to do and will reduce CPU use on your users :)
Big one: Consider using a JS lazy loading library. native lazyloading is very permissive. Look at how many images are loaded with just the "above the fold" load on a tiny phone. A lot of users will never even scroll down but they're still going to be loading in those images! Waste of energy for both sides. Fine-tuned lazyloading JS would allow you to only start loading once it's in viewport – a much more sensible option for this economical site. And with inlined height/width values those images will have perfectly sized placeholders waiting for them :)
Hash CSS file and fix TTL. Your CSS file, named style.min.css, has a cache lifetime of 3 days. Repeat visitors after 3 days will need to recheck with the server, causing energy consumption! If you instead hashed the file name (eg style.min.30ac31b.css) so that the hash changes every time the CSS did, the cache could be immutable. There would be more energy used during the hashing process but this would likely only happen on deployment (or as needed).
Offline first or the "Cache, falling back to network" strategy. By using a ServiceWorker, you could cache everything a user loads from your servers on their own browsers, and subsequent refreshes would then touch nothing on your servers. This is a big win for users (they can read offline!) and for you as well. 🔥 Cons: Implementing this w/Pelican might be tricky; users may see stale content if you update posts.
Serve SVGs as resources. Each page has 8 SVGs inlined that are increasing document sizes. One of them is a duplicate. Load these instead as resources to make them cacheable. If you concatenate them into a single sprite sheet and make use of <use> you'll see gzip wins as well. That all means fewer bytes sent for subsequent page loads.
Move general CSS to critical, lazyload rest. This site has a print media query and 6 other max-width breakpoints in the bottom of its main CSS file. Having all those in 1 file means users are downloading more than necessary: most won't be printing anything; and some aren't loading on laptops. Here's one way to address:
Then, through <link rel="stylesheet" media="print" href="print.css"> and media="screen and (max-width: 667px)" href="mobile.css", you'll be making those styles optional.
Finally, I'd encourage inlining all the un-breakpointed CSS into a <style> tag in the <head>. You're one of the few sites for which this is still warranted in an HTTP/2 world: it's your only critical path asset and you only have about 2kb of it gzipped. Doing this would allow the First Contentful Paint (FCP) to happen immediately.
Hey gang! Love the website and the idea behind it.
I wanted to do a dive into your site's frontend performance. Whereas I normally would call attention to things that would improve experience for the users, here I'll instead focus on things that reduce energy consumption.
A lot of this won't be possible easily, I'm sure, because of Solar essentially being a themed version of the main lowtechmagazine.com site. Hopefully, these findings apply to both sites, then :) Some of this will require a build process that you may not have setup. Feel free to email me at firstname.lastname @ gmail
Use multiple sizes for large images. Requires one-time server-side processing of uploaded images, but you'd make up for it in bandwidth costs. I'd expect most of your traffic is mobile: sending over 50-60% reduced image sizes on >50% of hits is a big difference. You can do this with
<picture>A fast follow from that is to Inline image height/width values. This provides the browser an aspect ratio and permits it to precalculate layout information. Currently, when images load in, text and elements are moved. This isn't going to reduce energy costs on your side but it's a good thing to do and will reduce CPU use on your users :)
Big one: Consider using a JS lazy loading library. native lazyloading is very permissive. Look at how many images are loaded with just the "above the fold" load on a tiny phone. A lot of users will never even scroll down but they're still going to be loading in those images! Waste of energy for both sides. Fine-tuned lazyloading JS would allow you to only start loading once it's in viewport – a much more sensible option for this economical site. And with inlined height/width values those images will have perfectly sized placeholders waiting for them :)
You could either write a simple loader using
IntersectionObserver()– that you could inline in the HTML and start the loading immediately – or you could use something like the 2.4kb vanilla lazyload for ≥IE9 support. 🔥 Cons: images won't load with JS off.Hash CSS file and fix TTL. Your CSS file, named style.min.css, has a cache lifetime of 3 days. Repeat visitors after 3 days will need to recheck with the server, causing energy consumption! If you instead hashed the file name (eg
style.min.30ac31b.css) so that the hash changes every time the CSS did, the cache could be immutable. There would be more energy used during the hashing process but this would likely only happen on deployment (or as needed).Offline first or the "Cache, falling back to network" strategy. By using a ServiceWorker, you could cache everything a user loads from your servers on their own browsers, and subsequent refreshes would then touch nothing on your servers. This is a big win for users (they can read offline!) and for you as well. 🔥 Cons: Implementing this w/Pelican might be tricky; users may see stale content if you update posts.
Serve SVGs as resources. Each page has 8 SVGs inlined that are increasing document sizes. One of them is a duplicate. Load these instead as resources to make them cacheable. If you concatenate them into a single sprite sheet and make use of
<use>you'll see gzip wins as well. That all means fewer bytes sent for subsequent page loads.Move general CSS to critical, lazyload rest. This site has a
printmedia query and 6 othermax-widthbreakpoints in the bottom of its main CSS file. Having all those in 1 file means users are downloading more than necessary: most won't be printing anything; and some aren't loading on laptops. Here's one way to address:<link rel="stylesheet" media="print" href="print.css">andmedia="screen and (max-width: 667px)" href="mobile.css", you'll be making those styles optional.<style>tag in the<head>. You're one of the few sites for which this is still warranted in an HTTP/2 world: it's your only critical path asset and you only have about 2kb of it gzipped. Doing this would allow the First Contentful Paint (FCP) to happen immediately.