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).
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.
Autopti
mize 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.
My friend and #WordPress performance guru Bariş is from Turkey and is asking for help from the WordPress ecosystem. Share as widely as possible!
Phew, getting php 8.2 working in my #wordpress 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 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.
So Autoptimize Pro has finally been released, somewhat secretively (I like flying under the radar).
All info about features can be found on https://autoptimize.com/pro/ including a 20% early birds discount code, but if you use my internet nickname/ handle of whatever you want to call it (it’s part of the domain of this blog and has 3 t’s in it 😉) as coupon code between now and November 16th, you’ll get an even bigger discount!
Be quick, your website will be too 😉
It has been long overdue, but I’m finally almost ready to release Autoptimize Pro. The first version of AO Pro (an add-on to be installed on top off Autoptimize) will have Image optimization, CDN, fully automated critical CSS and a number of “boosters” to improve performance even more, with more features are in the backlog.
If you’re interested in beta-testing fill out the form below and based on data submitted I’ll pick 10 beta-testers. As a beta-tester you’ll be able to use AO Pro free of charge until the end of the year.
Beta-testing is being finalized, I am currently not looking for additional testers.
Autoptimize 3.1 was just released with some new features and some fixes/ improvements:
I got some questions about why and how of the “Disable extra compatibility logic?” option, here’s some more info copy/pasted from my answer on the WordPress support forum:
well, back in the 3.0 days the assumption was that for existing and thus confirmed working installations the compatibility logic brought no advantages and *could* cause regressions, hence compatibility was disabled for those (there are no complex/ heavy queries in the compatibility code).
this new option gives users of “older installations” the option to enable compatibility anyway, but as it is only useful in case of problems, I would advice to keep it off unless something is broken and only then to enable it to see if is automatically fixes the issue 🙂
Happy optimizing! 🙂
Lyte was just listed as a top video player on WP Glob 🙂