Any coder hates Google when it comes to the silly observations made by PageSpeed and similars. Of course we can comply with those endless requirements, but doing that and keeping all functionalities and features… well…

SEO-related requirements force website owners to perform a carnage in their WP installations. Multiple “optimizers” are installed. Most of them managing exactly the same aspects with a few differences. That includes Jetpack’s optimizing features in tandem with W3 Total Cache, Autoptimize and other smaller plugins, to remove this or defer that.

As a result, the website remains as slow as before, but now suffers with major issues like time outs, internal server errors, lack of memory and CPU capacity, etc. Inevitable, if we take those who can’t code their own solutions.

I agree: sometimes we can earn from using some of these “all-in” plugins of optimization. On the other hand, not every website demands such a comprehensive set of features. The number of features present in giants like W3 impels most people to another problem: configure it all correctly.

Not an article on cache plugins

We’re not talking about W3, Autoptimize or any other cache/optimizing package here. We’d prefer to highlight how some possibilities existent inside the WP core can optimize minor but important aspects of your website or app easily. Here we want to explore some of the possibilities of three particular asset-related WP classes:

There are many functions to deal with CSS and JS assets in WordPress, but some answers for the daily coder or designer must be developed or search in the community. For instance, I always get surprised with the tonne of queries on StackOverflow and forums on how to get a list of all enqueued assets.

Scripts and snippets of all flavors appear to respond the question. Some of them still work, but with unnecessary complexity. To explain once: scripts and styles are processed and printed in a given moment by WP. Thus, the only we need to do is grabbing some properties from the classes mentioned above AFTER that particular moment.

// First, let's hook it to an action that obviously happen after JS and CSS were declared
add_action('wp_print_scripts', function () {
	global $wp_scripts; // Instance of WP_Scripts class
	var_dump($wp_scripts->queue); // Dump the property $queue of that class


array(31) {
  string(6) "common"
  string(9) "admin-bar"
  string(11) "site-health"
  string(9) "dashboard"
  string(14) "plugin-install"
  string(7) "updates"
  string(12) "media-upload"
...and so on.

To get styles, you can use exactly the same hook and anonymous function, but need to grab the instance of WP_Styles, so the global variable to use is $wp_styles.

A tip using this same thinking

While troubleshooting clients’ websites, in most cases I always find some bloat in the admin area. They look frenetically for frontend improvements, for SEO reasons, but usually don’t ask for improvements in the backend. But they complain.

Hundreds of reasons are capable to slowdown the admin, but sometimes tiny changes and adjustments are able to reduce the bloat and make a client happy (or happier). The asset-related classes allow us to concatenate all default scripts and styles, mostly affecting the backend, without put in risk anything in the frontend.

We all see lots of complaints in the internet about people using plugins to minify, compress or concatenate assets on WP sites. The plugins definitely do what they promise, but website owners get pissed when they realize that some of the beautiful and funny features performed by JS libraries and advanced CSS simply stop working.

So, this small snippet will just concatenate the basic admin assets, so the backend can run a little faster without messing up with the user experience.

// The hook is again the same - we want the assets to be concatenated, so they need to be registered.
add_action('wp_print_scripts', function () {
	global $wp_styles, $wp_scripts;

	$wp_styles->do_concat = true; // Default is false
	$wp_scripts->do_concat = true; // Default is false

Images can be also explored

The abstract class that manages the media editor already offers a couple of interesting hooks. In this case, most of the class properties and functions can’t be messed up, but the class can definitely be extend (maybe another article in the future). The class WP_Image_Editor contains some interesting filters. About extending, this possibility is so obvious that even WP core brings two other child classes:

Both have been built to take advantage of WP instances in servers with one or both of these PHP extensions. Just starting with the most common, the quality of the saved image in WP and its respective compression can be set using a filter:

add_filter( 'wp_editor_set_quality', 'set_img_quality', 10, 2 );

function set_img_quality( $quality, $mime_type ) {
  // conditions for the returned variable or
  // simply an integer between 0 and 100
  return $quality;

/* NOTE: for JPEG images, this filter can be 
superceded by the jpeg_quality filter */

If your server loads Imagick or GD extensions, you can access other possibilities. For instace, GD extension strips metadata from resized images by default, while Imagick doesn’t. However, you can do the same with Imagick just passing a boolean “true” with the filter image_strip_meta.

In the next posts, we will be exploring even further the WP assets management and optimization, in a way that doesn’t rely in several plugins and image optimizers and compressors.