×

Last night I was having a beer with a web developer who works for a SaaS company here in Atlanta. Naturally, we ended up talking about web performance and workflows.

“How do make sure your homepage stays fast when you make design changes or add new tags?”

“Well, we have a tool in our CMS that automatically optimizes images when someone uploads them. We automatically concatenate JavaScript in each build. And, we have a number of tools that check for things like broken JavaScript, problems with Ruby, or problems with our static site framework. These tools have rules that will fail the build and prevent us from pushing bad code into production.”

“Cool. But, what if it’s not broken – just something that will make your site slower?”

“Eh, when we’re pushing new code we use developer tools. We simulate some throttling and make sure the new code isn’t making things significantly slower. If it looks a lot slower we roll things back or make compromises to make the site fast again.”

“Nice. How often does your team push code to your site?”

“Sometimes several times a day.”

This is coming from a person who works with a very smart team of people. They happen to have one of the fastest, most reliable marketing websites in their industry. On one hand, they’re doing all of the right things:

  • Using logic in their CMS to make automatic image optimizations, preventing user error;
  • Automatically concatenating and minifying JavaScript in each build;
  • Running tests on staging to make sure they won’t release broken code into production; and
  • Watching the incremental impact of changes on performance.

But, the next morning, out of curiosity, I ran a Rigor Optimization scan on my friend’s features page. Knowing that my friend’s team has so many bespoke optimization automations in place, I was surprised to find a few performance defects that slipped through the cracks. I found some SSL/TLS content served from a http:// page, a number of resources without far-future caching, and a handful of unoptimized images.

Defect Detail PNG

Rigor Optimization can identify unoptimized images and suggest how to correct them.

Now, I’m not interested in shaming my friend or his team. It’s possible that they’re aware of these defects and that they have some strategic business reasons for deferring fixes for these issues. But, at a basic level, these performance problems are bugs, just like functional bugs, and they deserve to be treated as such. A “bug” is any unintended program behavior. Someone in the organization made a mistake or inadvertently added an unoptimized image. Then, the automations and tests didn’t catch those mistakes.

These bugs might not be significantly impacting performance today, but if similar bugs make their way into production – remember: they’re pushing code several times a day – they could see the response time for their website increase over time. Worst case scenario: one day my friend wakes up with a website that takes 2 or 3 or 4 more seconds to load, and the whole team ends up in a fire drill to diagnose and correct all of the issues.

Troubleshooting and fixing bugs after they’ve already been pushed to production costs significantly more than preventing the problems in the first place. This is exactly why teams use programmatic tools in their continuous integration systems to fail builds and prevent functional problems from going into production.

How can you gain the confidence to know that you’re:

  • looking for all possible performance bugs, and
  • verifying that processes and automations are working as intended to prevent these bugs from releasing into the wild?

Confidence in Continuous Integration

If you have bespoke processes and automations in place, Rigor Optimization acts as a safety net, giving your team the confidence of ongoing coverage for potential performance optimizations.

Rigor Optimization tests for quality and catches performance bugs before they go live into production. Each scan looks for hundreds of unique types of performance defects, covering everything from unnecessary redirects to unoptimized animated GIFs. You can kick off Optimization scans via API or automatically as part of a build.

At Rigor we heard from many of our users that they use Jenkins for their continuous integration builds. To help our users identify performance bugs before they go live, we added the ability to trigger Optimization scans from within the Jenkins build process. And, we gave users the ability to define exactly which performance defects should fail a build based on customizable thresholds.

We believe that customizable performance optimization should fit lockstep into your continuous deployment workflows. We’re eager to learn how your business is actively preventing response time creep and to learn how we can continually improve and automate the process of checking for performance defects.

Interested to see what types of performance bugs are slipping through the cracks? Or, ready to use Optimization as a safety net in your continuous integration? Add the Jenkins plugin and connect it to your existing Optimization account or contact us to start a trial and try Rigor Optimization today.

Suggested Blog Posts