Jetpack SuperCache

  • Role: Design lead
  • Skills: Ideation, UI design, Prototyping, Product design
  • Tools: Figma
  • Duration: Three weeks
  • Iterations: Two

With over 2 million installations, WP Super Cache is one of the most popular open source caching plugins for WordPress. I like to think of it as one of the original static site generators.

This project was a short exploration to understand how WP Super Cache could be modernised and become part of the Jetpack suite of products, alongside Jetpack and Jetpack Boost. As an exploratory project, it was largely free from existing constraints and was used to kickstart further discussion about potential futures.


Caching is complicated. Most popular WordPress caching plugins are jargon heavy with tonnes of inline documentation to try and ease the burden of configuration and management. WP Super Cache is no exception with pages of toggle switches, radio buttons and inputs used to tweak cache behaviour.

Whilst a technical interface makes sense for a certain subset of WP SuperCache users, our data suggested that the plugin is being used by a much broader range of people. It has the potential to be installed by any WordPress user looking to improve site performance.


Optimising for first time use therefore felt like a good place to start. What can we do during the first use of the plugin to both explain the concepts of caching and the benefits of the plugin?

A soft landing

When launching the plugin for the first time, you will enter an onboarding flow which is used to explain caching, why it matters and also the premium features that are available. This would be shown on first launch and could be expanded to include more cards as the product matures.

Your first use would also be guided by a “getting started” tutorial, explaining key features of the interface, how they work and most importantly, why you might need to use them.

A new approach to settings

Making caching simpler

At its most basic, WP Super Cache is an on/off switch. The challenge becomes tailoring cache behaviour to your particular site requirements. The burden of configuration falls to the user in the existing UI. I believe the solution is to run a number of automated checks during cache activation, ensuring compatibility with other plugins and configuring sensible defaults.

The primary on/off tool becomes a big feature of the UI, and the status ring is used to indicate current plugin state and actions being taken.

Simply activating caching should be enough for most users to get started and see strong performance improvements.


Imagine for a moment that you wanted to create a homepage banner that was tailored to the operating system of the device visiting your sites homepage. On Windows it might say “Install the Windows .exe file”, on Mac “Download the .dmg” and on Android “visit the Play store to install the app”. Caching could easily break this functionality, as we now need different caches based on user agent or operating system.

Changing cache behaviour based on the visitor type (logged in vs logged out), URL, file, device and browser are pretty much all possible in the exiting plugin. They are unfortunately quite primitive. You cannot mix these categories or define specific circumstances in which caching can be turned off, or a new cache is defined. The settings are also loosely grouped under various tabs and sections.

Audiences would allow you define these kinds of rules, targeting the specific visitors that require a separate cache. Most of the WP Super Cache interface could be simplified behind this concept, allowing for heavily reduced settings screens.

Demonstrating value

The existing WP Super Cache plugin is really just a huge collection of settings, once configured, there is very little need to revisit the plugin screens (set it and forget it). How do users know the plugin is working? How do we show value?

I believe the solution will be to introduce statistics for both effectiveness and site performance. This gives users a reason to check back from time to time and is aligned with the approach taken in current Jetpack plugin.

Woah this is really breaking new ground, and an excellent unbound exploration bringing fresh ideas. :)

— Erin Casali, @folletto


To help communicate these ideas with the wider Jetpack team I created a Figma prototype with a number key interactions and screens available to test. The prototype can be found below if you wish to test it yourself.

Try the prototype