Zoompf's Web Performance Blog

Note: Archived Content

This is the archived version of the Zoompf blog. Since our acquisition by Rigor, all our new research and posts on web performance are being published on The Rigor Blog

The Surprising Thing about Pregnancy and Performance

 Zoompf Performance on June 29, 2015. Category: Uncategorized

When you or our loved once find out you’re pregnant, you start visiting the doctor and getting sonograms as soon as possible, right? You don’t wait until the baby is born to check things out. So, when you’re “pregnant” with a new website or web app, why would that be any different? Why would you wait until you launch to monitor performance?

You wouldn’t. A baby develops WAY more in utero than he or she does after birth. I mean, sure, the kid gets big, eats a lot, and starts having conversations with you, but that change is minimal compared to the fact that form a couple of cells that didn’t know each other to a bouncing baby [fill in your choice here] in nine months. The changes that occur are almost hourly, and most certainly daily.

But we’re talking about websites and web apps, right? Yes! Which is what I mean by hourly and daily changes. So, here’s just a few ways you could/should test your website and/or web app before it’s born you launch it.

  1. Begin using performance tools as soon as you have an MVP, so you can find performance issues as they arise. Since you are (should be) designing for performance, you’ll know if there’s an issue immediately upon adding a new module or ball of code (“ball of code” is the SI approved unit of code measurement).
  2. Testing in pre-production also gives you a daily assessment of what changed, because this baby is changing constantly, and each day will bring new issues, incompatibilities, performance issues, and other unexpected finds. Having a daily report of all your changes is a very important tool as you proceed towards birth/launch.
  3. And when those issues pop up, your performance tools can provide you with a faster triage – what’s the problem?!? – and an answer for how to fix that problem.
  4. Knowing there’s a problem weeks before launch enables you to address the problem as a tiny little blip rather than a big nasty customer facing bug. But you only find out of there’s a performance issue in pre-production if you’re testing before you launch.

So what do we mean by “performance tools”? As we discuss a whitepaper, there are many different classes of performance tools, such as load testing tools, monitoring tools, and root cause analysis/auditing tools. In pre-production, we find the best tools are root cause analysis tools like Zoompf, and to some extent monitoring tools as well. The monitoring tools can tell you if there has been a large change, and the root cause analysis tools can tell you what performance defects were introduced. If want to know more about the different types of performance tools, download our whitepaper.

Knowing that it’s best to have development, design, and IT/hosting involved and working together from the start, rather than making a frantic call to hosting to crank up the power of your server, it becomes easier to see why performance testing should start well before launch.

Image courtesy Wikimedia

Image courtesy Wikimedia

If you are interested in performance testing early in the development cycle, then you will love Zoompf. We have a number of free tools that help you detect and correct front-end performance issues on your website: check out our free report to analyze your website for common performance problems, and if you like the results consider signing up for our free alerts to get notified when changes to your site slow down your performance.


Have some thoughts, a comment, or some feedback? Talk to us on Twitter @zoompf or use our contact us form.