Working with Jetpack in development mode

Plugins like Jetpack don’t work at all in development environments that don’t use a fully qualified domain name or a domain that uses non-standard local domains (like site.local or, making it impossible to use any of its features unless we use Development Mode. To enable development mode we need to define the JETPACK_DEV_DEBUG in wp-config.php. The code looks something like this: <?php define( ‘JETPACK_DEV_DEBUG’, true ); While in Development Mode, some features will not be available since they require for their functionality, for example, Related Posts and Publicize. Other features will have reduced functionality to give developers a

Critical Path CSS

I’ve been looking at Critical Path CSS again as I work trying to improve the performance of this blog. The idea behind Critical Path CSS (from now on, just Critical Path) is that we inline the CSS needed to render the first screen of content, what’s called above the fold (borrowing a term from printed media) and load the remaining CSS later. I know that inlining CSS or Javascript can negatively affect performance but in this case, reducing the number of HTTP request needed to render and only adding the smallest amount of CSS possible to render above the fold

Working With WordPress Development and Staging Environments

Although I’ve always thought about staging environments as clones of production systems, I understand the need to do things differently in production than in staging or development. This would be no different than using Gulp to only concatenate and minify scripts in production or use the compressed setting when transpiling SASS but until version 5.5 there was no native way to do it. WordPress 5.5 introduced the wp_get_environment_type() function that allows developers to branch code based on the type of server we’re running. First set the WP_ENVIRONMENT_TYPE variable in wp-config.php define( ‘WP_ENVIRONMENT_TYPE’, ‘staging’ ); When wp_get_environment_type() returns development, WordPress will

Gulp and AVIF, part 2

Using the default encoder and settings, as described in Compressing AVIF images with Gulp, got the task running and produced the result we wanted: AVIF images that were smaller than the source image in either JPG or PNG format. This post will start from there and explore some further considerations on using avifenc to create images for the web. Unlike the previous post, the tasks here will try to mirror the following CLI commands. # Default AOM encoder avifenc –codec aom \ –min 40 –max 40 \ –jobs 4 \ –speed 10 \ –output squosh3.avif \ images/squosh.png The first pass

Compressing AVIF images with Gulp

Now that AVIF support is enabled by default in Chrome stable (85) and Firefox (behind a flag) we really should look at how to encode images to AVIF as part of a build workflow. In my normal workflow, I use imagemin, gulp-imagemin, imagemin-mozjpeg, imagemin-webp, and, experimentally, imagemin-guetzli. As of right now, there is no Node package to compress AVIF images (either direct library manipulation or wrapper for the existing scripts) so we’re left to explore other options. Squosh compressing an image to AVIF The first one is to use a tool like Squoosh from the Google Chrome team. It is