Team,

TL:DR; we are now using WP Rocket and re.Smush.it on future installs.

—

WP Rocket (for further caching and speed optimizations) and reSmush.it (for image compression) have been added to the FS Template install. Both plugins are already configured and active on the FS Template, and thus will be active on future installs that get created — even during the development/build phase. Once the site is live on Pressable, further configuration will be required for optimal WP Rocket settings.

Some notes about WP Rocket configuration during development:

A new task called “WP Rocket Post-Launch Tweaks” has been added to the Asana Website Project Template (and thus will be present on future projects that get created). Here is a screenshot of the subtasks.

—

In addition, we’ve curated a list of page speed “best-practices” (mainly for the developers) to keep in mind and follow during the website buildout phase.

This new task is called “Page speed best-practices” and is a subtask of the main “Initial Build” task (and thus will be present on future projects that get created). Here is a screenshot of the subtask.

—

My thoughts:

Our project managers and support team have been getting hit hard lately with requests/complaints from clients about slow websites — so we need to constantly reassess our standards and practices, to ensure we’re exceeding client expectations.

I think we’re beyond the point where we’re able to install any “trusted” plugin and leave the default settings. Today, our clients are expecting more from their websites. More speed, more functionality, more beauty, and more usability. We’re selling ourselves as WordPress experts — so expectations are high, and rightfully so.

For this reason, we need to be more adamant about site speed, and the effect that plugins can play with that. In most cases, it comes down to poorly coded plugins. However, even popular and premium plugins are often not optimized for site speed best practices. And when we load an install with a handful of plugins, the issues are compounded.

Sometimes a plugin is loading numerous asset (CSS, JS, etc.) files, when it would have ideally combined such files into a single minified version. In addition, most plugins will try to load their assets on all frontend pages, regardless if the plugin is actually being used on that page (“just in case”). Other times, the plugin is making numerous connections to the WP database each time the page loads, or is reaching out to 3rd party services via multiple API calls.

Suffice to say, each client website is different, and often does require the use of additional plugins (often at the request of custom features). While additional plugins add needed or requested functionality, they can also play a role in harming site speed. We need to be cognizant of what each plugin is doing to the site and how it works — so that we can be proactive and diligent in finding ways to improve speed.

That may entail digging through plugin settings, reading plugin documentation, reading over the changelog or user questions, submitting feedback to plugin authors, etc. All of this will indubitably take more time and effort during the build phase, but it’s a win-win for everyone (especially our clients and our support team).