Eurovision 2023; my winner is … Blanca Paloma

About #Eurovision; Loved Croatia, Finland and I’m happy my fellow-Belgian #Gustaph did (very) well. But my favorite by far this year was Spains #BlancaPaloma

Flamenco-ish, intense, great voice, beautiful act, uncompromising electro-track that completely avoids the standard 4 to the floor beat that is way to present in Liverpool.

So much to like & discover, I’ve got it on repeat!

Blanca Paloma - Eaea (LIVE) | Spain 🇪🇸 | Grand Final | Eurovision 2023

Want to know some Autoptimize secrets?

There’s a first for everything and so last week I did a presentation at a WordPress Meetup in Antwerp titled “Autoptimize: 5 secrets and an intermezzo” which at least I had fun with.

You can find a PDF export of the presentation here.

Questions go below, in the comments (or in the form on the contact page).

Autoptimize Pro 1.3; instant.page

New booster in Autoptimize Pro 1.3: instant.page, a 3rd party JS component that can significantly improve performance for visitors going from one page to another on your site by preloading a page based on visitor behavior.

Do take into account that it could increase the number of page requests as the preloaded page might end up not being requested after all.

More info on https://instant.page.

How to fix Autoptimize & Critical CSS cron issue

Critical CSS (either through Autoptimize with your own Critical CSS account or through Autoptimize Pro which includes Critical CSS) requires WordPress’ scheduling system to function to be able to communicate with criticalcss.com on a regular basis. In some cases this does not work and you might see this notification in your WordPress dashboard;

It looks like there might be a problem with WordPress cron (task scheduling)

If this is the case, go through these steps to troubleshoot:

  • install the “WP Crontrol“-plugin and go to Tools -> Cron Events
  • WP Crontrol will warn if “cron” (another name for job scheduling) is disabled
  • Look for “ao_ccss_queue” and check the “next run” time/ date.
  • If the has a “next run” date is in the past, there is an issue with your site/ host’s WordPress cron.  Some hosts’ info on the topic can be found for WP Engine here , here for BlueHost, here for HostGator and lastly here for SiteGround.
  • Alternatively you can click on “manually process job queue” in the jobs pane in Settings -> Autoptimize -> Critical CSS

AOPro 1.2; delay JS, CSS & HTML as long as you want

Autoptimize Pro has “Boosters” to delay JavaScript (esp. interesting for external resources), CSS and HTML (which can be very impactful for long and/ or complex pages). Up until today’s release the delay was either until user interaction OR a set timeout of 5 seconds, but now you can choose the delay time yourself, setting it to e.g. 20s or 3s or -and that’s where things get a teeny bit shady- 0s to disable the time-out, waiting for user-interaction to load the delayed resources.

Setting the delay to 0 is a bit shady because at that point you are hiding those assets for performance tests which -although artificial- is likely to improve (lab test) performance scores. If you do use the 0s delay then do take into account that *real* users will still need to load/ render those assets and that that still may be a sub-optimal experience.

Adding PHP 8.2 in travis tests

Phew, getting php 8.2 working in my plugin’s travis tests required quite a bit of trial & error in travis.yaml, but 8 commits later I won 😉

The solution was in these extra lines to ensure libonig5 was installed;

matrix:
  include: 
  - dist: focal
    php: 8.2
    env: LIBONIG_INSTALL=1

install:
  # for PHP 8.2 install libonig
  - if [ -n "$LIBONIG_INSTALL" ]; then sudo apt-get install libonig5; fi

Mastodon oEmbed requests overload; use WP Rest Cache

Mastodon due to the decentralized nature can result in a significant extra load on your site if someone posts a link to it. Every Mastodon instance where the post is seen (which can be 1 but also 100 or 1000 or …) will request not only the page and sub-sequentially the oEmbed json object to be able to show a preview in Mastodon. The page requests should not an issue as you surely have page caching, but the oEmbed object lives behind /wp-json/ and as such is not cached by page caches. The solution; the WP Rest Cache plugin and one small code snippet (for now). A lot more info can be found in Donncha’s excellent post on the subject.