One of the things that I handle for clients at FixUpFox is site speed optimization. I also help with performance optimization, which I almost lumped into this post, but I think that it deserves its own overview at a later date.

I also began blogging more regularly on this personal site, thanks to the support from the Blogging Accountability Group that I formed with a few members of the WordPress Orlando Meetup. One of the things that I want to do is to improve the theme that I use on the site, and one of the ways that I want to do that is to improve site speed.

There are quite a few reasons to want to improve the speed of a site. Most concerning to me are based around resource usage and visitor experience. Loading a smaller page does a lot of good, including:

  • Less bandwidth and resource usage for visitors, improving loading speed and battery life
  • Lighter energy usage footprint, reducing ecological impact slightly

Here’s a quick overview of what I did for my personal site, which can be what I do for a client site, depending on their needs. I have to note that I don’t do much in terms of tracking on my site, and I don’t run ads. Those are often the two biggest blockers that I have to increase page performance for clients.

A baseline of performance

The first thing that I do is establish a baseline of the site. That lets me get an idea of what improvement that I end up with, but also places to start looking at making changes.

The following data was from my WordCamp Atlanta Review post tested with tools.pingdom.com. I also use Google PageSpeed Insights, Lighthouse, and GTMetrix depending on what I’m looking for.

Performance grade: C β€” 77
Page size: 1.1 MB
Load time: 1.37 s
Requests: 56

The above indicates that I loaded 1.1MB worth of data on this page, taking an average of 1.37 seconds over their tests, and that 56 separate files were requested to load this page.

This isn’t terrible, but I had a feeling that I could do better with a few simple changes.

Removing Unused Scripts, Styles, and Fonts

First, I started by reviewing external requests. That includes any JavaScript files, CSS stylesheets, and fonts that load along with the rest of the page. I had 56 requests being made to load that page, which is far from unusual, but a bit high for a personal post about a trip on my non-monetized site.

Boilerplate Scripts

A plugin that I use to manage things like my Speaking custom post type was made with the WordPress Plugin Boilerplate. That helped save time in setting the plugin up, but it also added a bit of code that I didn’t need, including display script and style files which I wasn’t making use of. Eliminating the code that called those files eliminated two requests that did literally nothing at all.

jQuery Migrate

Next, I looked at jQuery Migrate. This is a script that WordPress loads to help manage old code. It acts as a bridge between the latest versions of jQuery and code that is written for very old versions of jQuery. Since my site is running up to date code in the theme and plugins, I could remove this script. I can’t always say that it is possible to remove it, but you can try and see if anything breaks on your site. Most current themes and plugins have no need for it, so I removed it with the following code taken from this Dotlayer article.

//Remove JQuery migrate
function remove_jquery_migrate($scripts)
{
    if (!is_admin() && isset($scripts->registered['jquery'])) {
        $script = $scripts->registered['jquery'];
        
        if ($script->deps) { // Check whether the script has any dependencies
            $script->deps = array_diff($script->deps, array(
                'jquery-migrate'
            ));
        }
    }
}

add_action('wp_default_scripts', 'remove_jquery_migrate');

FontAwesome

Next, I looked at FontAwesome. loading the script to enable that on my site was the largest file, accounting for around 25% of the page load size.

I really like FontAwesome. It’s made it a great way to get social icons and other useful site iconography without having to find and load new pictures for each. Plus, it flows smoothly between code, the content editor, and stylesheets.

It turns out that I was only using three icons from FontAwesome across the entirety of my site: the hamburger mobile menu icon, the X close icon when the mobile menu was open, and the moon icon for the basic night-mode that I have a feeling no one even realizes is for that purpose (more on that in the future).

Since I didn’t have a lot of icons to replace, I decided to rebuild those in CSS only. There are a variety of places to find tutorials on drawing in CSS, something that I hope to do in the future as well. For now, I redid those icons in CSS and removed reference to FontAwesome from the theme, saving a lot of the page size in the process.

WP Emoji

WordPress has its own emoji loading, which is useful for the amount of times that I like inserting a 🐺or a 🐾 or a 😝into what I’m writing. But you can see from the previous sentence and my bio at the end of posts that I still have them displaying with system defaults of pretty much every device that would view my site without having to load them.

I’ve used the following code to blanket remove the WordPress emoji from my site load, though you might have reasons for keeping some of these on.

/**
 * Disable the emoji
 */
function disable_emoji() {
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );
	remove_action( 'admin_print_styles', 'print_emoji_styles' );
	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );

	// Remove from TinyMCE
	add_filter( 'tiny_mce_plugins', 'disable_emoji_tinymce' );
}
add_action( 'init', 'disable_emoji' );

/**
 * Filter out the tinymce emoji plugin.
 */
function disable_emoji_tinymce( $plugins ) {
	if ( is_array( $plugins ) ) {
		return array_diff( $plugins, array( 'wpemoji' ) );
	} else {
		return array();
	}
}

Handling Images

I realized that a lot of images were returning too large on my site. This means that I had a space where an image would load, say an 80px square for a profile icon, yet a larger 512px square was loading for it.

In this case the issue was Webmentions, which I was handling via an IndieWeb plugin. I was showcasing people who liked or retweeted my post on Twitter, as well as those who commented on it.

A whole discussion should be had about the display of metrics, the privacy of individual interaction, and a need to prove popularity through that interaction. For now, my focus was on speed, and I’ve turned off profile image loading. I’m going to be reviewing my usage of this type of interaction demonstration, while still showcasing some cool features that IndieWeb proponents have given us.

Resizing default media sizes

The large image size on my site was set to the default of constraining to a box of 1024px by 1024px. This is a good default for some sites, but for me I had nowhere that images were displaying that large generally, even on wide screens. There were images loading that had to be resized by the browser and ended up loading larger files than needed.

If you are on your site dashboard, you can go to the Settings panel on the left sidebar and select the Media page. There you can change the default media settings to sizes that make sense for you. In my case, I made thumbnails a different size to fit my design. They ended up being larger than the default, but allowed me to avoid having to crop to fit featured images manually, and are smaller than the medium size that I would have otherwise loaded. I also made large images constrained to an 800px by 800px box, which is around 61% of the size of the original image size. This is still large enough for my theme, but saved some space in what is often the largest portion of page load.

If you change your image size on an existing website, you’ll also want to regenerate the cropped and resized image files that WordPress makes. The plugin Regenerate Thumbnails is my go-to for this task. You can even set it to only resize featured images, if those are the only ones that need to change.

Performance improvement after making changes

Now that I’ve made a handful of changes, it’s time to test the site again to see how we’ve done. I’ve gone back to tools.pingdom.com and ran the test again, being sure to select the same server location to get comparable results.

Performance grade: C β€” 80
Page size: 563.2 KB
Load time: 442 ms
Requests: 36

The performance grade has barely gone up, but that’s more of an overall estimation based on what they think is important, which doesn’t always apply to your site. What has improved is the page size, which is about half of what it was before optimization. That’s already a huge savings! It’s also loading in about a third the time, and I was able to remove 20 requests from the page load.

At this point we could probably be done and move on, but I figured I’d try a few other small things to improve page speed. I wasn’t doing any concatenation of files, and that seemed like the next best place to reduce the number of requests, increasing load speed.

What about performance optimization plugins?

I have used a few plugins for minification and concatenation in WordPress. Minification means stripping out unnecessary spaces and comments in files that make them much easier to read for humans, but aren’t needed by the computer. Concatenation is taking files and combining them together into one larger file. While it takes up more space it is one fewer request to make, which again can be a big driver in performance and speed.

Fast Velocity Minify and Autoptimize are two free plugins with a variety of free and paid extensions that you can take advantage of. I’ve never used the paid extensions to offer any insights, but the free versions work very well.

In this case I chose Fast Velocity Minify, which I installed on my site and activated with default settings only, no modification. Running the speed test again gave me the following results:

Performance grade: A β€” 91
Page size: 607.3 KB
Load time: 443 ms
Requests: 19

There’s a few things to note here. The performance grade greatly improved, and the number of requests was cut nearly in half, which is a big contributor to that score.

But we also see that load time is basically unchanged, and the page size actually increased, despite the fact that we tried shrinking the number of files that loaded.

These optimization plugins can do great things for your site, though they can also add headaches with another layer of caching and the possibility that concatenation breaks the order that scripts need to load to function. I still use them on a lot of sites, but I think it’s important to note that they aren’t a magic fix and are a bit more complex in how they handle your site content.

tl;dr β€” A recap of what I did to improve performance

I’m going to let the following screenshot (that I optimized, of course) from Google PageSpeed Insights speak for itself in terms of what a few minor changes that took me about an hour worth of work did for my site.

And here are the results that I got for the site at various testing times:

Before OptimizationAfter OptimizationAfter Optimization Plugin
Performance gradeC β€” 77C β€” 80A β€” 91
Page Size1.1 MB563.2 KB607.3 KB
Load Speed1.37 s442 ms443 ms
Requests563619

I’ll encourage you to consider deeply what optimization steps apply to your website and which don’t, but here’s a short list of things that I did that you could try.

As a reminder, I am basing this case study on a personal site that does not run ads (though it has a Patreon to support my writing and tutorials!), and uses a single Google Analytics tracking script. When it comes to sites that do extensive tracking or use advertising networks, there are a host of other things to consider.

I hope that the above gives you a place to start when you begin looking at increasing performance and speed on your site. Now go make the web faster and better!

While there’s been a lot written about the new editing experience that came out with WordPress v5.0 last month, I want to give a reminder of some of the neat features for end users. One of the best things about the new editor is that a theme or plugin can add or remove features from the editor with simple hooks, allowing you to craft an experience that fits your needs.

As an example, I have taken a few client sites that have embraced the new editor, and used their style guides to add their branding colors, fonts, and variants into the page editor. Now, when they want to add a block of content with a colored background or change the color of a button on a page, they have their palette of brand-approved colors already set to use. No need to remember hex codes or anything confusing!

Sounds great! How do I set up a custom color palette?

Default WordPress Editor Color Palette
Notice that the editor will warn you if your background and text colors aren’t high contrast. This makes it a bit easier to keep your content accessible!

By default the editor will have a palette of 11 colors, plus a color picker to get a different color. You can swap to a palette of your own by adding some code to your theme. Place the following in your functions.php file or where appropriate based on your structure. Next, we’ll modify it to fit our needs.

This code came directly from the Gutenberg Theme Support Handbook, a good resource for all WordPress developers.

function mytheme_setup_theme_supported_features() {
    add_theme_support( 'editor-color-palette', array(
        array(
            'name' => __( 'strong magenta', 'themeLangDomain' ),
            'slug' => 'strong-magenta',
            'color' => '#a156b4',
        ),
        array(
            'name' => __( 'light grayish magenta', 'themeLangDomain' ),
            'slug' => 'light-grayish-magenta',
            'color' => '#d0a5db',
        ),
        array(
            'name' => __( 'very light gray', 'themeLangDomain' ),
            'slug' => 'very-light-gray',
            'color' => '#eee',
        ),
        array(
            'name' => __( 'very dark gray', 'themeLangDomain' ),
            'slug' => 'very-dark-gray',
            'color' => '#444',
        ),
    ) );
}

add_action( 'after_setup_theme', 'mytheme_setup_theme_supported_features' );

There’s a lot of code there, but not a lot to break down. First, remember that after_setup_theme is a hook, on which you add the function mytheme_setup_theme_supported_features that you’re creating. In that function we’re using add_theme_support, a built in WordPress function, where we’re using editor-color-palette to set our palette up.

We’re adding an array of colors, and each element of that array is itself an array. Within those nested arrays we have the name of the color, which we’re making translatable with the __() function, and setting the textdomain of our theme. Change themeLangDomain to whatever matches your theme. This name is a descriptor for when you hover over it in the palette.

The slug is a string of how you’ll refer to the color elsewhere in your code. The color is the hexadecimal value of the color that you want in your palette. With the above code, you’ve got a new editor palette with four colors that you’ve set, along with the color picker.

Our custom WordPress editor color palette
Our four custom colors now appear, along with the color picker

Adding to Our Palette

There are a few more features of the editor color palette that I’d like to show off, including targeting blocks in CSS, Customizer set colors, and removing the color picker.

Using our Color Palette Selections in CSS

If you’re editing text with the color palette you shouldn’t have to make any other changes. But what if you want to use the color selection in something a bit more customized, or in your own block type?

The slug that we added to our colors in the example above lets us target for both background and text colors. We don’t even need to use the color set in the editor, but something custom to our needs. For example, you may want a specific background or text color when you use the strong magenta color. In that case, here’s the CSS that can target the classes added when we use that color:

.has-strong-magenta-background-color {
    background-color: #313131;
}

.has-strong-magenta-color {
    color: #f78da7;
}

Setting a Color Palette with the Customizer

The twentynineteen theme that comes with WordPress has a custom palette that includes colors that can be set in the Customizer. This means that you can set your own primary and secondary color from the WordPress dashboard, without changing code!

array(
	'name'  => __( 'Primary', 'twentynineteen' ),
	'slug'  => 'primary',
	'color' => twentynineteen_hsl_hex( 'default' === get_theme_mod( 'primary_color' ) ? 199 : get_theme_mod( 'primary_color_hue', 199 ), 100, 33 ),
),
array(
	'name'  => __( 'Secondary', 'twentynineteen' ),
	'slug'  => 'secondary',
	'color' => twentynineteen_hsl_hex( 'default' === get_theme_mod( 'primary_color' ) ? 199 : get_theme_mod( 'primary_color_hue', 199 ), 100, 23 ),
),

The new color is now set as the output of a function that will get a theme mod, if you’ve modified the color. If not, it’ll return the default, ensuring that there’s always a color set.

The WordPress customizer with a primary color selection

Removing the Color Picker

You can also do things like disable the color picker, to ensure that users can only use the colors that you have preset for them. Doing so requires just one line of code in your functions file:

add_theme_support( 'disable-custom-colors' );

With that single line we’ve made it so the beautiful design that we’ve worked so hard to craft and the branding style guide that we have had to constantly review will always be set the way that we want.

Wrapping Up

As you can see, there’s a lot that you can do to change how users edit content in the Gutenberg editor, without having to add a tremendous amount of code.

This is only the beginning, and even more developer and user friendly features like this already exist or are coming to the editor and the rest of WordPress. I’m excited for the new opportunities this gives to all stakeholders of a site, from designers and developers, to admins and editors, all the way to customers and visitors. Let’s keep making WordPress better for everyone!

I’ve started using Beaver Builder with a few clients after having played with it a bit and hearing lots of great reviews. I’ve looked into multiple WordPress Page Builders, and have had experience with quite a few of them through my work offering WordPress maintenance service.

I’ve found that Beaver Builder is able to handle a lot of the customizations that my clients may want to make, but there are still a few things that I have to setup externally to get a feature that they want. As an example, a client wanted to use the callout module to make an entire box clickable, not just a button after text and images.

Doing the above was fairly straightforward for this use-case: I set the entire callout link to be relatively positioned in CSS, so that I could absolutely position the anchor tag within the link to be the full height and width of that box. Finally, I added a hover and focus state to the button so that when hovering with the mouse or focusing with the keyboard there would be a visual indication that it was clickable, besides the cursor icon that was already set.

.callout-link {
	position: relative;
}

.callout-link a {
    position: absolute;
    width: 100%;
    height: 100%;
    top: 0;
    left: 0;
}

.fl-callout-button a:hover,
.fl-callout-button a:focus {
	box-shadow: 1px 1px 3px 0 #315E7D;
}

So what’s the issue?

That looked like a simple solution to the problem that we had, but like many bits of code, I inadvertently created a new issue.

Beaver Builder is a front-end content editor, which means that it uses the same HTML and CSS structure to display the content while editing. While this is normally a good thing, it means that you need to pay attention to custom code that you’ve added to modify Beaver Builder.

Since I changed the layout of links in the callout module, I changed the layout of links for the editor of that module. Additionally, I’d styled unordered list bullets with pseudo-elements, which also caused a display issue. This is what the editor looked like when I tried to modify those links:

Broken Beaver Builder editor CSS
This is what happens when you let me touch code!

After I determined that I was the cause of the issue, I set about to fix it. Thankfully, Beaver Builder adds several body classes while the page editor is open, including the class fl-builder-edit which I used to fix this particular issue. I hid the li::before pseudo-elements, and restored the link anchor to relative positioning.

/* Beaver Builder Editor Fixes */
.fl-builder-edit .entry-content ul li::before,
.fl-builder-edit .fl-builder-content ul li::before {
	display: none;
}

.fl-builder-edit .callout-link a {
    position: relative;
}

With that code in place, the editor layout looked as it should before I mangled it.

Fixed Beaver Builder editor settings
That’s a lot better and actually usable!

Check for unintended consequences of your code.

This broken CSS wasn’t a major problem, and was thankfully easy to fix. But it did bring up a good reminder: when you make one change to your code, you may change something else that you didn’t mean to. It’s always good to review every time that you make a change. Having some version control in place that you use regularly doesn’t hurt either!

I have clients that want to ensure that their pages print well so that people can save things offline for later, like recipes or instructions. I don’t print webpages myself, but I can see plenty of useful reasons to do so.

One of the issues when printing a webpage is that you lose context and interactivity. This is usually fine, as the site is probably intended to be read online anyway. But sometimes you want to make it easier for people to use that printed site, like still being able to find a linked page from a printed article.

The Solution: Print Styles for Links

Let’s say that you want to link to FixUpFox, my WordPress maintenance service. You can put https://fixupfox.com as the text on your page so that it prints properly and people can visit the site from their computer later.

The above works for print, whether you link it or not, but usually you’ll want to say something like “For site support I use FixUpFox, because they provide great service at an affordable price for unlimited tasks”. In that case, you’ll want to have some way to display that URL next to the linked text when printing.

Thankfully, there is a media query in CSS that is for print styles. Your browser will pull up that style when viewing the print version of a site. We’re going to use that to create our links.

Making the Print Styles

First, we’re going to make a media query in our stylesheet. This can go at the end of your existing stylesheet, or you can place it elsewhere as long as it loads on the page that you want print styles for.

@media print {
}

Next, we’ll add an underline style for links, so they’re easier to see among text in a printed document that might be in black and white. We’ll add that style to visited links as well to override any potential visited link styling already on the page for underlines.

@media print {
	a,
	a:visited {
		text-decoration: underline;
	}
}

Finally, we’ll use a CSS pseudo-class of :after on links that have an href attribute selector (so it’s not just an empty <a> tag), which is the target URL. We’ll add that target URL attribute of the link (the page that we’re linking to) to the content, after any links on our site. We’ll add a space before the link, and wrap it in parentheses to set it apart from the text. That code looks like this:

@media print {
	a,
	a:visited {
		text-decoration: underline;
	}
	a[href]:after {
		content: ' (' attr(href) ')';
	}
}

This works with any anchor tag that has a target link, even if it’s a text link instead of the URL. So when I type Ongoing WordPress Support and Maintenance, the printed version of that link will be the text of the link underlined, a space, and the URL in parentheses.

The following screenshot shows what the link looks like when we view the page in print mode:

screenshot example of a CSS print style for links
This is a saved PDF of part of this article. Note the URL in parentheses after the link text.

Finishing Up

You’ll likely find that you have lots of things displaying links that you probably don’t need, like the menu to your site, or sidebar content.

One solution would be to use the print styles to hide those portions of the site entirely. After all, if I’m printing a recipe out for later, I don’t need the navigation, header, footer, or anything else to print besides the content of that recipe. Another solution would be to target links in your content specifically, such as using the .entry-content class to get links that are only in your page and post content if you’re using a theme like the Genesis Framework.

Whatever method you choose is up to you, but I hope that this helps you consider the ways that you can use print stylesheets, CSS pseudo-classes, as well as CSS attribute selectors to add more context to your site, whether printed or on the web.

Thanks for following along and putting up with the shameless plugs for my maintenance business!