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
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.
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.
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.
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.
Someone uploaded an amateur recording of an entire (?) Jeff Buckley solo concert at the Sin-é from July 1993 (one year before Grace was released). A gem!
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.