We’re always looking for great tools to make it easier to design, build, or test WordPress sites. We’ve grouped these tools broadly by function. If we failed to mention your favorite, you can fix that by letting us know in the comments.
Performance Testing Tools
Performance testing tools are a great way to see how fast a page on your site loads in a browser. A common report is a waterfall showing the content on a page loaded over time. When a web page is loaded, each image, script, or CSS file is loaded with a GET request. A waterfall report typically shows each request in order, along with the size of the request and the time it took to complete it. The combined size of all requests on a page is referred to as page weight; it’s usually measured in kilobytes or Kb. As a general rule, you want to minimize the number of requests and the total page weight.
Performance Testing Using Your Browser
- Built-in Developer Tools, usually available by pressing F12
You can test your site’s speed by using a browser that supports the HTML5 Draft Specification (such as Internet Explorer 9 or greater, or current versions of Firefox, Chrome, or Safari on a Mac). Browsers load content using a series of DOM events, and there are 2 events that are important for monitoring performance: DOMContentLoaded and load. The DOMContentLoaded event fires first, and it’s triggered when the entire document for your page has been loaded and parsed. The load event fires when the entire document has finished loading, including external resources that aren’t required to render the page.
Resources that are normally loaded on the page but aren’t required for rendering are often referred to as asynchronous or non-blocking. For example, if you use Google Analytics to monitor site traffic, it loads a script to do that. However, the script does not have to finish loading to render the page, so the DOMContentLoaded event will be completed before that script is loaded. If your page only uses a few resources that don’t need to load to render the page, the DOMContentLoaded will be just slightly less than the time to complete the load event. The more non-blocking resources your page loads, the bigger the difference between the DOMContentLoaded and load events will be. When there’s a big gap between the DOMContentLoaded and load events, that’s an indicator that the external resources on the page were slow to respond. That can fluctuate over time, but consistently large gaps mean that you’re loading a lot of slow resources. Your visitors will see an indicator that the page is continuing to load until the load event completes, and that can make a fast page seem slow.
In Internet Explorer and Chrome, pressing F12 will bring up the browser’s Developer Tools. In Firefox, if you have the Firebug extension installed, F12 will bring up Firebug and Ctrl + Shift + Q will bring up the browser’s native developer tools. Browser-based Developer Tools provide a wealth of information, and one of the most popular uses is to explore HTML and styling. For this discussion, we’ll focus on load time performance information on DOM events in the Network tab.
The screenshots below show the Network tab of Developer Tools in Internet Explorer, Firefox, and Chrome, respectively.
Performance Testing Using an External Site
- Google PageSpeed Insights
- Pingdom Tools
Don’t simply take the reports provided by performance testing sites at face value. Like the weather, performance results will fluctuate, and they’re influenced by a wide range of factors outside of your control.
Tests performed from one location will yield results that are very different when performed from a different location. Pingdom provides some settings to control test location, and WebPageTest.org provides more, but many testing sites don’t offer any location settings.
Moreover, most testing tools compare a site’s performance to a general performance measurement of the overall web. For example, Pingdom reports that a site is faster or slower than some percentage of all other sites, which might represent the universe of sites they’ve tested. That’s a good way to see how your site fits in to the larger internet. But if your legitimate needs require you to have a content-heavy site and you’ve done everything you can to minimize page weight? Pingdom’s comparison to a larger pool of sites can send the wrong message if those sites have more or less page weight. That is, if your site is very heavy, and Pingdom reports that it is slower than most other sites, that might simply be because they have a lot less page weight. Likewise, if Pingdom reports that your site is faster than just about every other site on the internet, it might be a meaningless conclusion if you’re not loading much content.
Despite the limitations and cautions, performance testing tools can provide important insights on the number and weight of each request necessary to build a page on your site, as well as the time it takes for each request to complete. That information can enable you to identify requests that take more time than they should or to reduce the overall number and page weight of the requests.
Responsive Design Testing
- Google Mobile-Friendly Test
- Malte Wassermann’s Viewport Resizer
- Retro – Basic info on screen resolution, viewport size, pixel ratio, user agent, and IP address
- Viewportsizes.com – Filterable list of device viewport sizes with a tool to find your viewport info
It’s important to see how your site looks on a wide range of devices, but in many cases you want to test your site on devices to which you don’t have easy access. That’s where responsive design testing tools come in. They allow you to simulate characteristics of another device to see how your site might render on it.
The first link on the list is to Google’s Mobile-Friendly Test. It’s first on the list for a reason: it’s important to check each of your site’s pages that use a different template to make sure Google considers them mobile friendly. If you’re using an unmodified theme, pages should pass this test. The most common error we see is where custom CSS has been applied that puts buttons, form fields, or links too close together. On a mobile device, these are called tap targets. Be sure to size tap targets appropriately.
For themes that support mobile responsive design, you can also explore how your site will render by dragging your browser to a different size. You should see a smooth transition as the width narrows, without noticeable breaks in the design.
Using simulators and changing the width of your browser are useful techniques, but they’re no substitute for actual testing on the target device and browser. For example, if you use Safari on a Windows-based PC and drag your browser to a different width, the results you see might not match what a visitor using mobile Safari sees. You’re ignoring that Safari on mobile devices is a completely different version than the one you’re using for your test. That version difference can introduce rendering differences. If you understand the limitations of these techniques, you’ll be better able to make use of the results you see.
Checking your site to make sure it uses valid markup is important, because invalid markup can break your layout. Hard errors such as unclosed
divs have to be fixed, but it’s equally important to avoid being obsessive about fixing all validation errors. For many WordPress sites, validation errors are introduced by plugins and are difficult to track down and fix, and not all validation errors are of equal significance. And perfect validation isn’t an SEO requirement. Your goal should be reasonably valid markup that renders consistently across the browsers making up the lion’s share of your traffic and allows search engines to index your pages.
- Quirktools – A collection of several useful tools including:
- Golden Ratio Typography Calculator – Recommendation on line height based on font size & line width
These tools don’t fit in one of our other categories, but we’ve found them useful from time to time.