Maslow's Hierarchy of Needs: Website Performance Edition

People visit your site for a reason. They want to read an article, or get information about an event, or shop and compare products, or something else important to them. Your site should move at the speed of their thought.

Visitors will leave if your site loads slowly enough that they have enough time to think about the fact that they are waiting. Those who do stay become painfully aware of what the browser and site are doing. They know when a font is being loaded because everything is visible except the text. They know scripts are still being processed because elements keep jumping all over the page. They know something feels broken when scrolling lags.

A site performing well means an absence of this awareness. It means that the medium of the web creates no friction between your site's goals and the people browsing it.

Image

Transcendence: Going Beyond Performance

In thinking about performance in this manner, I was reminded of a post I wrote last year on  DevOps as it relates to Maslow's Hierarchy of Needs. At the top of that hierarchy we have actualization and transcendence. For human beings, reaching these heights means spending your time and energy in effective and fulfilling ways; often in service of causes greater than yourself.

For your website development, there should be a cause greater than a perfect performance score. Improved performance will result in improved conversions. To understand how to reach this summit let's look at how other stages of Maslow's hierarchy map to site performance from the bottom up.

Physiological Needs: Performant Infrastructure

Most performance recommendations only have a chance to be successful when you are building on top of a stable base. For Drupal and WordPress sites that means PHP 7, solid state drives, and an object cache. It means using a CDN to get your cached assets (including full page caches of your HTML) as physically close to your visitors as possible.

When your website is running in a healthy environment, you have a chance to make it fast. Given fundamentals like version control, a reliable deployment strategy, and a development environment that matches production, you can start making changes to improve performance.

Safety: Avoid Performance-Killing Mistakes

When working with a fully built site that never had a focus on performance, there is a good chance you can make huge improvements with some very small changes.

I have seen a handful of Drupal 7 sites use the PHP filter in Views module to load nearly every piece of content on a site, only to print five articles. When a site is new and only has 50 articles, this technique is inefficient. As the site ages and the list of articles grows to 50,000, it becomes a disaster. Over the course of months and years such a site will see page rendering times drift from milliseconds, to seconds, to minutes.

Similarly, there are plenty of sites that fail to configure image styles in one or two places. If a content editor uploads a 10mb image, then every other optimization made for that page could be moot.

Often you can make to biggest improvements to performance on existing sites by finding and fixing these basic performance killers.

Belonging: Load Only What Belongs On The Site

Tricks like trying to load a bunch of stuff in parallel, or aggressive caching, might seem like appealing shortcuts, but nothing replaces just auditing the code and making it need less 'stuff.'

 

—Craig Silverstein

As I've presented “Why Your Site Is Slow” at Drupal and WordPress conferences over the last two years, I like to emphasize this point from Craig Silverstein of Khan Academy. There will always be new, cool techniques for making a site as fast as possible. With these techniques you can squeeze out a few more points on a 0-100 Lighthouse score. You can often make bigger improvements by removing code instead of optimizing it.

Before asking "how quickly can we load this JavaScript?" ask "Do we need to load this JavaScript at all?"

Recently when reviewing the files a WordPress site was loading, I saw a JavaScript file for a "Share This" widget. My first thought was "that should really be aggregated with other JavaScript files." But wait! The page didn't even have a "Share This" widget on the screen, and neither did any other page on the site. That file could be removed entirely.

The same problem can easily happen with CSS on Drupal and WordPress sites. There is a good chance that a site is loading styles from a parent theme that has been completely overridden by a custom child theme.

Drupal and WordPress sites also tend to accumulate unused modules and plugins over time. There might something that was added during the site build and never really used.

If you are unsure where to start finding unused assets, I recommend opening up Chrome Developer Tools and looking to see if you have unused CSS rules.

Esteem: Get The High Score

Automated tools like the audits available in Chrome Developer Tools or stand-alone sites like webpagetest.org will give you letter grades or 0-100 scores that indicate how well your site is doing. It's a good idea to run these tools from the beginning of a project or any performance optimization work. Doing so will help you track changes over the life of a project and give your client a clear before/after if you are working specifically on speeding up an existing site.

Many of the recommendations that you will get from these tools can be fulfilled with performance-related modules and plugins. On the Drupal-side, the Advanced Aggregation module can handle tasks like inlining CSS and moving JavaScript files to the bottom of your page. In WordPress, the Autoptimize plugin does many of the same enhancements.

See our frontend performance guide for more details on how to max out your scores and raise your esteem.

Actualization: What Is This Page's Actual Purpose?

The wider conversation around web performance has recently moved toward concepts like "First Meaningful Paint." It may take a few seconds for every single element of your page to load, but will your visitors care if the page is loaded enough for their purposes within a fraction of second? Probably not.

Here is where performance best practice has to tie back into the rest of your website building discipline. Content strategists, accessibility experts, and (hopefully) your client will care deeply about identifying the most important parts of the page and putting them first on the page.

By getting the important parts of the page (a headline, a checkout form, a table of information) loaded quickly you do more than get a high score in Lighthouse. You help your clients, stakeholders, and site visitors think about something other than the speed of the site.

Transcendence

One of the benefits of a well performing site is spending less time thinking about about performance; or perhaps expanding your definition of performance. Conversions, bounce rates, engagement, and other metrics probably matter more to you (or your client) than time to first byte. A good TTFB is helpful to the extent it correlates with your client reaching their business goals.

From the Beginning

Many web development teams do not pay attention to performance until the end of a project. I have fallen into that trap. I have spent weeks and months building a site while not acknowledging that the site seems to be getting slower. Instead I hoped that in a "performance sprint" at the end of the project I could review some caching options and hope for the best. That was a bad strategy.

Projects are much more successful when each of the steps of the hierarchy are addressed throughout the project's lifecycle.

• Physiological needs: Make sure you have solid infrastructure from the beginning. Do not let a project get too far without knowing exactly what the production environment will be.

• Safety: Use tools like New Relic or modules/plugins like Query Monitor to catch performance killers as soon as they are introduced.

• Belonging: Use feature branching to experiment with new plugins and features so that if you decide against using a given plugin, that plugin never makes it into your master branch.

• Esteem: Test your site against performance graders throughout the site build so that you are not surprised by your score right before launching.

• Actualization: With performance data in hand, you can have informed conversations with your clients about the impact of certain features on the overall site performance.

• Transcendence: If you do all of these things throughout the life of a project you might actually spend less time worrying about performance and have more focus available for the business goals of the site.