Is the web doomed?

Off course the web is not doomed, but despite the fact that web performance is immensely important (think impact on mobile experience, think impact on search engine ranking, think impact on conversion) the web keeps getting fatter, as witnessed by this graph from mobiforge;
web-page-size-revisited-revised
Yup; your average web page now has the same size as the Doom installer. From the original mobiforge article;

Recall that Doom is a multi-level first person shooter that ships with an advanced 3D rendering engine and multiple levels, each comprised of maps, sprites and sound effects. By comparison, 2016’s web struggles to deliver a page of web content in the same size. If that doesn’t give you pause you’re missing something.

There’s some interesting follow-up remarks & hopeful conclusions in the original article, but still, over 2 Megabyte for a web page? Seriously? Think about what that does that do to your bounce-rate, esp. knowing that Google Analytics systematically underestimates bounce rate on slow pages because people leave before even being seen by your favorite webstats solution?
So, you might want to reconsider if you really should:

  • push high resolution images to all visitors because your CMO says so (“this hero image does not look nice on my iPad”)
  • push custom webfonts just because corporate communications say so (“our corporate identity requires the use of these fonts”)
  • use angular.js (or react.js or any other JS client-side framework for that matter) because the CTO says so (“We need MVC and the modularity and testibility are great for developers”)

Because on the web faster is always better and being slower will always cost you in the end, even if you might not (want to) know.

About Insanely Stupid Code

When looking into a JS-problem on an Autoptimized site, it turned out missing semi-colons messed things up. Missing semi-colons make JS un-minifyable, as eloquently explained by master-minifier and JS-guru Douglas Crockford in this Bootstrap issue from back in the day;

That is insanely stupid code. I am not going to dumb down JSMin for this case.

Forcing Featured Video Plus to display Lyte YouTubes

A couple of days ago a WP YouTube Lyte user asked me if Featured Video Plus and WP YouTube Lyte were compatible. It took me a day to find the answer (I first said “no”), but Featured Video Plus actually has a filter (get_the_post_video_filter) that allows one to override the code used to display the featured video. And after a bit of trial and error this is what I came up with;

add_filter('get_the_post_video_filter','lyte_featured_video');
function lyte_featured_video($in) {
	$post_id = ( null === $post_id ) ? get_the_ID() : $post_id;
	$meta = get_post_meta( $post_id, '_fvp_video', true );
  	if (($meta["provider"]==="youtube") && (function_exists('lyte_parse'))) {
		return lyte_parse($meta["full"]);
	}
 	return $in;
}

Some extra checks ($post_id should not be empty, $meta should not be empty) would make this more reliable, but that’s something you should be able to add, no?

Why would you still be on PHP 5.2?

For Autoptimize 2.0.1 I declared a pretty complex regex to extract font-face’s from CSS using the nowdoc-syntax which is supported from PHP 5.3 onwards. Taking into account that the first PHP 5.2 release was over 9 years ago and support ended with the release of 5.2.17, over 5 years ago I assumed using a nowdoc would not be a problem for anyone. How naive I was; several people contacted me with this ugly error-message PHP 5.2 throws;

Parse error: syntax error, unexpected T_SL in /wp-content/plugins/autoptimize/classes/autoptimizeStyles.php on line 396

There is a workaround and even a more fundamental fix for that already, but who would still want to run PHP 5.2, which has this huge list of security issues? Moreover PHP 5.5 and 5.6 seem approximately twice as fast as 5.2 according to these test results and PHP 7.0 is even over three times as fast as 5.2! And still almost 9% of all WordPress sites are running on that old version (so I could have known this was coming really, bugger).
I you are one of those, do urge your hosting company to urgently provide you with an upgrade path to PHP 5.6 (or even 7.0)!

Autoptimize Power-Up sneak peek; Noptimize

In case you’re wondering if those Autoptimize Power-Ups are still coming and if so how they’ll look like and what they’ll do;
AO powerup sneak peak: noptimize
So some quick pointers;

  • Power-Ups will be installed as separate plugins and will obviously require some sort of registration, payment and license key activation (still to be developed, will either be EDD or Freemius-based)
  • Once installed, they will appear as tabs on Autoptimize’s settings page (no clutter in your menu’s!)
  • You can actually see 2 Power-Up-tabs in this screenshot;
    1. the active one is “Noptimize” and will allow you to configure which URL’s shouldn’t be optimized (either entirely or just CSS or JS).
    2. The inactive tab is for “SpeedUp” which … speeds up the creation of uncached autoptimized files immensely.
  • Other Power-Ups that are on the table are
    1. Critical CSS” to enable you to define “above the fold CSS” for different types of pages (posts, pages, homepage, archives, …)
    2. Whitelist” which lets you specify what JS or CSS to optimize (“known good”), making sure unknown code is never autoptimized
    3. HTTP/2” which will have logic to take the most advantage of what HTTP/2 has to offer, although (part of) this might go into AO proper.

Next steps for me; register my “secondary activity as independent” (as I still have an official day-time job), get in touch with an accountant, decide on EDD vs Freemius, set up shop on optimizingmatters.com (probably including bbpress for support) and determine pricing (thinking a Euro/month actually for each PowerUp, what do you think?).
Exiting times ahead …

Mijn m.deredactie.be-alternatief nu ook met Sporza

futttas-sporzaHet was exact een jaar geleden dat ik nog iets over mijn m.deredactie.be-alternatief schreef en het was nog langer geleden dat ik er aan gesleuteld had. Omdat ik tussen mijn echte werk en mijn WordPress plugin spielereien nog wat tijd had, heb ik één en ander verbeterd;

  1. Je kunt nu ook Sporza-nieuws lezen
  2. Op PHP-installaties zonder APC-support (apc_store/ apc_fetch) wordt de cache nu op disk bijgehouden
  3. Op PHP-installaties zonder CURL-support wordt nu teruggevallen op file_get_contents
  4. Een reeks kleinere UI-verbeteringen en fixes voor PHP-notices
  5. Getest op PHP 5.2, 5.5, 7.0 en HHVM (op openshift)

De (crappy) sourcecode staat nog steeds op GitHub, bug-meldingen of pull-requests zijn daar zeer welkom 🙂

WordPress Plugin releases: who needs a big bang anyway?

On January 1st Mika Epstein blogged about releasing/ updating software for large projects, advising against releasing software during the festive season;

With the increasing provenance of online stories and websites for everyone, pushing a change when we know that the majority of the world is celebrating something between Nov 15th and January 15th is reckless. […] picture what happens when an update has a small bug that takes down […] 1/1000 of 1/4th of the entire Internet. […] It may be time to call a year end moratorium on updates to our systems and apps.

Working in corporate IT myself I could only agree. In theory that is, because a couple of days before I had purposely pushed out a major Autoptimize release in the last week of December, on a Saturday. Why? While inching closer to Autoptimize 2.0’s release, I was becoming worried of the impact some of the bigger changes could have. Impact as in “what if this breaks half of the sites AO is installed on“. One way to limit such impact, I thought, is by releasing on a moment people are bound to be less busy with their websites. So by releasing on Boxing Day, I assumed less people were bound to see & install the update on day 0, limiting the damage a major bug could do.
Now I do agree this approach is very clumsy, but being able to limit the amount of people seeing/ installing a plugin (or theme) update on day 0 could help prevent disasters such as the ones that plagued for example Yoast SEO. The idea of “throttled releases” is not new, it already exists for Android apps, with Google allowing developers to flag an update for a “staged rollout:

You can release an app update to production using a staged roll-out, where you release an app update to a percentage of your users and increase the percentage over time. New and existing users are eligible to receive updates from staged roll-outs. […] During a staged roll-out, it’s a good idea to closely monitor crash reports and user feedback.

Pushing an update to a percentage of users and monitoring feedback, allowing you to catch problems without the risk of impacting your entire install base? I want that for my WordPress plugins! So how could we get that to work?
What if an extra header were included in readme.txt, e.g. an optional “throttled release” flag. With that flag set, the percentage of people seeing the update in their wp-admin screens would be low on day one and increasing every day, for example;

Day after release% of people seeing release in dashboard
day 05%
day 110%
day 220%
day 340%
day 480%
day 5100%

This could be accomplished by having https://api.wordpress.org/plugins/update-check/ (against which WordPress installs check for updates) “lie” about updates being available if the “throttled release”-flag is set by e.g. simply introducing randomness in plugins/update-check/;

$showupdate = false;
$randomness = mt_rand(1,40);
if ( ($throttledrelease === true) && ($datenow === $pluginreleasedate) && ($randomness < 2) ) {
    $showupdate = true;
    }

(The “magic” in above code is in the random value between 1 and 40 which has a 1 in 40 (or 2.5%) chance of being smaller than 2 (i.e. 1), so in 2.5% of requests $showupdate would be true. This translates to 5% of requesting WordPress instances per day, as there are checks for updates every 12h, so 2 per day. Obviously on $pluginreleasedate+1d the condition would change, with the random value having to be smaller than 3 (so being either 1 or 2, i.e. approx. 5% of cases X2 =10%), on +2d smaller than 5 (1, 2, 3 or 4 = 10% X 2 = 20%) and so on. This randomness-based approach allows for plugins/update-check not having to keep tabs of how many people saw/ did not see the update at a given date.)
This obviously is just a simplistic idea that does not take into account any of the smart stuff undoubtedly going on in plugins/update-check/ (such as caching, most likely), but I’m pretty sure the wordpress.org-people who are responsible for that code could implement something along these lines. And I do think this would very much be worth the trouble, as It would allow Yoast & other major plugins developers to release without the fear of breaking hundreds-of-thousands WordPress sites within a couple of hours. And I would not have to release on Boxing Day, leaving me and the users of my plugins the time to digest that Christmas-dinner peacefully. What’s not to like?
Blogpost updated (code example + explanation) on 13/01/2016 to reflect the fact that a WordPress instance checks for updates every 12 hours, which impacts the randomness.