In 2018, Erlend and I discussed that we should take our experience and thoughts about performance focused development, and make it into a method and workflow, for others to follow.

WordCamp Nordic would be the perfect opportunity to present the early start of a workflow that anyone can follow. So with WordCamp Nordic as the deadline, I started working on what is now The Performance First workflow.

Why do we need a new way of working with performance?

@thoaud gave an incredible talk about not using cache. It might a real eye-opener for many developers. #WCNordic pic.twitter.com/mny2UpZEMX — Maciek Palmowski (@palmiak_fp) March 8, 2019

When we look at the average page speed numbers, it is clear that we are making websites that are no way near any best practice of three seconds. To me, that tells me that we need to start doing website development differently.

Googles data about page speed for European countries. Source: Google

Our theory is that most developers don’t even know how much faster better code can be. We also think most developers think that cache is the best way of speeding up a site.

I tested this theory by doing a poll in the Advanced WordPress group on Facebook.

The majority of WordPress users that responded to the poll said they used caching for speed. Presented at WordCamp Nordic 2019.

The large majority of respondents answered that speed was their reason for using full page caching. Caching is in no way a magic bullet when it comes to performance.

The nature of caching is that no page is magically in the cache, and usually a visitor is needed for the page to be cached for the next visitor – so she’s able to get the same page, faster, from the cache.

There are only two hard things in Computer Science: cache invalidation and naming things.

PHIL KARLTON

We also see from data in full site performance tests we often do, that only a small fraction of the pages on a site are in cache, and that usually only between 5% and 20% of the page requests, are delivered from the full page cache . We do know of sites that can have up to a 50% cache hit rate, but they are very rare and they are almost always static (e.g. not eCommerce).

Important clarification: With cache, I am referring to full page caching, also known as HTML caching. I am not talking about static asset caching, object caching, CPU cache, micro-caching and other types of caching in the hosting stack.

Confusing information

Even though so many developers think that cache is the solution, many of the sites that try Servebolt hosting usually tell the same story. They have tried multiple cache solutions and a variety of optimizations, but don’t feel that the site is actually faster.

The cognitive dissonance is created through all types of channels. Online articles, Stack Exchange, ads, Facebook groups, blogs, help documents and marketing sits. We are surrounded by information that tells that caching is the remedy for slow performance, and that it will make your site faster. But when tested, you don’t experience that yourself.

A plugin list in WordPress, filled with both activated and deactivated plugins for caching and optimization.

And they are right. It’s not faster. Some pages are faster if you hit cache , but as you won’t be able to cache everything always, you won’t be able to deliver a fast experience to all visitors with cache as the main performance improvement technique either.

To forget about the full page cache in your development workflow, will result in better code that runs faster. You will easily see, feel and know when something you have done, has slowed down your site.

Want to know more about how caching works? Read my article on how caching works in WordPress.

The Performance First Workflow

It doesn’t matter if you build a site with plugins, off the shelf themes and a few CSS tweaks, or if you build the site completely from scratch with custom code. The Performance First workflow is designed to help you, and works no matter how you build your website.

Oh no, another something something first

In design we have mobile first, accessibility first, content first among others. In frontend code, we have mobile first and accessibility first. All these are trends in web development because they make sure that the websites and online stores you build has the user and the way the website will be used in focus. But, when doing backend code you don’t have anything like it. You have coding standards, and unit testing etc , to make sure your code is easy to read and understand, that it doesn’t break functionality and so on.

But in backend code, we don’t have that many “firsts”. I could come up with one, and it’s called “Shortcuts first, because of project deadlines”. And the lack of a method and main focus is one of the reasons I believe we need the Performance First method and workflow. Developers, agencies, and clients need to know the importance of performance, and commit to making websites faster and with better code.

How the Performance First workflow works

The Performance First workflow has two main parts:



The performance budget

The performance test

Between those two main parts, there are “rules” and a workflow to follow. Rules and a workflow is there to ensure that you, as a developer, don’t introduce code that slows down the site you are working on.

The main rule in the Performance First workflow is that the performance budget is absolute. Like with your money, you cannot exceed the budget at any point.

Join the performance conversation on Twitter using hashtag #perffirst

Step 1 – Make a performance budget

The first step, regardless if you build a new site, or start working on an existing one. You need a performance budget. The Performance First budget consists of two main factors, time and size.

How many seconds do you have to spend?

How many kb can you transfer during that time?

To make it even easier, we can break those two into four KPIs.

Download of HTML (first request) Page size DOM content loaded Fully loaded

You can add as many performance KPIs as you wish, the more KPIs you have the better. But, the more KPIs you add, the more complicated you make the next steps too. And you should have a good understanding of any KPI you add because behind any KPI there are hints of where a possible performance problem is. More on that later.

Step 2 – Do your code/change

The second step is to build whatever you want to build or change on the site.

The more times you have worked through the steps in this workflow, the more performant code you will be producing. If you build websites using page builders, you will likely already have changed your standard setup to a more performant one when you have worked through the Performance First workflow a few times.

Step 3 – Test performance

After you have made your changes, it’s time to test the performance of what you have introduced or changed.

What should be the scope of your test?

You can test performance with different scopes:

Function/fraction of code

Single page

Full site

Testing a function or fraction of code

Testing the performance of a function or fraction of code is usually done during your continuous integration (CI) process. For many normal websites, this is unnecessary complicated and time consuming.

Single page testing

Most people test single pages, using single page test tools like WebPageTest.org (or tools.pingcom.com, GTMetrix). These are easy to use tools and good enough for most. However, the problem is the fact that they are only single page testing tools.

Single page testing is for most websites a to narrow scope. A single page performance test is not enough, unless you have added code that only impacts a single page.

In most cases, any code you add will impact more than one page. If you add a plugin or module it will impact more than one page, guaranteed.

Full site testing

Full site testing is what most developers should do more of. Full site testing is done either by testing a preset selection of pages, or by crawling the site in full.

With full site testing you can see the impact of your change, across multiple pages, and hence identify performance issues on pages with different scenarios.

Full site testing can be implemented into your CI process, or be done manually with tools like Sitebulb and Screaming Frog. The important thing, regardless of what tool you use, is that you are able to get the KPIs you have in your performance budget for each page.

Personally, I recommend Sitebulb. I really like the possibilities it provides, and that it gives me a lot more than just performance information. In its core, SiteBulb is an SEO tool that gives you a lot of information about possible SEO improvements.

The main reason for me to recommend SiteBulb is that you can run the tests locally, from your own computer, on a site you run locally. This gives you a controllable environment and makes it easy to run regardless of where you are, and the test will not be impacted by network latency and so on. The important thing to remember, if you run this locally, is that you then have relative numbers to your budget. Relative to how much slower your local environment is to whatever environment you will be running in production.

Step 4 – Did it affect performance?

After you have done the performance test, you have to determine if what you did affect the performance of the site. After you have determined that, you enter the final stage.

Step 5 – The decision map

The decision map, or the dance as I like to call it, is the part of the workflow that is most strict. If you do not follow this part, the rest is close to useless. You start out on the tile that answers the question – Did it affect performance? A simple question, either yes – or no.

The decision map, as presented at WordCamp Nordic 2019 in Helsinki, Finland.

No. My change did not affect performance

The flow when a change does not affect performance, is quite simple:

Did it affect performance? Did it increase page size? Are you above the overall budget?

If it did affect performance, the flow is a bit more complicated, and you may eventually have to head back to step 2 and improve your code.

To be forced back to step 2, to improve, rework or rewrite your change – is a good thing. That leads to you learning new things, thinking differently, and learning new ways to write better and faster code.

Yes. My change affected performance

If your change or added code affected performance, the workflow becomes a bit more of a dance.

The first thing you will need to figure out is if the degraded performance is worth it. This decision is totally up to you. If it’s not worth it, head back to step 2, and find a better and faster solution to whatever problem you have tried to solve.

Yes, it is worth it

Ok, so the degraded performance is worth it. Then the Performance First workflow has a security net in case you make this decision too many times. The overall performance budget, which is an absolute and can never at any point be exceeded.

The step after determining if the degraded performance is worth it, is to check if the change has exceeded the performance budget. If it has, then you have to go back to step 2, and rework your code or in some other way find a better and faster solution.

Help! I have exceeded my performance budget

If you have exceeded to average performance budget, you will need to rework your code. An important note here is that you don’t necessarily need to rework the code you have just introduced. It can be both easier and smarter, to rework some other part of the code that takes up a larger part of the performance budget instead.

When you exceed the budget you need to figure out what part of the budget. When it is the time to first byte (TTFB), you have two options. Try faster hosting, or rework your code with the help of profiling tools to figure out what made it slow. Profiling is time consuming and often difficult , and hard to do if you don’t have an advanced and diverse skill set.

The deploy step

You have worked through the workflow, and ended up in the deploy step. Good work!

Deploy the new version of your site to the internet, make it public, and viewable to the internet. But, before you give yourself a pad on the back, we need to do the very last step of the Performance First workflow.

Enable cache

Enabling cache is the last step in the workflow, always. Never at any point earlier in the process.

The reason for this being the last step is that you should not, at any point use cache (full page cache, html cache etc) as a performance improvement. If you use cache for performance, you are guaranteed to end up with, at some point, with users having a bad experience since they are the unlucky ones that does not hit cache.

When cache is taken out of your website performance toolbox, you will need to push yourself and your work, to the next level to reach the level of performance your website’s visitors require.

If you have cache in your toolbox however, it’s easy to just enable it and trick yourself into thinking it’s a good solution. It’s not.

Now, it’s up to you

Implement the workflow, work with it, and see what happens. I’m 100% sure you will end up with faster sites, better code, and happier clients.

Please comment you have any questions, critique or just feedback. The Performance First workflow is going to be updated, and improved, and we are also looking into making this into a open source project with tools, and tips to make working Performance First easier.