web page download size

How to go block-less with the WordPress ActivityPub plugin

by

Being the web performance zealot I am, I strive to having as little JavaScript on my sites as possible. JavaScript after all has to be downloaded and has to be executed, so extra JS will always have a performance impact even when in the best of circumstances it exceptionally does not impact Core Web Vitals (which are a snapshot of the bigger performance and sustainability picture). Hence when adding blocks in WordPress, I check if the block is entirely rendered server-side and if not I look for alternatives to avoid multiple files from wp-includes/js/dist (and in the case of some 3rd party blocks the entire React JS and more) being loaded.

For that reason I tested the WordPress ActivityPub plugin with the reactions block loaded as per these guidelines and indeed it triggers the loading of hooks.min.js, i18n.min.js, url.min.js, api-fetch.min.js (all in wp-includes/js/dist) and 2 files from the plugin itself (/wp-content/plugins/activitypub/build/reactions/view.js and /wp-content/plugins/activitypub/build/remote-reply/view.js).

To be able to reduce the dependency on those JavaScript files, 2 questions needed to be answered; how to have reactions (which I like a lot) without the JavaScript-driven rendering and what is that remote-reply thing.

Starting with the latter; “remote-reply” handles the federation of local comments on reactions (comments) from the Fediverse, showing a modal window where the commenter is asked what ActivityPub account they want to post the reaction from. I decided this was not that important for me and –with some help from Matthias @pfefferle who always gives great support- came up with a couple of lines of code to not “do” remote-reply on this blog.

Now that Fediverse reactions block is very nice and I did want reactions showing on my blog, so I started looking at the database and the ActivityPub plugin code and saw that all Fediverse reactions were stored in the wp-comment en wp-comment-meta db-tables and were in fact accessible with the WP_Comment_Query class. With quite a bit of trial and error I ultimately ended up with a totally server-side generated solution that looks pretty nice (and similar to the JavaScript-rendered one).

If you’re interested, you can find the code in this gist, but don’t expect it to be good. Some negatives include no language handling, unminified CSS inline and the placement of the reactions might not work on every theme as I hook into the comments_template action to try to show them just before the comments. But who knows it might just work for you as well?

Is the web too fat for your IPhone?

by

So you have a spiffy mobile phone with a top notch browser that does a decent job at displaying “desktop-oriented” websites and you use it to surf the web regularly, visiting some of the bigger news-sites in Belgium. What does that mean, from the point of view of data transfer and bandwidth usage?

data usage for 4 pages on 5 sites (click on image for more, methodology see below)

That sure is a lot of data, Captain! What does that mean?

  1. You will have to be patient, because downloading 1 or 2 Mb for that initial page will probably be gruesomely slow (especially if you’re on EDGE because there’s no 3G-coverage)
  2. You will end up paying good money for all that data transfer, because data is money when you’re on mobile time
  3. You might even curse your handset or crashing browser (more on google), because all that data will end up in RAM and these devices do not come with tons of that.

In these broadband-times, website builders seem to have completely forgotten about best practices for download size of complete web pages (html + all js/css/images/…). This means that a lot of websites should be considered non-accessible on mobile devices.
If you want your normal website to be usable on IPhone’s, HTC’s and other Nokia’s, you’ll have to start taking download size into account again. That means taking some technical measures (using mod_deflate and mod_expires for example) and making hard functional choices to remove some stuff (on this blog dropping the rather useless mybloglog-widget saved me 210Kb, going from 10 to 7 posts per page another 200). And if you want to target mobile users specifically, you’d better invest in a mobile-specific version of your site!

The methodology followed to measure these download sizes;

  • disable flash (there’s no such thing on mobiles, with flash these figures would have been even far worse)
  • disable memory cache (in about:config), because it can’t be cleared easily
  • clear disk cache
  • open up firebug and click on ‘net’ to monitor downloads
  • download homepage, random 2nd page, random 3th page and the homepage again

The spreadsheet (on google docs) contains more data (compare above results with those for 2 mobile-specific sites)