After switching to a very minimal blog design, I realised what a huge impact (relatively speaking) libraries like jQuery and plugins like Jetpack can have on the weight of a page.
Less bullshit
Nick Heer wrote an excellent piece last month on The Bullshit Web: how we (people building the web) are ruining the Web for everyone by using the extra bandwidth and CPU power we have nowadays with stuff unrelated to the actual content. But even when the page isn’t filled with 100 surveillance scripts designed to track your every move, small choices can make a big difference to page size. For the past 1.5 years my blog has been running the Twenty Seventeen theme, and recently I removed the pretty superfluous hero image, which made the design even simpler. Out of curiosity I decided to switch to a custom theme based on WP Rig by Morten Rand-Hendriksen. For the time being, I’ve done very little customisations – a half-hour spent removing web fonts, the sidebar and doing some small layout and typographical adjustments. I was happy to find out that in my local development environment, the size of an individual short blog post such as this was around 30-50 KB. This was about 100 KB less than running Twenty Seventeen. Hooray!
Ruining the party with Jetpack and embeds
Imagine my surprise when on the live site that had gone up to over 300 KB! The culprit turned out to be Jetpack, which seems to enqueue jQuery and a ~90 KB CSS file even when they’re not needed. Since I was using very little Jetpack features anyway, I chose to disable it.
My front page is currently still ~660 KB. Almost 600 KB of that is because of a single WordPress.tv embed, 440 KB of which is due to three different thumbnail sprites that allow hovering over the timeline for easily jumping to different parts of the video. I can understand the convenience factor, but those would quickly crop up if I had multiple embeds on the same page.
Doing better
I’m not saying Jetpack is bad, but it and other popular WordPress plugins could often do a better job at checking whether a library or feature is really needed on the current page.
We should be able to do better too, as professionals building custom sites for clients. Using JavaScript it’s relatively simple to know when a user is interacting (or likely to interact) with a component and WordPress has many helper functions to aid in checking for specific content before assets are loaded. And it doesn’t take long to test a plugin to see what it adds to the weight of a page, and decide whether the value it brings to the site is worth the possible extra cost in bandwidth. Because those virtual costs translate into real costs, in time, electricity, and CO2.
Daniel Koskinen 
Leave a Reply