Love ya Dolly!
For the love of Dolly
1 Reply
Category Archives: Technology
Autoptimize featured on The CommonSenSEO Show
I had a nice chat on The CommonSenSEO Show, if you want to hear me ramble you can do so in this video;
Google Pagespeed Insights: The Good, The Bad, and The Ugly on The CommonSenSEO Show No.20
Watch this video on YouTube.
And if you’re into SEO, do subscribe to the channel!
We just joined the club!
Autoptimize just joined the “1+ million active installs”-club. Crazy!
I’m very happy, thanks everyone for using, thanks for the support-questions & all the great feedback therein and especially thanks to the people who actively contributed and especially-especially to Emilio López (Turl) for creating Autoptimize and handing it over to me back in 2013 and to Tomaš Trkulja who cleaned up al lot of the messy code I added to it and introducing me to PHP codesniffer & Travis CI tests.
Google Font display swap in Autoptimize?
Autoptimize 2.5.1 (out earlier this week) does not have an option to enforce font-display on Google Fonts just yet, but this little code snippet does exactly that;
add_filter('autoptimize_filter_extra_gfont_fontstring','add_display');
function add_display($in) {
return $in.'&display=swap';
}Easter bunny special: Autoptimize 2.5
Autoptimize 2.5 has been released earlier today (April 22nd).
Main focus of this release is more love for image optimization, now on a separate tab and including lazyload and WebP support.
Lots of other bugfixes and smaller improvements too off course, e.g. an option to disable the minification of excluded CSS/ JS (which 2.4 did by default).
No Easter eggs in there though :-)
How to (not) correctly load Gutenberg JS
On Facebook someone asked me how to do Gutenberg the right way to avoid loading too much JS on the frontend, this is a somewhat better organized version of my answer;
I’m not a Gutenberg specialist (for from it, really) but:
- the wrong way is adding JS with wp-block/ wp-element and other gutenberg dependencies on init calling wp_enqueue_script,
- the right way is either hooking into enqueue_block_editor_assets (see https://jasonyingling.me/enqueueing-scripts-and-styles-for-gutenberg-blocks/)
- or when using init doing wp_register_script and then register_block_type referring to the correct editor_script previously registered (see https://wordpress.org/gutenberg/handbook/designers-developers/developers/tutorials/block-tutorial/writing-your-first-block-type/).
I’ve tried both of these on a “bad” plugin and can confirm both solutions do prevent those needless wp-includes/js/dist/* JS-files from being added on the front-end.
Developers: don’t make Gutenberg go Badass-enberg on my frontend!
Over the past couple of months, since the release of WordPress 5.0 which includes Gutenberg, the new JavaScript-based block editor, I have seen many sites loading a significant amount of extra JavaScript from wp-includes/js/dist on the frontend due to plugins doing it wrong.
So dear plugin-developer-friends; when adding Gutenberg blocks please differentiate between editor access and visitor access, only enqueue JS/ CSS if needed to display your blocks and when registering for front-end please please frigging please don’t declare wp-blocks, wp-element, … and all of those other editor goodies as dependencies unless your 100% sure this is needed (which will almost never be the case).
The performance optimization crowd will thank you for being considerate and -more likely- will curse you if you are not!