This week Peter Chamberlin (BBC) posted some great content about performance as a feature; I highly recommend checking it out. Ultimately, performance is a feature that can increase the metrics that businesses care so deeply about. Although this is true according to,  the key to getting your team and business as a whole to support the constant focus on performance is to first acknowledge a core truth: Performance is not a finishable feature. I actually stole that line from a tweet-storm on the topic, but it describes this so eloquently:

Screen Shot 2016-03-03 at 1.57.08 PM

At Rigor, we build technology that aligns with this concept, and we have added a unique twist. Many technologies gather performance timings and metrics on sites like Rigor, Webpagetest, and Soasta. You can hook these tools into your deployment process to gain visual regressions or improvements in performance from a metrics perspective as you’re making changes to the site/app.

Screen Shot 2016-03-03 at 2.02.49 PM

This is a great way to visualize the performance effects of your changes, but what if the performance has regressed? Metrics only give you so much information; they don’t tell you what changes are causing the performance to regress. They don’t tell you what performance bugs you added during that last deploy. After all, improving performance is essentially a constant cycle of measuring and optimizing performance bugs, isn’t it?

Last week our engineering manager (Kyle) discussed how we automate this process internally at Rigor. When we deploy, we trigger a Zoompf analysis that searches for over 420 performance bugs and shows how to make the fixes.  If there is a regression in performance, we alert you via Slack with information on what performance bugs you’ve added or fixed and the commit link. This cuts down the time to resolution of performance issues drastically, requires fewer engineering resources, and provides transparency of what needs to be fixed throughout the team and the entire organization.

Comparing total defect count from Zoompf

Screen Shot 2016-03-03 at 2.33.26 PM

Screen Shot 2016-03-03 at 2.37.43 PM

We received a number of requests to open source the Zoompf/Slack Deploy trigger, and we’re excited to say that we now have. Remember that you can easily use this as a starting point and hook this into any deploy tool and other chat apps like Hipchat.

How it works

  1. Deploy this web service (Heroku is an easy platform)
  2. Add the web service as a “Deploy” webhook in your Semaphore project (docs)
  3. Make appropriate changes
  4. Raise your bottom line with increased conversions

Once configured, this webhook will:

  1. Trigger a new Zoompf snapshot on deploy of your server via Semaphore
  2. Compare the new snapshot of total defect count to the previous one
  3. Post the results in Slack

Peter Chamberlin says it well, “Performance isn’t a technical niggle that ‘we should get around to fixing.’ It is an opportunity to grow your audience, to grow your business, to convert more sales.” Rather than viewing web performance management as a terminable project, you should encourage your team to view it as a feature that requires ongoing attention and maintenance.

Interested in tackling your site’s untapped potential? Then you’ll love Rigor’s performance monitoring and analysis platform. Rigor tests your entire website and identifies over 420 performance defects that are slowing it down. Our continuous monitoring provides 24/7 performance visibility of your website’s performance and availability and allows you to understand exactly what you can do to make it faster.