Debug Your Performance Defects with Zoompf Alerts
In this post I wanted to highlight some of the great free tools now available to our Zoompf Alerts beta users for debugging and fixing performance defects. (And if you’re not on the beta, it’s still not too late to sign up!)
Understanding the Problem
The first step to fixing a problem is of course understanding it. Zoompf Alerts currently tests for 10 different high impact performance best practices: Static File Caching, Content Compression, Image Optimization, Combinable Resources and more.
To see this list, first log into your Zoompf Alerts dashboard and scroll down to the bottom of the page (example). In the “Defects By Type” section, you’ll see a brief overview of each performance rule, with open defect counts and a link to more information.
Click on any rule title to view a detailed description of the defect and its solution. You can also link to this description directly from your alert emails:
This new page is called the “Rule Detail” page and contains a wealth of information: an overview of the defect, your current list of open defects for this rule, and steps to resolve this defect on the common server platforms. For example, here are some screenshots from the “Static File Not Cached” rule detail page for our NewEgg demo account
Each page is highly specific to the type of performance rule being evaluated.
That covers the theory part, now on to the practice. To debug, you’ll want to see “point in time” specifics captured for that defect. Fortunately you’re in luck – there’s a wealth of historical data displayed for each defect on the “Defect Details” page. There are 2 primary ways of accessing the Defect Details page. First you can click the “Details” link in any defect list in your portal, for example:
Alternatively, you can also link straight from your email alerts:
Once on this page, you’ll see a number of useful metrics captured from each point in time snapshot the defect was found. First, the exact time, full URL and body size of the impacted URL.
The specific URL is more important than you may think, as many content systems can version their URLs over time (example “myfile.js?v=1” changes to “myfile.js?v=2”), so the utility of this field is not simply to identify the defect, but also to track name changes as new builds are pushed to your site.
In addition, full HTTP response headers and bodies are captured at the time this defect was found. Viewing the exact response from the webserver captured at a specific time can be invaluable to debugging changes to your server configuration, or spotting intermittent results across different servers on your web farm.
If the defect refers to a potential file size optimization, information about the potential savings is also displayed, and in many cases a link to download the actual optimized file! If the file is an image, you can even use a handy slider to compare the unoptimized and optimized image quality side by side:
And for the hardcore bit-heads, there’s even an inline hex viewer available to see the contents of the image file.
This is a useful way to see the extra bloat in your images firsthand. (For more information check out our blog post Visualizing image optimizations with hex editors and strings).
At the very bottom of the Defect Details page you can view the Referring Pages list. Referring pages give you the context of how our crawler located the particular defect. For example, an unoptimized image may have been included by one of your CSS files, rather then the root HTML page itself. Using this table helps you locate the source of the defect, and plug any holes you may now have known existed.
What’s particularly useful here, is you can continue to link up the reference tree. So for example, you can view not just that your image was included by a CSS file, but also click that CSS file to see the full response bodies for the parent that linked in that CSS as well!
And last, but not least, if you’d like to see how that defect has changed over time, simply use the next/previous snapshot button at the top of the page to track through those changes.
Pay special attention to any changes to the URL, as often this can happen if you are using a custom or off the shelf publishing platform. There’s a lot of under the hood “magic” to link these changed names to the same defect in your detail view, a topic we’ll likely expand upon in a future blog post.
We hope you’ll find these tools helpful in debugging your performance defects and optimizing your site. Of course we’re always adding new features and if we’re missing something, we’re very receptive to your feedback.
If you’re not already on the Zoompf Alerts beta, there’s still time! Join now for free.