AOPro 2.3: delay all JavaScript

As of Autoptimize Pro 2.3 there is an option to delay all JavaScript. Delaying can have a bigger positive performance impact then asyncing or deferring because AOPro will only load the delayed JS after a to be defined delay or (better even) only at the moment user interaction (such as swiping/ scrolling or mouse movement) is noticed.

Obviously when delaying all JS you might want to be able to exclude and that is possible as well; you might want add data-cfasync there for example as contrary to Autoptimize’s normal behavior for deferring, delaying ignores attributes like data-cfasync, meaning that if you want to leave such JS untouched you will have to add it to the exclusion list yourself.

Lastly; if your site’s above the content depends on JavaScript to render correctly (which has serious performance impacts), delaying all JS would result in the page not rendered entirely, so test and exclude as required.

When lazyloading iframes does (not) work (automatically)

WordPress has made some good progress to speed up site rendering the last couple of years and part of this is thanks to images and iframes having the “loading” attribute with value “lazy”, telling browsers these can be loaded later allowing other (more important) assets to take priority. Especially iframes can consume a lot of bandwidth (think embedded Google Maps or one or more YouTube videos), so the performance impact of lazyloading those can be very significant.

Unfortunately one cannot always rely on WordPress core to automatically make sure there is no performance penalty from stuffing your site with iframes. Here is a non-exhaustive list of when iframes will still delay your site:

  1. WordPress core does not always add the loading="lazy" attribute;
    1. if loading="eager" is set (which means load asap)
    2. if no width & height are set (as lazyloading iframes without those could cause layout shifts)
  2. Firefox (and some less important browsers) does not support lazyloading iframes even if loading="lazy" is set
  3. iframes in or near the “above the fold” part of a page are loaded immediately, even if loading="lazy" is set

Conclusion; show restraint when adding iframes; adding an image of Google Maps which links to (a separate page with) Google Maps is almost always as informative and the performance benefit of using an image instead of an GMaps iframe is huge. And when using iframes then consider using alternative solutions to avoid the performance impact (for YouTube you might want to give WP YouTube Lyte a try).

As found on Our Tube; Edward November – Cold Street Light

So I heard Edward November on the (online) radio a couple of times already and the first and only single “Cold Street Light” is magic.

He (aka Edmund Lauret) should either stop making music entirely or (a lot more difficult) he could try to do even better.

The latter will be very hard though, because “Cold Street Light” is a perfectly unhappy pop-song, beautifully moody, slightly quirky and somewhat unpredictable but with an immensely catchy (downbeat) chorus.

Edmund November - Cold Street Light

Autoptimize Pro released, secret discount code here ;-)

Autoptimize ProSo 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 😉

Autoptimize & WordPress 5.9 issue with aggregated inline CSS

WordPress 5.9 comes with a change I had not noticed before; it is adding inline CSS with random-ish names, which when “also aggregate inline CSS” is active makes the AO cache grow incredibly fast.

As a workaround you can add .wp-container- to the CSS optimization exclusions. I have just pushed out Autoptimize 2.9.5.1 which automatically excludes inline CSS with that string.

Het Bakkebaarden-beklag

Ik ga graag naar de kapper; een vermoeid mens moet daar simpelweg zitten en af en toe met het hoofd in de juiste richting neigen. Het feit dat je soms even binnensmonds brommend op een onbetekende vraag moet antwoorden om een poging tot gesprek af te blokken, doet daar niets aan af.
Als je bij een goeie kapster in de stoel zit, is het masserende wassen van je haar immers al voldoende beloning om die
achtergrondruis te negeren. En aangezien ik maar een paar eenvoudige instructies heb (“kort, moet wat piekerig staan bovenop”), ben ik over het algemeen ook tevreden met het eindresultaat.
Behalve .. behalve als het over mijn bakkebaarden gaat. Want op een of andere manier gaat het daar elke keer opnieuw volledig fout. Het meisje met de schaar vraagt dan schijnbaar onschuldig; “Moet ik uw faschen bijtrimmen mijnheer?”. Ik brom dan instemmend, want het haar groeit nu eenmaal waar het niet kruipen kan en er zijn grenzen aan elk grasperkje. Maar voor ik kan uitleggen welk motiefje mijn voorkeur wegdraagt, krijg ik de haartrimmer dreigend tegen de slaap geduwd en verlies ik het eerste streepje mannelijkheid. Een occasioneel ongegeneerde kapster draait de brommende machine zelfs nog even in m’n oor, om de overtollige begroeiing daar ook te kappen. Het is ongetwijfeld een manier om zich subtiel te wreken op de mannelijke haargroei.
Terwijl ik dan tot mijn afschuw ontdek dat de tochtlat voor mijn linkeroor niet veel koude meer zal kunnen tegenhouden, wordt ik ook aan de rechterkant genadeloos gekortwiekt. En het is precies op dat moment dat het over het algemeen echt volledig fout loopt; kapsters hebben immers, zo blijkt uit mijn jarenlange ervaring, absoluut geen benul van symmetrie. Ondanks zeldzame verwoedde -en ongetwijfeld door wroeging ingegeven- correctie-pogingen, waarbij de dame van achter mijn rug aandachtig fronsend in de spiegel staart terwijl ze met wijs- en ringvinger van beide handen de lijn van mijn
favorietjes volgt, blijkt keer op keer dat de linkerkant hoger komt dan de rechterkant. Of omgekeerd. Als het dan nog een beetje tegenzit (en geloof me, dat doet het meestal), gaat de bakkebaard aan de linkerkant van hoog naar laag en aan de rechterkant van laag naar hoog. Of omgekeerd. Volstrekt onsymmetrisch, hopeloos onoplosbaar en bovenal erg
lelijk.
Op dat moment kan het kappersbezoek er niet snel genoeg opzitten: bedremmeld betalen en weg, zo snel mogelijk. Om de weken erna tandenknarsend in de spiegel te kijken naar wat ze er in godsnaam toch weer van gemaakt hebben en te wachten tot het geliefde onkruid terugkomt. Want die troost hebben we tenminste; in de strijd tussen bakkebaarden en mannenhatende kapsters, zal de fasch altijd winnen!