This is not entirely unexpected because the top sites tend to have dedicated developers who custom-built the back-end code for serving pages and have dedicated operations teams that watch the performance of the systems and databases and spend a lot of time focused on the performance and scalability of the back-ends.

As you move out of the top tier of Internet publishers you start running into sites that are running on off-the-shelf content systems (Drupal, WordPress, Joomla, etc) and with owners who either contracted for the site development at one point in time or used and tweaked an available template and then used a collection of plugins to put together their site (often not knowing how the plugins themselves work). The hosting for these sites also varies wildly from dedicated servers to VPS systems to running on shared hosting (by far the most common) where they have little to no insight on the performance of the actual systems their site is running on.

As a result, it’s not uncommon to see something like this:

Yes, that is a 30+ second time to first byte (TTFB) with all of the time being spent somewhere on the back-end to assemble and produce the page. This wasn’t an outlier either. For this page, EVERY page load takes 30+ seconds before the browser even gets the first bit of HTML to work on.

This isn’t unique to this site or the Content Management System (CMS) it runs on (though it is an extreme example). It is not uncommon to see 8-20 second back-end times from virtually all of the different CMS systems.

This is really painful for users (assuming any of them actually wait that long for the site) but it also causes scaling problems for the back-end because the application is tied up for a long time processing each request making fewer resources available for other users.

What is a good back-end time?

A good target for just the processing time for back-end requests is on the order of 100ms (0.1 seconds). That doesn’t mean you should expect a TTFB of 100ms, just that the back-end processing time shouldn’t take longer than that. It is important to remember that the user can’t see ANYTHING at all before the TTFB so any improvements there go directly to the user experience.

When figuring out the back-end time from a front-end tool like WebPagetest, you need to remember to include the network latency. For that I usually use the socket connect time to the server (orange bar) as the RTT and then use that as a baseline for everything else.

In this case, the DNS lookup time (teal bar) is taking longer than I would expect but you want to compare the size of the orange bar to the size of the light green bar. The length of the orange bar is the fastest the server would be able to reply and assumes 0 back-end processing time so if they are reasonably close in size then you’re in pretty good shape.

Eyeballing waterfalls is good for a general feeling but if you want to see the specifics, you can get the individual component times in a data table below the waterfalls on WebPagetest:

In this case you just subtract the initial connection time from the TTFB and you have the amount of time that was spent on the back-end (436ms here).

Figuring out what is going on

So, you know you have a back-end issue, how do you figure out what is causing the problem?

The problem is almost certainly caused by one of these issues:

• Web server configuration that is out of available clients to process requests
• Slow database queries
• Back-end calls to external services

Unfortunately, most of the performance tools you are used to using don’t have any visibility into those components and they become a black box. At this point you need a developer and a sysadmin (or someone with the skillset to do both) because fixing it is going to involve code or site configuration changes. Even just finding the source of the problem requires a pretty decent skillset.

There are commercial solutions that will identify the issue for you really quickly with minimal work. Actually, there is a whole sector focused on it (called Application Performance Management or APM). I’ll use New Relic as an example here because it is what I use on webpagetest.org but Dynatrace is another common solution. All of them require that you install binary code on the server though so if you are on shared hosting these may not be available options (and once you get through the free trial phase most cost more than shared hosting plans anyway).

Once configured, the APM tools will monitor your production systems and tell you how much time your server is spending in the various different tiers:

I’ve done a fair bit of tuning to WebPagetest so there’s not a whole lot to see here. Average response times are ~10ms and the database is only used for the forums so the bulk of the time is spent in the actual application code.

From there you can drill into each band to see exactly where that time is going:

In my case, most of the CPU time is spent generating thumbnail images (which includes waterfall thumbnails) for the results pages. Not completely unexpected since they are all generated dynamically by code.

The thumbnail generation is something I spent a fair amount of time optimizing because it used to be a LOT more resource intensive and took close to 80% of the time. The tools let you keep drilling in to see what specific functions contribute to the time:

They let you do the same for database calls and for particularly slow requests they will provide diagnostics for individual requests instead of just aggregate results so you can also drill into slow outliers easily.

If you aren’t fortunate enough to be able to use the tools then you have to look into what is available for your platform to see if there are free diagnostic tools or you have to start instrumenting the code yourself. In WordPress, for example, there are several plugins that will debug the database queries and tell you how long they are taking.

W3 Total Cache is a useful plugin for improving WordPress performance but it also provides debugging information that will help you identify any slow database calls:

When you enable the debug information, details about every database query (and cache operation) will be logged into the page HTML as a comment that you can view by visiting the page and viewing the page source:

You’ll get the overall time spent in database queries as well as timings and details for each and every query.

Fixing it

Great, so now that you’ve identified the issues the real hard work starts. The most common “solution” people use is to add caching to hide the problem. This can be in the form of a plugin like W3 Total Cache that will let you cache all sorts of different operations to custom query caches using memcache. Caches are absolutely necessary but you should improve the underlying issue as much as possible before enabling caching, that way 100% of the requests will get improved performance.

Finally

As they say in carpentry, measure twice, cut once. Don’t go optimizing your site until you have measured the user experience and then use the measurements to guide your work, not grades or scores from various tools ñ they may not be relevant to your particular situation. Just because sites normally spend most of their time on the front end doesn’t mean that is necessarily the case for yours.

A resource like the performance calendar is a really great tool for finding ideas to apply to your own work. Many of the authors of this site are lucky in that they spend a significant amount of their time optimizing large sites for companies like Facebook, Yahoo! and Google (and yours truly, Walmart). However many developers have lots of other responsibilities other than performance.

When you have lots of things on your plate measuring more than pays its way. While it is easy to grab a technique that someone has laid out for you and apply it (and you should) you should make sure you target the issues that affect your site the most. I was at a conference a few years ago about JavaScript and an extremely prominent, talented and altogether smart JavaScript expert gave a talk about performance optimization. He gave a number of in-depth tips including unrolling loops and other micro-optimizations.

Here is the thing; When you are the author of a framework used by many thousands of sites every hour you spend optimizing the code pays off on every one of those sites. If you make helper functions used over and over your work repays itself many fold through each small usage. However, when you only care about the one site you maintain unrolling loops probably won’t make a significant or obvious a difference to your users. Optimization is all about picking the correct targets.

This is where we come back to measuring again. When you don’t have a clear understanding of where your bottlenecks are you need to measure before you cut. Measuring performance can be done in many ways and this is also important to consider. Unrolling loops in JavaScript is a very atomic micro optimization. It improves one specific function. However unrolling a loop that loops only twice and is only used by 1% of users is clearly not an important use of time.

The key to measurement is instrumentation. Start at a macro level. What are the most important parts of your site? This might be the ones used the most, or the ones which have the most impact on your business (such as the checkout process). You might find yourself surprised, perhaps you receive a lot of search engine traffic to a page deep in your site that is poorly optimized. Improving that page by 50% might make a much bigger impact than spending the same time getting another 1% improvement on your already optimized homepage. The only way to really know which pages on your site are important are to look at the stats or to discuss priorities with whoever is in charge of the site.

Once you know what’s important, the next task is to figure out what users do with those pages, or again what you want them to do. It’s important to note in this process that what customers do now may be an attribute of the current site and not actually what you want them to do. Identify which parts of your site are used the most by finding the most common tasks on the page. Which page level items (menus, search results) do users interact with most?

So here is our formula for optimizing:

• Step 1. Use instrumentation to pick which pages/sections to optimize
• Step 2. Use instrumentation to pick which features to optimize
• Step 3. Optimize

Measure twice, cut once.

Identifying Pages/Sections

How do you go about picking which pages or sections of your site to optimize? This probably one of the easiest tasks because most conventional metrics give you everything you need to know. Start by seeing which pages get the most views. This will give you a short list of obvious targets. Your homepage is almost certainly one them, and then other popular pages on your site. These should be your shortlist.

The next thing to do is talk to your business owner. That might be your project manager, CEO, whoever. The most popular pages are not always the most important to the business. Checkout and shopping cart are very obvious examples here. If you run an e-commerce site many many people will browse many items, but only a small percentage of people will check-out. This doesn’t mean check-out isn’t important. On the contrary. Checkout is really important, it’s just something that metrics many not help you prioritize.

Now you should have a list of the pages or sections of your site which are a mix of the most popular or important ones to the business. This is your hit list. Keep it up to date periodically. Until you’ve exhausted your hit list don’t bother with other performance issues.

Identifying Features

On modern web sites many pages share the same code on many pages. Look at the code to find these features or use a packet sniffer like Wireshark, Charles Proxy or the Chrome Inspector or the Chrome Inspector on your hit list pages will help you get a list of the remote resources that were accessed. You can also examine your HTTP logs to look at what secondary web service resources are being requested for those popular pages. Those resources could also be a blocking factor in page rendering.

You should also try to identify what your users are doing on each page. This can be difficult. Unless you have a very rich metrics system you probably don’t know where the users’ cursors are, or how much they scroll. What you can probably do, however is look at what where they commonly click to from your hist list pages. This will give you an idea of what is being used the most. For example, on an product description page it might be the “add to cart” button. You should also look at timing, things like navigation menu items are going to get clicked a lot sooner after rendering than an “add to cart” button in general. This is because when people buy things they normally read the product description first. When they are navigating they aren’t reading page content, yet. You can instrument your pages with JavaScript or you can compute the time between page loads per user if you want to be a clever-clogs.

In general the goal is to figure out which things the user will need most readily. As an informal rule of thumb consider prioritizing items to load in this order:

• Items above the fold
• Navigation item (Menus, search bar)
• Items that provide information (Product description, News stories)
• Items to take an action (Add to cart, etc)
• Items below the fold

You can check how fast various things load on your site using WebpageTest‘s film strip feature.

Optimizing

The final step is of course optimizing. Remember even within optimizing a feature don’t spend all your time optimizing something that is already optimized when there is something used 90% as much that isn’t. That’s the point of metrics to make good decisions. This goes both for your list of pages and features, and within the code. The goal of optimizing should be to take your measurements and then make the best use of your time to affect the users’ experience. Check out page render and JavaScript profilers and techniques.

There are lots of resources out there, once you know what you need to optimize go and find something to solve your problem, and then measure, measure again.

Enter one of this year’s most interesting open-source projects: PhantomJS. Thanks to Ariya Hidayat, there’s a valuable new tool for every web developer’s toolbox, providing a headless, yet fully-featured, WebKit browser that can easily be launched off the command-line, and then scripted and manipulated with JavaScript.

I’ve used PhantomJS to underpin confess.js, a small library that makes it easy to analyze web pages and apps for various purposes. It currently has two main functions: to provide simple page performance profiles, and to generate app cache manifests. Let’s take them for a quick spin.

Performance summaries

Once installed, the simplest thing to do with confess.js is generate a simple performance profile of a given page. Using the PhantomJS browser, the URL is loaded, its timings taken, and a summary output emitted – all with one single command:

$> phantomjs confess.js http://calendar.perfplanet.com/2011/ performance

Here, the confess.js script is launched with the PhantomJS binary, directed to go to the PerfPlanet blog page, and then expected to generate something like the following:

Elapsed load time:   6199ms
   # of resources:       30

 Fastest resource:    408ms; http://calendar.perfplanet.com/wp-content/themes/wpc/style.css
 Slowest resource:   3399ms; http://calendar.perfplanet.com/photos/joshua-70tr.jpg
  Total resources:  69080ms

Smallest resource:    2061b; http://calendar.perfplanet.com/wp-content/themes/wpc/style.css
 Largest resource:    8744b; http://calendar.perfplanet.com/photos/joshua-70tr.jpg
  Total resources:  112661b; (at least)

Nothing revolutionary about this simple output – apart from the fact that of course, under the cover, this is coming from a real WebKit browser. We’re getting solid scriptable access to every request and response that the browser is making and receiving, without having to make any changes to the page under test.

So already you might be able to imagine there’s a lot more that can be done with this instrumentation. I had some light-hearted fun getting confess.js (with a verbose flag) to emit waterfall charts of a page and its resources, for example – all in technicolor ASCII-art:

  1|-------                                                         |
  2|       ------------                                             |
  3|                 -----------                                    |
  4|                 ---------------------                          |
  5|                  -----------                                   |
  6|                  -------                                       |
  7|                  -------                                       |
  8|                  -------                                       |
  9|                  -------                                       |
 10|                                     ----------                 |
 11|                                     ----------------------     |
 12|                                     ----                       |
    ...

  1:   1679ms;       -b; http://cnn.com/
  2:   3115ms;       -b; http://www.cnn.com/
  3:   2716ms;       -b; http://z.cdn.turner.com/...css/hplib-min.css
  4:   5465ms;       -b; http://z.cdn.turner.com/...5/js/hplib-min.js
  5:   2952ms;       -b; http://z.cdn.turner.com/.../globallib-min.js
  6:   1681ms;      21b; http://content.dl-rms.co...r/5721/nodetag.js
  7:   1698ms;       -b; http://icompass.insightexpressai.com/97.js
  8:   1743ms;       -b; http://ad.insightexpress...px?publisherID=97
  9:   1706ms;       -b; http://js.revsci.net/gat...gw.js?csid=A09801
 10:   2494ms;    7732b; http://i.cdn.turner.com/...ader/hdr-main.gif
 11:   5694ms;   44091b; http://i2.cdn.turner.com...quare-t1-main.jpg
 12:   1023ms;     858b; http://i.cdn.turner.com/...earch_hp_text.gif
    ...

While this might seem a poor alternative to the rich diagnostics that can be gained from, say, the WebKit Web Inspector tools, it does provide a nice way to get a quick overview of the performance profile – and potential bottlenecks – of a page. And, of course, and more importantly, it can be easily extended, run from the command-line, automated and integrated as you wish.

App cache manifest

Similarly, we can also use a headless browser to analyze the application’s actual content in order to perform a useful task. Although there’s a run-time ‘chinese wall’ in PhantomJS between the JavaScript of the harness and the JavaScript of the page, it’s permable enough to allow us to evaluate script functions against the DOM and have simple results structures returned to confess.js.

Why might we want to analyze a page’s DOM in an automated way? Well, take the app cache manifest mechanism, for example: it provides a way to mandate to a browser which resources should be explicitly cached for a given application, but, despite a deceptively simple syntax, it can be frustrating to keep track of all the assets you’ve used. To maximize the benefits of using app cache, you want to ensure that every resource is considered: whether it’s an image, a script, a stylesheet – or even resources further referred to from inside those.

This is the perfect job for a headless browser: once a document is loaded, we can examine it to identify the resources it actually uses. Doing this against the real DOM in a real browser makes it far more likely to identify dependencies required by the app at run-time than would be possible through statically analyzing web markup.

And again, something like this could easily become part of an automated build and deploy process. For example:

$> phantomjs confess.js http://calendar.perfplanet.com/2011/ appcache

…will result in the following manifest being generated:

CACHE MANIFEST

# This manifest was created by confess.js, http://github.com/jamesgpearce/confess
#
# Time: Fri Dec 23 2011 13:46:42 GMT-0800 (PST)
# Retrieved URL: http://calendar.perfplanet.com/2011/
# User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X) AppleWebKit/534.34 (KHTML, like Gecko) PhantomJS/1.4.0 Safari/534.34

CACHE:
/photos/aaron-70tr.jpg
/photos/alex-70tr.jpg
/photos/alois-70tr.jpg
[...]

http://calendar.perfplanet.com/wp-content/themes/wpc/globe.png

http://calendar.perfplanet.com/wp-content/themes/wpc/style.css

NETWORK:
*

Depending on your app, there might be a lot of output here. But the key parts, as far as the eventual user’s browser will be concerned, are the CACHE and NETWORK blocks. The latter is always set to the * wildcard, but the former list of explicit resources is built up automatically from the URL you ran the tool against.

For app cache nirvana, you’d simply need to pipe this output to a file, link to it from the <html> element of your target document, and of course ensure that the file, when deployed, is generated with a content type of text/cache-manifest.

As an aside, the list of dependant resources itself is harvested by confess.js in four ways. Firstly, once the document is loaded in PhantomJS, the DOM is traversed, and URLs sought in src and href attributes on script, img, and link elements. Secondly, the CSSOM of the document’s stylesheets is traversed, and property values of the CSS_URI type are sought. Thirdly, the entire DOM is traversed, and the getComputedStyle method picks up any remaining resources. And finally, the tool can be configured to watch for additional network requests – just in case, say, some additional content request has been made by a script in the page that would not have been predicted by the contents of the DOM or CSSOM.

(Naturally, there are many useful ways to configure the manifest generation as whole. You can filter in or out URLs in order to, say, exclude certain file types or resources from remote domains. You can also wait for a certain period after the document loads before performing the extraction, in case you know that a deferred script might be adding in references to other resources. There’s information about all this in the docs.)

Onwards and upwards

We’ve just touched on the two simple examples of what can be done with a headless browser approach in general. The technique provides a powerful way to analyze web applications, and get closer to being able to understand real users’ experience and real apps’ behaviour.

I’d certainly urge you to check out PhantomJS, try scripting some simple activities, and think about how you can use it to understand and automate web site and application behaviour. (I’m not even sure I mentioned yet that it has a screen-shotting capability too…)

And of course, feel free to give confess.js a try too – with its humble goal of making it easier to help automate some of those common tasks. I’m always accepting pull requests!

But whatever your tools of choice… do have fun on your performance adventures, push the envelope, make the web a wonderful place – and I hope you all have an excellent 2012.

Antti contributes code to WebKit core and recently spent some time optimizing CSS selector matching. In fact, after finishing his work, he said:

“My view is that authors should not need to worry about optimizing selectors (and from what I see, they generally don’t), that should be the job of the engine.”

~ Antti Koivisto

Wow! That sounds fantastic to me. I’d love to be able to use selectors in a way that makes sense for my architecture and let the rendering engine handle selector optimization. So, what did he do? Not just one thing, rather he created multiple levels of optimization — we’ll take a look at four optimizations in particular:

1. Style Sharing
2. Rule Hashes
3. Ancestor Filters
4. Fast Path

Style Sharing

Style sharing allows the browser to figure out that one element in the style tree has the same styles as something it has already figured out. Why do the same calculation twice!

For example:

<div>
  <p>foo</p>
  <p>bar</p>
</div>

If the browser engine has already calculated the styles for the first paragraph, it doesn’t need to do so again for the second paragraph. A simple but clever change that saves the browser a lot of work.

Rule Hashes

By now, we all know that the browser matches styles from right to left, so the rightmost selector is really important. Rule hashes break a stylesheet into groups based on the rightmost selector. For example the following stylesheet would be broken into three groups:

a {}
div p {}
div p.legal {}
#sidebar a {}
#sidebar p {}

When the browser uses rule hashes it doesn’t have to look through every single selector in the entire stylesheet, but a much smaller group of selectors that actually have a chance of matching. Another simple but very clever change that eliminates unnecessary work for every single HTML element on the page!

Ancestor Filters

The ancestor filters are a bit more complex. They are Probability filters which calculate the likelihood that a selector will match. For that reason, the ancestor filter can quickly eliminate rules when the element in question doesn’t have required matching ancestors. In this case, it tests for descendant and child selectors and matches based on class, id, and tag. Descendant selectors in particular were previously considered to be quite slow because the rendering engine needed to loop through each ancestor node to test for a match. The bloom filter to the rescue.

A bloom filter is a data structure which lets you test if a particular selector is a member of a set. Sounds a lot like selector matching, right? The bloom filter tests whether a CSS rule is a member of the set of rules which match the element you are currently testing. The cool thing about the bloom filter is that false positives are possible, but false negatives are not. That means that if the bloom filter says a selector doesn’t match the current element, the browser can stop looking and move on the the next selector. A huge time saver! On the other hand, if the bloom filter says the current selector matches, the browser can continue with normal matching methods to be 100% certain it is a match. Larger stylesheets will have more false positives, so keeping your stylesheets reasonably lean is a good idea.

The ancestor filter makes matching descendant and child selectors very fast. It can also be used to scope otherwise slow selectors to a minimal subtree so the browser only rarely needs to handle less efficient selectors.

Fast Path

Fast path re-implements more general matching logic using a non-recursive, fully inlined loop. It is used to match selectors that have any combination of:

1. Descendant, child, and sub-selector combinators, and
2. tag, id, class, and attribute component selectors

Fast Path improved performance across such a large subset of combinators and selectors. In fact, they saw a 25% improvement overall with a 2X improvement for descendant and child selectors. As a plus, this has been implemented for querySelectorAll in addition to style matching.

If so many things have improved, what’s still slow?

What is still slow?

According to Antti, direct and indirect adjacent combinators can still be slow, however, ancestor filters and rule hashes can lower the impact as those selectors will only rarely be matched. He also says that there is still a lot of room for webkit to optimize pseudo classes and elements, but regardless they are much faster than trying to do the same thing with JavaScript and DOM manipulations. In fact, though there is still room for improvement, he says:

“Used in moderation pretty much everything will perform just fine from the style matching perspective.”

~ Antti

I like the sound of that. The take-away is that if we can keep stylesheet size sane, and be reasonable with our selectors, we don’t need to contort ourselves to match yesterdays browser landscape. Bravo Antti!

Want to learn more? Check out Paul Irish’s presentation on CSS performance.

Traditionally, older performance studies were concerned with speeding up things on the server side, but a few years back Steve Souders famously started research on the idea that the main performance bottleneck happened on the client side. In particular, in the way bytes were pushed to the client from the server. “Reduce HTTP requests” has become a general maxim for speeding up frontend performance, and that is a concern that’s even more relevant in today’s world of mobile browsers (often running on networks that are an order of magnitude slower than broadband connections).

These studies have been concerned with latency and bandwidth, and this still continues to be the focus of performance research today. You are probably already familiar with the standard HTTP waterfall chart:

However, we’re slowly starting to see a shift to other frontend concerns for each component of the frontend stack (HTML/CSS/JS). In particular, there’s been a great focus on JavaScript performance, a fact attested to by the popularity of jsPerf and the rise of JavaScript profilers.

After the page loads: the UI layer

This is all well and good, but we’re missing something: the presentation (UI) layer. Ok, that’s actually a bit of an exaggeration. UI performance tips have been disseminated throughout the community for years, but often as an aside, with bandwidth and latency concerns much more at the forefront. For instance, where CSS is even a concern, the focus is on reducing CSS filesizes. But what about expensive selectors? Or CSS that may cause the page to lag horribly?

One of the reasons UI performance has been downplayed is perhaps because of its inability to be quantified. As engineers, it’s a bit disconcerting to say that as a result of many hours of improvements, a website “feels” more responsive, or scrolls more smoothly. We would rather say “this site was originally rated at a 6/10 for responsiveness, but now it’s rated 8/10 for responsiveness!” But how on earth can we do gauge that? Well, now we can!

UI Profilers

Recently we’ve been given the tools to measure UI performance. A new CSS profiler is available in Opera’s developer tools, and one is on the way for WebKit browsers. Here’s the new face of performance profiling:

Here’s a few tools that should come in handy when testing UI performance:

CSS Stress Test

CSS Stress Test (by Andy Edinborough) is a bookmarklet that figures out which CSS declarations are slowing down the page by selectively removing each one, then timing the scroll speed performance. The result is a bookmarklet that’s a bit jarring to watch, but seems quite useful in tracking down rogue CSS bottlenecks. Note to self: apparently applying border-radius to a ton of elements isn’t a very good idea, performance-wise.

CSS Profilers

A CSS profiler is coming to a browser near you, which will give us much more insight into the actual speed of the CSS we write, moving us forward from vague and mysterious rules. Is the universal selector (*) really that expensive? Are border-radius, box shadow, and rgba values really performance drains? Now we have ways to measure those concerns!

CSS Lint

CSS Lint (by Nicole Sullivan and Nicholas Zakas) is a set of best practices (you may not agree with them all, but that’s ok), including a few helpful rules that target UI performance specifically. Run your stylesheets through and it’ll give you some helpful tips on what to improve.

DOM Monster

DOM Monster (by Amy Hoy and Thomas Fuchs) is intended as a JavaScript profiler companion, but remember that the complexity of the DOM (Document Object Model) will also affect UI repaints and reflows. Reducing that bloat is better for data down the wire, as well as UI rendering and JavaScript DOM access.

Perception of Speed

If you think about it, all of performance is concerned with how performance is perceived by the user. While we’re mostly concerned with real performance improvements, we have to recognize the limitations and realize that we don’t always have control over bandwidth, latency, or the speed of a user’s browser. Where we’ve already done our best elsewhere, here we sometimes have to fake it. Fake it ’till you make it!

What do I mean by faking it? This might mean preloading content where possible, which is what Gmail mobile does before the user clicks on the “Show more messages…” button. After the user clicks, the content has already been loaded – it only needs to change the UI to show the new content, and this happens extremely fast. It doesn’t really matter how long it took to make the original HTTP request, because either way the experience is the same for the user, and their perception is that the interface is extremely fast. This is an example of a great marriage of good user experience design with good engineering.

“Faking it” might also mean simply being responsive and quickly showing the user a visual indicator after they take an action. It doesn’t matter how well you optimize HTTP requests or how fast the connection is – if you don’t give an indication after the user performs an action, they will likely repeat their action (a click or another tap on the touchscreen) and come away with the impression that it’s a sluggish interface.

UI responsiveness also became a concern for Flickr when they switched to YUI3 – though they took advantage of combining HTTP requests, the initial unprimed cache page load meant that a user might start taking actions before the JavaScript was fully loaded, parsed, and executed. Because Flickr progressively enhances their webpages, this means that without JavaScript ready, the user gets taken to pages that were put in place for users with JavaScript disabled. Their solution was to load a mini-library in the page to capture all events on the page and queue them back to be replayed later. Most importantly, this small library also provides a UI (a loading spinner) to give the user feedback after taking actions, even if it means nothing had happened, short of the event being queued up to be replayed later when the JavaScript is ready. Fake it ’till you make it!

Tidbits

As I mentioned before, UI performance tips have been circulating for quite a while, but they have been somewhat downplayed compared to latency and bandwidth issues.

Here’s a collection of tidbits to give you an idea of some of the concerns that are out there:

• Sprites save HTTP requests, but large sprites hog up memory
• Pure CSS3 images? Hmm, maybe later (Marcel Duran) – pure CSS3 images are awesome but perhaps impractical, as they trade less bandwidth for decreased rendering speed (it turns out that images render faster)
• Microsoft’s FishIE Tank is a nice benchmark to test Canvas rendering speed, measured in frames per second. You may even find that tweaking the viewport tag on mobile devices may speed up rendering times
• CSS gradients are faster than SVG backgrounds
• Older WebKit browsers had scrolling/rendering lag with large box shadows – not all CSS3 stuff is ready for prime time, and sometimes images might be the way to go – better UI performance at the expense of more data down the wire
• CSS radial gradients may be awesome and save the request of an image, but they might have rendering problems in some browsers, particularly Android. We save bandwidth by not requesting an image, but the user experience suffers
• Avoid IE CSS filters, as they have a performance hit
• Use hardware-accelerated CSS animations over JavaScript animations where possible, but be aware of limitations (maximum sizes of 1024x1024px in WebKit). If you do end up needing to animate from JavaScript, try using requestAnimationFrame as opposed to setTimeout/setInterval

Call for a focus on UI performance

Performance is more than pushing bytes over a fence into a browser! Much of the user’s experience happens after a page loads, so we should still be concerned about the performance of a “loaded page” experience. This applies to our JavaScript, but equally as important is our CSS and its impact on scroll speed and overall UI responsiveness.

This might mean that we are sometimes better off using images instead of new CSS fanciness that’s not yet ready for primetime, and it’s up to us to weigh the cost and understand the tradeoff! It also helps us appreciate new CSS features or fancy demos while remaining skeptical of their practical use.

More than anything, if you struggled with a UI performance issue and overcame it, the world could learn from your experience! When you blog about it, you save other folks some time – time that could be spending with their families, which is definitely more important. We need more articles from folks like Marcel and Estelle, who understand that performance goes beyond saving bytes.

So get to it! But first, enjoy your time off. Happy holidays and merry Christmas!

The greatest feature of their approach was the fact that all performance data are consolidated into single container – HTTP Archive (HAR). It makes further processing of test results more controlled and predictable due to strict format standardization.

However, there were no advanced tools for dealing with HAR files at that moment. HAR Viewer is wonderful but is not suitable for common testing workflow. ShowSlow is instead a perfect example of repository for automated performance measurement. Unfortunately handling of HAR files is not the strongest trait of it. So new project HAR Storage appeared.

Concept

Testing process is rather straightforward. All you need is to create Selenium script which describes common user actions. Then you arm your script with methods to control proxy server via its API. It not only means capturing and storing stream of HTTP requests but also customization of network characteristics (e.g., bandwidth and latency) and traffic filtering. The last point is extremely important for analysis of impact of third-party components on overall site performance.

Finally you can send HAR of each page or asynchronous event to local repository – HAR Storage. Actually, HAR Storage is a simple web application built on Pylons and MongoDB. It allows extracting detailed metrics from HAR files, storing test results and visualizing all gathered data.

Advantages

The key advantage is high flexibility. With BrowserMob Proxy use can test website in any modern browser that supports custom proxy settings. You can even deal with mobile browsers.

Selenium in turn makes it possible to simulate any sophisticated user scenario. Therefore you can analyze both speed of single page and performance of complex business transactions.

HAR Storage has cool features too. For instance, you can compare results of different tests. This is a great help for analysis of third-party party content or for investigation of relationship between site speed and network quality.

At least with HAR Storage you can continuously track performance of your web site or application at any development phase.

Limitation

Nothing is perfect in this world. BrowserMob proxy runs outside the browser and on the one hand has minimal impact on its performance; on the other hand, internal browser events are inaccessible. Thus you can’t estimate performance of rendering or JavaScript parsing. Tools like dynaTrace AJAX Edition is more suitable for such tasks.

This approach may seem too complicated to some people. In fact it isn’t WebPagetest.org where you can simply put the URL and enjoy the result. But if you need real cross-browser testing, measurements over time and implementation of complex use cases – this method will work for you.

Conclusion

Web performance is still critical aspect, and performance testing is still a challenge. Frameworks based on Selenium, BrowserMob Proxy and HAR Storage may become an ultimate solution for many growing projects.

This works well for live deployed applications, but what about a staged setup? Engineers might want to look at the performance before deploying to production, perhaps while going through a QA process. They may want to find possible performance regressions or make sure a new feature is fast. The staged setup could reside on a corporate network however restricting the use of RUM tools mentioned earlier.

And what about an application hosted in a firewalled environment? Not all web applications are publicly hosted on the Internet. Some are installed in private data centers for internal use only (think about an intranet type of setup).

How can you watch application performance in these types of scenarios? In this blog post, I’ll explain how we leveraged open source software to build our performance test suite.

Recording data

The initial step is to record data. For that purpose we use a bit of custom code that records time spent on multiple layers: front end, web tier, backend web services and database.

Our web tier is a traditional server side MVC application that generates an HTML page for the browser (we use PHP and the Zend Framework, but this could apply to any other technology stack). First, we store the time at which the server side script started, right before we invoke the MVC framework:

<?php
// store script start time in microseconds
define('START_TIME', microtime(TRUE));
?>

Secondly when the MVC framework is ready to buffer the page back to the browser, we insert some inline javascript code which includes:

• the captured start time (“request time”)
• the current time (“response time”)
• the total time spent doing backend calls (How do we know this information? Our web service client keeps track of the time spent doing webservice calls; and with each webservice response, the backend include the time spent doing database calls).

In addition to those metrics, we include some jquery code to capture:

• the document ready event time
• the window onload event time
• the time of the last click (which we store in a cookie for the next page load)

In other words, in in our HTML document (somewhere towards the end) we have a few lines of javascript that look like this:

<script>
Perf = Perf || {};
Perf.requestTime = <?= START_TIME ?>;
Perf.responseTime = <?= microtime(TRUE) ?>;
Perf.wsTime = <?= $wsTime ?>;
Perf.dbTime = <?= $soapTime ?>;
$(document).ready(function(){
  Perf.readyTime = new Date().getTime()/1000;
});
$(window).bind("load", function(){
  Perf.renderTime = new Date().getTime()/1000;
  Perf.clickTime = getLastClickTime();
});
$(window).bind("unload", function(){
  storeLastClickTime(new Date().getTime()/1000);
});
</script>

Finally we insert a couple more javascript lines in the head tag, so that we can record an approximate time at which the page was received by the browser. As Alois Reitbauer pointed out in Timing the Web, this is an approximation as it does not account for things like DNS lookups.

<head>
<script>
Perf = Perf || {};
Perf.receivedTime = new Date().getTime()/1000;
</script>
[...] more code [...]
</head>

Now that we have some metrics for a given request in the browser, how do we retrieve them so that we can examine them?

Collecting and analyzing the data

This is where Selenium comes into play. We use Selenium to simulate a person using our web application. Again this is technology agnostic as you can control Selenium from various languages (we use PHP and PHPUnit, but you could do the same with python or ruby).

Selenium has an API which you can call to invoke some javascript snippet and get back the output of the executed code. This API is called getEval.

Within our test code, we first open a page we want to analyze, then use the getEval API to retrieve the metrics we recorded and finish with storing the metrics for later consumption.

class ExampleSeleniumTest extends PHPUnit_Extensions_SeleniumTestCase
{
  public function testLoadSomePage()
  {
    // Open our web application
    $this->open('/');
    // Click a link to load the page we want to analyze
    $this->clickAndWait('Some Page')
    // Use getEval API to retrieve the metrics we recorded
    $metrics = $this->getEval('window.Perf');
    // Call our internal method that will store the metrics for later use
    // Note: we include a reference to the page or to what use case we are testing
    $this->saveMetrics('some-page', $metrics);
  }
}

We use this pattern for multiple use cases in our application. Also note that while I used the example of a full page load, our framework also supports collecting metrics for AJAX interactions, which we do quite a lot (for instance remotely loading content triggered by a user click).

One of the great things about using Selenium is multiple browser support. We have a set of virtual machines running various versions of Internet Explorer and Firefox. This enables our performance test suite to run across multiple platforms.

The last piece of the puzzle is analyzing the data we collected. For this purpose we built a small database driven application which reads the metrics we collected and plot them. We can apply filters such as specific browser vendor or version, specific use case, specific version of our software, etc. We can then look at the complete data over time.

Here is the logic we use to plot the data we collected:

Sample results

This is an example of chart generated after collecting data:

In the above sample, we can observe a client side performance issue in Sample 1, some inefficient code in the backend web services in Sample 2 and a slow database query in Sample 3.

Benefits

When we built this framework in 2009 we had multiple goals in mind:

• Monitor performance between our software release and catch eventual regressions
• Monitor performance of upcoming features
• Monitor the scalability of the software as we add more users/more data

Looking back, this tool yielded some great results and here are a few examples:

• Discovery of bugs in our javascript code that would result in much higher load times in IE
• Found issues in the way we were manipulating HTML with javascript and were able to improve the responsiveness of the impacted user interactions
• Eliminated bottlenecks in our backend web services as we raised the amount of data: we were able to pin point exactly where the problem was (inefficient backend code, slow database queries, etc.)

Closing words

In conclusion, I’d like to look into some ideas we have in mind to improve our setup.

I’d like to use the tool more often. We currently run the test suite several times during our development process and before each releases, but this is a manual process. It would be great to tie in the test suite with our Jenkins CI builds. A different idea would be to ship the tool as part of our product and run it in production providing us with some analytics on real world usage of our platform.

As I mentioned, we are using virtual machines to test on multiple platforms. This adds a bit of overhead in terms of maintenance. Maybe we should look at the hosted Selenium solution from Sauce labs?

When we built the product, the performance landscape was a bit different and there are tools today that were not available back then. Would we see any benefits if we were to leverage Webpagetest, boomerang, etc.?

Credits

I’d like to acknowledge Bill Scott for his presentation on RUM at Netflix which inspired us to build our framework.

That if you don’t count lots of creative talent that went into creating them, so much in fact that it created the web as we know now, reach, shiny and full of marketing potential! Without images we wouldn’t have the job of building the web, and without images we wouldn’t worry about web performance because there would be no users to care about experience and no business people to pay for improvements.

That being said, images on our websites are the largest payload sent back and forth across the wires of the net taking big part in slowing down user experience.

According to HTTPArchive, JPEGs, GIFs and PNGs account for 63% of overall page size

and overall image size has 0.64 correlation with overall page load time.

Still we can safely assume that we are going to have only more images and they will only grow bigger, along with the screen resolutions on desktop computers.

Lossy compression

There are a few different ways to optimize images including compression, spriting, picking appropriate format, resizing and so on. There are many other aspects of handling images that include postloading, caching, URL versioning, CDNs and etc.

In this article I wanted to concentrate on lossy compression where quality characteristics of the images are changed without significant visual differences for the user, but with significant changes to performance.

By now most of us are familiar with loss-less compression, thanks to Stoyan and Nicole who first introduced us to image optimization for web performance with an awesome on-line tool called Smush.it (now ran by Yahoo). There are a few other tools now that have similar functionality for PNG, for example.

With smush.it and alike image quality is preserved as is with only unnecessary meta-data removed, it often saves up to 30-40% of file size. It is a safe choice and images will be intact when you do that. This seems the only way to go, especially for your design department who believe that once image comes out of their computers it is sacred and must be preserved absolutely the same.

In reality, quality of the image is not set in stone – JPEG was invented as a format that allowed for size reduction at a price of quality. Web got popular because of images, it wouldn’t be here if they were in BMP, TIFF or PCX formats that were dominating prior to JPEG.

This is why we need to actually start using this feature of JPEG where quality is adjustable. You probably even saw it in settings if you used export functionality of photo editors – here’s the screenshot of quality adjusting section of “export for web and devices” screen in Adobe Photoshop.

Quality setting ranges from 1 to 100 with 75 usually being enough for all of the photos with some of them looking good enough even with the value of 30. In Photoshop and other tools you can usually see the differences using your own eyes and adjust appropriately making sure quality never degrades below certain point that mainly depends on the image.

Resulting image size heavily depends on the original source of the image and visual features of the picture sometimes saving up to 80% of the size without significant degradation.

I know these numbers sound pretty vague, but that is exactly the problem that all of us faced when we needed to automate image optimization. All images are different and without having a person looking at them, it’s impossible to predict if fixed quality setting will be damaging the images or not saving enough. Unfortunately having a human editor in the middle of the process is costly, time consuming and sometimes simply impossible, for example when UGC (user-generated content) is used on the site.

I was bothered by this problem since I saw smush.it doing great job for lossless compression. Luckily, this year two tools emerged that allow for automation of lossy image compression: one open source tool was developed specifically for WPO purposes by my former co-worker, Ryan Flynn and called ImgMin and another is a commercial tool called JPEGmini which came out of consumer photo size reduction.

I can’t talk for JPEGmini, their technology is private with patents pending, but ImgMin uses a simple approach of trying different quality settings and then picking the result that has the picture difference within a certain threshold. There are a few other simple heuristics, for more details you can read ImgMin’s documentation on Github.

Both of the tools work pretty well providing different results with ImgMin in it’s simplicity being less precise. JPEGmini offers dedicated server solution with cloud service coming soon.

In this table you can see my twitter userpic and how it was automatically optimized using loss-less (smush.it) and loss-y (JPEGmini) compression:

Original: 10028 bytes	Lossless: 9834 bytes 2% savings	Lossy: 4238 bytes 58% savings

Notice no perceivable quality degradation between original and optimized images. Results are astonishingly similar on larger photos as well.

This is great news as it will finally allow us to automate lossy compression which was always a manual process – now you can rely on a tool and reliably build it into your image processing pipeline!

• System 1, which is fast and intuitive, and
• System 2, which is slow and logical.

Almost invariably, System 1 is flawed, yet we helplessly rely on it. We also have a painful tendency to think we’re applying System 2 to our thinking, when in fact it’s just an intellectually tarted up version of System 1.

Kahneman offers a nifty little test of this thinking:

“A certain town is served by two hospitals. In the larger hospital about 45 babies are born each day, and in the smaller hospital about 15 babies are born each day. As you know, about 50% of all babies are boys. However the exact percentage varies from day to day. Sometimes it may be higher than 50%, sometimes lower. For a period of 1 year, each hospital recorded the days on which more than 60% of the babies born were boys. Which hospital do you think recorded more such days?”

1. The larger hospital
2. The smaller hospital
3. About the same (that is, within 5% of each other)

The correct answer is B, the smaller hospital. But as Kahneman notes, “When this question was posed to a number of undergraduate students, 22% said A; 22% said B; and 56% said C. Sampling theory entails that the expected number of days on which more than 60% of the babies are boys is much greater in the small hospital than in the large hospital, because the large sample is less likely to stray from 50%. This fundamental notion of statistics is evidently not part of people’s repertoire of intuition.”

But these are just a bunch of cheese-eating undergrads, right? This doesn’t apply to our community, because we’re all great intuitive statisticians? What was the point of that computer science degree if it didn’t allow you a powerful and immediate grasp of stats?

Thinking about Kahneman’s findings, I decided to conduct a little test of my own, to see how well your average friendly neighbourhood web performance expert is able to analyze statistics. (Identities have been hidden to protect the innocent.) *

The methodology

I asked 10 very senior and well-respected members of our community to answer the hospital question, above. I also asked them to comment on the results of this little test:

The following RUM results capture one day of activity on a specific product page for a large e-commerce site for IE9 and Chrome 16. What conclusions would you draw from this table?

The results

If you had to summarize this table, you would probably conclude “Chrome is faster than IE9.” That’s the story you take away from looking at the table, and you intuitively are drawn to it because that’s the part that’s interesting to you. The fact the study was done using a specific product page, captures one day of data, or contains 45 timing samples for Chrome is good background information, but isn’t relevant to the overall story. Your summary would be the same regardless of the size of the sample, though an absurd sample size (i.e. results captures from 2 data points or 6 million data points) would probably grab your attention.

Hospital question results:
On the hospital question, we were better than the undergrads… but not by much. 5 out of 10 people I surveyed got the question wrong.

RUM results:
I was amazed at the lack of focus on the source of the data. Only 2 people pointed out that the sample size was so low that no meaningful conclusions could be drawn from the results, and that averages were useless for this type of analysis. The other 8 all focused on the (assumed) fact that Chrome is faster than IE9, and they told me stories about the improvements in Chrome and how the results are representative of these improvements.

Conclusions

The table and description contain information of two kinds: the story and the source of the story. Our natural tendency is to focus on the story rather than on the reliability of the source, and ultimately we trust our inner statistical gut feel. I am continually amazed at our general failure to appreciate the role of sample size. As a species, we are terrible intuitive statisticians. We are not adequately sensitive to sample size or how we should look at measurement.

Why does this matter?

RUM is being adopted in the enterprise at an unprecedented speed. It is becoming our measurement baseline and the ultimate source of truth. For those of us who care about making sites faster in the real world, this is an incredible victory in a long protracted battle against traditional synthetic tests.

I now routinely go into enterprises that use RUM. Although I take great satisfaction in winning the war, an important battle now confronts us.

Takeaways

1. We need tools that warn us when our sample sizes are too small.
We all learned sampling techniques in high school or university. The risk of error can be calculated for any given sample size by a fairly simple procedure. Don’t use your judgement because it is flawed. Not only do we need to be vigilant but we need to lobby for the tool vendors to help us. Google, Gomez, Keynote and others should notify us when sample sizes are too small – especially given how prone we are to error.

2. Averages are a bad measure for RUM results.
RUM results can suffer from significant outliers, which make averages a bad measure in most instances. Unfortunately, averages are used in almost all of the off-the-shelf products I know. If you need to look at one number, look at medians or 95th percentile numbers.

3. Histograms are the best way to graph data.
With histograms you can see the distribution of performance measurements and, unlike averages, you can spot outliers that would otherwise skew your results. For example, I took a dataset of 500,000 page load time measurements for the same page. If I went with the average load time across all those samples, I’d get a page load time of ~6600msec. Now look at the histogram for all the measurements for the page, below. Visualizing the measurements in a histogram like this is much much more insightful and tells us a lot more about the performance profile of that page.

(If you’re wondering, the median page load time across the data set is ~5350msec. This is probably a more accurate indicator of the page performance and much better than the average, but is not as telling as the histogram that lets us properly visualize the performance profile. As a matter of fact, here at Strangeloop, we usually look at both median and the performance histogram to get the full picture.)

* Of course, you’re allowed to call into question the validity of my test, given its small sample size. I’d be disappointed if you didn’t.

We all know that 3rd party content means you no longer control all the factors which affect page load time. A sleek, well-tuned, and optimized site can still deliver a poor user experience because of problems with 3rd party content. Steve Souders even used to publish a series of blog posts where he analyzed and rated the performance of 3rd party content snippets. (Dear Steve, please bring this back, it was awesome). Mathias Bynens took this one step further, showing how to additionally optimize Google’s markup and JavaScript snippets.

The surprising lesson to learn from Steve and Mathias is that if you want a fast site and 3rd party widgets, then you need to examine the 3rd party content for performance problems, even when a snippet comes from a trusted authority on web performance. So this post isn’t really going to be about 3rd party content. It’s going to be about trusting advice.

Last week a Zoompf customer, the online precious metal exchange GoldMoney, contacted Support about an issue our technology flagged on their site. We had detected an issue with Google’s JavaScript library for their Google+ button. Zoompf WPO was suggesting the customer do something which was contradicting Google’s advice. And that was enough to give GoldMoney pause.

The specific issue that Zoompf was flagging was that Google’s plusone.js library was being referenced using SSL from a non-SSL page. SSL is important because, if used properly, it provides communications privacy and integrity. However, a CSS file, or JavaScript library, or even a Favicon that is referenced using a SSL-enabled hyperlink from an HTML page which is not served over SSL most likely does not contain information that needs protecting. Since SSL provides these security features with a cost of a decrease in web performance (as discussed below), it is important to only use SSL when you have to.

In this case, the Google plusone.js button library does not contain personal or private information. Zoompf’s suggestion was to instead retrieve the Google+ library using http:// instead of https://. Here is what Google’s documentation has to say (emphasis added):

The +1 button code requires a script from Google’s servers. You may get this error by including the script via http:// on a page that’s loaded via https://. We recommend using https:// to include the script:
<script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>
If your web page uses https://, some browsers and verification tools will show an error when any assets on the page are called via http://. If your site serves pages via https://, make sure that the +1 button code on those pages also uses https://. (In fact, it’s fine to use https:// in the button code for all pages, even if they are only served via http://.)

The “error” that Google is trying to avoid is a mixed content warning. It looks like this:

A mixed content warning happens when an HTML page served with HTTPS references resources using HTTP. Due to some serious design flaws in modern browsers, mixed content can allow privileged information like the DOM, cookies, referrer URLs, session IDs, and more to be access by untrusted parties. Browsers usually display a confusing dialog box or just fail to render the page, depending on its security settings. Google’s solution to avoid all is to just always request the plusjone.js file using SSL, even when SSL is not needed.

But using SSL, just for the fun of it, is not a good idea. SSL impacts web performance negatively in several ways:

• HTTPS connections take longer to create than regular HTTP connections. Additional requests may need to be sent to different servers to validate the X.509 certificate chain before the SSL connection can begin, causing all pending HTTPS connections to that server to block.
• Establishing an HTTPS connection is computationally expensive. The browser and server must do a large amount of work during the SSL handshake and more work encrypting and decrypting data as it is sent. While computers are always getting faster SSL overhead is still sufficiently large that an entire market for SSL acceleration products exists.
• Because HTTPS runs on a separate TCP/IP port than HTTP, your browser cannot use an existing HTTP connection as an HTTPS connection, even if you are talking to the same hostname.
• Using SSL means inline devices like shared caching servers will not see the traffic and cannot be used to improve performance.
• Browser caching of content served over SSL is more complicated than content over HTTP. Depending on the browser and configuration, content may only be cached in RAM and discarded quickly, or require conditional requests not usually needed.

In short, SSL is great but it’s not free. Don’t use it if you don’t have to.

The solution here is to actually use a protocol relative URL. A protocol relative URL is a way of referencing a resource on a different host name without specifying what protocol to use to retrieve. So instead of src="https://apis.google.com/js/plusone.js" you can use src="//apis.google.com/js/plusone.js". Consider an HTML page which uses a protocol relative URL to reference plusone.js. If the page was served using https://, then plusone.js is requested using https://. Security is maintained and no mixed content security warning will appear. If the page was served using http://, then the library will be served using HTTP. No performance hit happens and no caching issues come up either.

Now, I know what you might be thinking. “Did Stoyan seriously allow some guy a spot on the Performance Calendar to talk about protocol relative URLs for eleven paragraphs?” Well yes, I did talk about something cool that many people are not familiar with and which provides an elegant solution to a surprising common problem. (If fact there tons of other stuff to talk about with protocol relative URLs, like a non-standard IE6 configuration which causes a weird certificate error, or the double downloading bug in IE7 and IE8. So count yourself lucky!) But as I said earlier, the magic of protocol relative URLs is not the point of this post.

The point of post is that you need to be careful about performance advice. Not just where you get it, but what it says to do. Google is awesome. They are one of the strongest supporters of web performance in the industry today. But no one is perfect. Mathias improved upon their Google Analytics snippet. Their Google Doodles are always ludicrously high quality JPEGs that needlessly waste bandwidth. And sometimes, like in this case, their advice is not just right. As the Buddha once said:

Believe nothing, no matter where you read it, or who has said it, not even if I have said it, unless it agrees with your own reason and your own common sense.

You should always examine a code snippet from a 3rd party before including it in your site, regardless of who wrote it, even if Steve Souders or Douglas Crockford or John Resig wrote it, to make sure it does not violate any best practices that you already know.