best practices

Browser innovation and the 14 rules for faster loading websites: Revisiting Steve’s work (part 2)

13 Sep 2012

4 Comments

A few months back, I posted part 1 of a 3-part post to answer the question:

“Aren’t many of the web performance rules described by Steve Souders in 2007 already outdated or made obsolete by browser innovation?”

Despite the fact that my company was founded on the premise that Steve’s rules are our bible, I still place a great deal of value on testing core assumptions. Fortunately, testing the first five rules revealed that these performance rules have stood the test of time and are as valid today as they ever were.

Today (finally), I want to look at the next five rules:

Methodology

1. As with my previous post, I used these test cases of the performance rules that Steve created five years ago, and which are still available. Using the Wayback Machine, I timestamped them to October 2007.

Steve Souders: 14 rules for high performing web sites2. Next, I ran each test case on Internet Explorer 6 on WebPagetest to get a sense of what Steve would have seen for performance rules 6 through 10. I did three runs of each test and used the median result.

3. Then I ran each test case on Chrome 19 to see what impact, if any, the rules have on a modern browser. Again, I performed three runs of each test and recorded the median result.

4. Using the above approach, I was able to see and compare the before-and-after results for each rule for both browsers, and then calculate the benefit. You can see the detailed test results, along with links to the tests, in this spreadsheet.

Important: The goal here is not to look at how fast Chrome 19 is versus Internet Explorer 6. We have looked at this in the past. This time I want to look at the relative benefit of each performance rule.

Findings

Here’s a high-level look at the results:

Rule 6: Move scripts to the bottom of the page

What this rule means: It’s better to move scripts from the top to as low in the page as possible. One reason is to enable progressive rendering, but another is to achieve greater download parallelization.

With scripts, progressive rendering is blocked for all content below the script. Moving scripts as low in the page as possible means there’s more content above the script that is rendered sooner. The second problem caused by scripts is blocking parallel downloads. While a script is downloading, the browser won’t start any other downloads, even on different hostnames. [From High Performance Web Sites]

Testing the rule: Steve experimented with placing scripts in various places on a page in order to see their performance impact. Using the methodology above, I was able to see the performance benefit (defined by the improvement in document complete time) of applying two of these techniques to IE6 and Chrome 19:

Rule
 Benefit in IE6 Benefit in Chrome 19
Scripts at the bottom 0.13% 18%
Deferred scripts
 31% 18%

Rule 7: Avoid CSS expressions

What this rule means: CSS expressions are an older technique, supported in Internet Explorer up until the release of IE8, which let you set CSS properties dynamically. The problem with CSS expressions was that they were evaluated more often than most people realized. As Steve pointed out in 2007, moving the mouse around the page can easily generate more than 10,000 evaluations.

This technique has fallen out of practice, largely because of findings like Steve’s. Nobody with any common sense is using this technique anymore, so it’s not relevant.

There may, however, be a modern version of this same issue. I’ve heard reports abut similar issues with JavaScript performance due to easy-to-use JS libraries such as JQuery. Similar to CSS expressions, it’s very easy to hook up functions to JavaScript events like moving the mouse and scrolling, causing similar tens of thousands of calculations to happen. I’m not sure how often this is actually happening out in the real world, but it’s something to be aware of.

Testing the rule: N/A

Rule 8: Make JavaScript and CSS external

What this rule means: If users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, you could potentially benefit from cached external files.

Pages that have few (perhaps only one) page view per session may find that inlining JavaScript and CSS results in faster end-user response times.

For front pages that are typically the first of many page views, there are techniques that leverage the reduction of HTTP requests that inlining provides, as well as the caching benefits achieved through using external files. One such technique is to inline JavaScript and CSS in the front page, but dynamically download the external files after the page has finished loading. Subsequent pages would reference the external files that should already be in the browser’s cache. [From High Performance Web Sites]

Testing the rule: Below are the performance gains (defined as the improvement in document complete time in the repeat view) for both browsers:

Rule
 Benefit in IE6 Benefit in Chrome 19
Cacheable external JS and CSS 37% 40%
Post-onload download 42% 45%
Dynamic inlining 38% 44%

Rule 9: Reduce DNS lookups

What this rule means: There’s no test case for this rule — because it’s a given that fewer DNS connections is a good thing — but I still want to review it here in order to talk about why it’s a good thing.

DNS lookup is when the browser looks up the domain of the object being requested by the browser. Think of this as asking the “phone book” of the internet to find someone’s phone number using their first and last name. DNS lookups are cached for better performance — on caching servers maintained by your ISP or LAN, on your operating system’s DNS cache, and in your browser cache.

Steve offers this advice: Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the page. Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times. My guideline is to split these components across at least two but no more than four hostnames. This results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.

It’s important to know that some newer browsers (at least Chrome does) do DNS prefetching as well.

Testing the rule: N/A

Rule 10: Minify JavaScript

What this rule means: Minification is the practice of removing unnecessary characters — such as comments and white space — from code. This improves JavaScript response time because the size of the downloaded file is reduced. Minification is fairly straightforward, unlike its sister practice: obfuscation.

Like minification, obfuscation removes comments and white space, but it also munges the code — converting function and variable names into smaller strings, thereby making the code more compact as well as harder to read. While munging wasn’t originally conceived of as a performance practice, it was found that it can help performance because it reduces the code size beyond what is achieved by minification. (Warning: Obfuscation can lead to bugs, unlike minification, which is relatively problem free.)

In addition to minifying external scripts, you can also minify inlined script blocks. Even if you’re already gzipping your scripts, minifying them will still reduce the size by at least 5%.

Testing the rule: Below are the performance gains for both minification and obfuscation of different-sized files:

Rule
 Benefit in IE6 Benefit in Chrome 19
Small script minified 14% 16%
Small script obfuscated 14% 15%
Large script minified 22% 21%
Large script obfuscated 23% 21%

Conclusion

Once again, it’s reassuring to see how many of the performance rules have stood the test of time. I was really struck by how similar the results were for many of the test cases. I had expected that the rules would still be relevant, but to be perfectly honest, I had also expected that browser evolution would have resulted in more disparity between the results.

It was also interesting to see how a rule — avoid CSS expressions — has become so entrenched over time that it’s no longer an issue.

This has been a really interesting exercise so far. I’m looking forward to part 3.

Related posts:

By: Tammy Everts Category: Tags: , , , , ,

15 things you can (and should) do to make your site faster for mobile users

29 Aug 2012

9 Comments

August is Speed Awareness Month, and performance experts throughout our community are contributing their perspectives. My post about must-have mobile optimization techniques just went live. Here’s the intro…

As you probably know, mobile users face unique performance challenges:

  • Slower networks (which is why reducing requests and payload is important)
  • Mobile browsers are slower to parse HTML and slower to execute JavaScript (so optimizing client-side processing is crucial)
  • Mobile browser caches are much smaller than those of desktop browsers (requiring new approaches to leveraging local storage of reusable resources)

There are a number of fundamental and advanced tactics that you can use to take on these challenges and win. I’m going to give an overview of each one here, but to get more insight and specific how-to details, I urge you to download Strangeloop’s whitepaper on mobile website optimization.

1. Consolidate resources

By now, this is a standard practice, so I’m not going to explain it here, but I want to point out that resource consolidation can be a double-edged sword for mobile browsers. Reducing requests speeds up page load the first time, but larger consolidated resources may not be cached efficiently. So if you’re using this technique, make sure to balance it with techniques to optimize local storage (coming up next).

2. Use browser caching and localStorage

Caching is an essential technique for achieving acceptable performance, but desktop and mobile caches are not created equal. Mobile browser caches are usually much smaller than on desktop machines, causing items to be flushed quickly, so traditional browser caching doesn’t work well for mobile devices. Luckily, the HTML5 Web Storage specification, which has been implemented in all major desktop and mobile browsers, provides a great alternative to relying solely on browser caching.

3. Embed resources in HTML for first-time use

If a resource doesn’t have a high likelihood of already being cached (such as in a mobile context), it is often best to embed that resource in the page’s HTML — a technique called “inlining” — rather than storing it externally and linking to it.

The disadvantage of inlining is that page size can become very large, so it’s crucial for a web application that uses this strategy to be able to track when the resource is needed and when it is already cached on the client. In addition, the application must generate code to store the resource on the client after sending it inline the first time. For this reason, using HTML5 localStorage on mobile devices (as described above) is a great companion to inlining.

4. Use HTML5 server-sent events

The HTML5 EventSource object and Server-Sent events enable JavaScript code in the browser to open a much more efficient channel from the server to the browser, which the server can then use to send data as it becomes available, eliminating the HTTP overhead of creating multiple polling requests.

5. Eliminate redirects

When users try to navigate to a standard desktop site from a mobile device, this often generates an extra round trip to the client and back to the mobile site, consuming several hundred milliseconds over mobile networks. For obvious reasons, it’s faster to deliver the mobile web page directly in response to the original request, rather than delivering a redirect message that then requests the mobile page. And as a courtesy to users who prefer to view the desktop site on their mobile device, you can provide a link on the mobile site that signals your application to suppress this behavior.

…

Those are the first five tips. You’ll have to go to the original post to read the other ten. :)

Related posts:

By: Tammy Everts Category: Tags: , ,

Automated front-end performance: How do you calculate developer ROI?

22 Aug 2012

4 Comments

Last week, we were preparing for a meeting with a customer and, during the process, our sales team asked me this question:

Customer X just asked if we had any analysis of cost savings for the amount of manpower they would save with Site Optimizer. I haven’t seen anything like this, but I thought I’d ask. A blog post, case study, or anything along the lines of cost savings would be great.

The question of ROI from automating front-end performance from a developer perspective is something I haven’t written about. Part of the reason it’s taken so long to get to this topic is because I feel like the answer is obvious, but at the same time I dread doing calculations that might cost someone their job. (More on that later.)

But when I reflect on it, the answer is really only obvious to those of us who care about performance and have tried optimizing by hand. If you’ve never done this, you’d never suspect the pain that lurks behind the performance doors.

In lieu of simply believing that many of the performance best practices should be automated just because industry gurus say they should, let’s get specific on the cost savings.

Background: Who cares about developer ROI?

Understanding this problem starts with some basic assumptions about the type of client interested in developer ROI:

  1. Customers interested in ROI generally write code, they have coders on staff, they have code repositories, and they understand concepts like version control. If you rent/host a blog for $1.99 per month, you will not find an ROI on the developer side.
  2. Customers interested in ROI have some significant (at least for them) revenue that is either directly related to the site (think ecommerce) or indirectly related (think big brands like Johnson & Johnson). Alternatively, they might have productivity-related goals for internal applications. In all cases, the CEO knows the site(s) exist(s) and knows that his/her job could be on the line if it/they don’t work.
  3. Customers interested in ROI change their site(s) often. This is key because, as I’ll demonstrate in a minute, a significant amount of the cost on the dev side is due to website changes over time.
  4. Customers interested in ROI often have a very strong marketing/content organization that dictates functionality to build and functionality to incorporate (think third-party content). The costs would be way less if the developers were able to make the site look and act like Craigslist.

Quick case study: Sears.com

A good example of this type of customer is Sears.com. Their site matters, it’s dynamic, and they care about performance.

Trying to frame this problem is hard because you can look at it from many different perspectives. A good way to start is to look at a couple of key front-end performance rules as described by Steve Souders in the context of different perspectives. I’ll cherry pick a few to provide a picture of the complexity the problems and the ROI benefits.

Key rule #1: Make fewer HTTP requests

Perspective 1: One page, one browser

As I’ve already mentioned, the costs associated with performance tuning are significantly reduced if the site never changes… but good luck with employing that strategy in modern ecommerce warfare.

To observe how much sites change over time, I dug into the HTTP Archive and pulled tests over the last year from Sears.com.

Let’s take a look at this data from two perspectives:

Visual: Looking at the video below, you can see how much the site has changed from a visual perspective over a year.

Behind the scenes: The amount of change you see above is very common. The amount of change is equally dramatic when you peel off the good-looking exterior and look behind the scenes. This site is constantly changing. Every week — possibly every day — the content changes, the number of requests change, and the number of domains change.

Sears.com home page changes: ImagesSears.com home page changes: JavaScriptSears.com home page changes: CSSSears.com home page changes: DomainsAs you can see from these tables, the basic composition of this page changes dramatically over the year.

Why is this expensive to hand code?

One of the key ways we can make sites faster is to minimize server roundtrips. Many of the techniques to minimize roundtrips involve combining objects together into packages. If the content is always changing, then these packages also have to change. Keeping packages updated can be very time consuming and arduous. And as anyone who’s actually done this can tell you, this work is also fraught with the potential to make mistakes when done by hand.

The key ROI from automation for dynamic sites is the ability to offload all of the packaging time and effort onto a computer. Not only does this save a significant amount of time, but it also reduces error.

How to calculate cost savings

A few caveats on ROI calculation: Calculating cost savings is best done on a case-by-case basis. All of the numbers I cite in this post are from my experience working with customers that do this stuff by hand. Your mileage may vary. However, here are a few guidelines from my experience:

In one large organization that performs FEO by hand, I have seen three full-time developers in the resource management side of the house. These people not only deal with packaging but also with caching and versioning.

Formula: By implementing automated FEO for resource reduction in this context, I would calculate 5 person-days of dev/QA time saved for every major content change on the site.

Perspective 2: One page, many browsers

Changing packages as content changes is hard and costly to do by hand. Changing packages to take into consideration the performance nuances within each browser is a nightmare to do by hand.

Why is this expensive to hand code?

Browsers don’t all support the same standards. As we’ve observed in the past, browsers can also change at a moment’s notice with disastrous effects if you are not careful. If you’re going to hand code by browser, not only does your matrix of supported scenarios exponentially increase, but your QA surface also exponentially increases. You also need to stay on top of all new browser developments and patches.

For a modern website with a standard user profile, you would need to do separate packages for at least five browser groups.

How to calculate cost savings

In any large organization that performs FEO by hand (think Google, Facebook, etc.) they have a team of browser experts.

Formula: Depending on the size of your organization I would factor in at least one browser expert and a 1.5x increase in front-end development time and a 2x increase in QA time if you’re going to undertake a per-browser optimization path.

Perspective 3: One page, many desktops + mobile

You probably already get the point, but it’s critical to break out mobile. Mobile makes front-end optimization way more difficult. Resource reduction is done totally differently in the context of mobile, so you need a totally different skill set to conduct mobile FEO.

Why is this expensive to hand code?

Standards are changing quickly. Browsers are changing quickly. Handsets have very different capabilities. Testing is a big pain in the butt.

How to calculate cost savings

Most of the organizations we know that perform front-end optimization by hand have a totally dedicated mobile team (on the dev and QA side).

Formula: I would calculate at least at 2:1 ratio of front-end desktop to mobile team members and a 2x increase in workload if they are going to perform these tasks by hand. You also need to factor in the costs of all the different devices and related plans.

Perspective 4: Many pages, many browsers

As I have written about before, resource reduction is hard across pages and, if done improperly, it can actually slow you down. One of the key benefits of a good automated FEO tool is the ability to juggle all of these different packaging combinations and provide the optimal package.

Why is this expensive to hand code?

Given the amount of change seen in a modern site, I would suggest that hand coding resource reduction in any sophisticated way across pages is nearly impossible by hand. If you’re just going to put a few common files into a package and reference it everywhere, this problem is much closer to perspective 1, but this is not good enough to gain maximum performance.

How to calculate cost savings

Given how hard this is to do, I would suggest the ROI here cannot really be measured in person-power reduction, but simply in the value of site speed. If you are crazy enough to try to do this by hand, be prepared for months of extra development and a whole lot of pain.

Key rule #2: Add an expires header

Adding expires header is easy. All of the difficulty arises from having to add the right header to the right resource and then to deal with version changes.

Imagine a simple example in which you add an expires header of 24 hours to a resource called logo.gif. Now imagine three hours later that the image changes but the name stays the same.

You now have a problem because everyone who has logo.gif cached will not request it again for 24 hours (or, to be exact, 24 hours minus the time elapsed since they first received it). This is a big problem because now you have people seeing stale content, and stale content is not acceptable.

To deal with this issue, organizations often have poor caching headers or else they embark on the long process of building a sub-system to version objects and control expires headers. They also need a vigilant operations staff to find stale content and they need to keep someone glued to the CDN purge tool. (Purging on a CDN is typically done manually or else you need to burn development hours integrating with their APIs. This becomes more complicated if multiple CDNs are in use, since no two are the same.)

Why is this expensive to hand code?

Proper object versioning and header management is time consuming and expensive to code. Without it, you risk stale content or more roundtrips because your expires headers are not optimal.

How to calculate cost savings

Building a proper version control and header management sub-system is expensive (think many person-months of effort). You also have to factor in the time you spend manually purging CDN caches, as well as the damage that stale content does to your brand.

Other key considerations

This post just scratches the surface in terms of ROI benefits when it comes to automating FEO — and we’ve only covered two rules out of fourteen! I could go on forever on this topic, but for now here are a few other considerations:

Third-party content

As we know, managing third-party content is costly. It also requires a great deal of vigilance to ensure you don’t have SPOFs or poor performance because of the third-party content you are forced to add to your site. Automating performance offers significant dev ROI because good FEO tools will help manage your third-party tags and place them in the right order. Your FEO vendor should save you countless hours in the trial and error process of moving tags around.

Image sizes and resolution

Images are one of the biggest performance challenges and many organizations spend a great deal of time optimizing their images by hand. One of the big time savers from automated FEO is the ability to have all of this work happen automagically.

Using a CDN

Automatically renaming files so they can be served from a CDN can be time consuming. One of the benefits of automated FEO is the ability to quickly get onto and change CDNs, thus saving devs a lot of time.

Final thoughts: ROI is about more than just short-term savings

One of the reasons I’ve avoided writing a post on the person-savings from automated FEO is because I believe very strongly that automated FEO is a tool that is best used in conjunction with great developers – not as a replacement. I have seen benign ROI calculations like this one used by number crunchers to justify making damaging resource reductions. (Don’t be fooled, CFO guy. Your developers are a key asset.) If you run a successful modern ecommerce site, you need great developers working on hard problems. The purpose of automated FEO is to let them work on different problems — in some cases bigger problems.

Offloading the arduous task of automation frees your team to climb bigger mountains and to continue to innovate.

Related posts:

By: Tammy Everts Category: Tags: ,

Speed vs. security: Four ways that security solutions can cause performance problems (and what you can do about it)

14 Aug 2012

3 Comments

Security-related performance problems can happen in a few key areas — some of which you have control over, and some of which you don’t. While each of these areas by itself may not amount to much, the cumulative performance penalty can be significant. And while you may not be able to make performance-improving changes to your (or your visitors’) security features, this makes a compelling argument for why you need to optimize all the other areas that are within your control.

Here are four key ways that security measures can hurt page load:

1. TLS/SSL

Transport Layer Security (TLS) — and its predecessor, Secure Sockets Layer (SSL) — are protocols for encrypting information over the Internet. You know you’re on a site that uses TLS/SSL when you see “https” as the URL prefix.

HTTPS requires an initial “handshake” to create a connection between the browser and the server, and this handshake can be be very slow. This diagram (courtesy of IBM) gives a good idea of how the SSL handshake works:

SSL handshake

The problem

It takes at least four TCP roundtrips just to open a single SSL connection between the client and the server — and this doesn’t happen until after the initial TCP connection has been set up. The amount of data transferred as part of the handshake isn’t huge (under 5 kB typically), but for very small requests this can be quite a bit of overhead.

Important to know: The SSL handshake is actually even more process intensive than the actual data encryption that happens over the connection after the handshake is successfully complete.

How to know if this problem affects you

No one can give you a meaningful answer to this question without some information about the nature of your web site, hardware, software, and network configuration.

There are a couple of ways to look into this problem for your own site:

1. Profile the performance of your web server. There are several tools out there (such as JMeter and Visual Studio) to compare the performance of an HTTP vs HTTPS server.

2. Run WebPagetests of key secure pages on your site. Look at the purple bars on the waterfall chart that indicate SSL negotiation. You don’t want to see:

  • too many purple bars
  • long purple bars
  • purple bars associated with non-essential page resources

Here are a couple of examples showing how you don’t want your waterfalls to look:

SSL: bad waterfall 1

SSL: bad waterfall 2

Solution 1: Fewer handshakes.

Re-use TCP connections. Take extra care when it comes to HTTP keep-alives, in order to create longer-lasting SSL connections.

Solution 2: Offload SSL processing to another device.

You can mitigate the performance concern by offloading the SSL processing to another device, such as a dedicated load balancer or firewall. There is also dedicated hardware for handling SSL, which not only unburdens your servers from dealing with it, but also speeds up the SSL handshakes and encryption, overall.

Solution 3: Make sure you’re not using SSL content on pages that don’t need it.

Some third-party tags, particularly those for website monitoring products (i.e., Alertsite and Verisign), are secure by default, so they add SSL load to every page they appear on — even pages that are otherwise non-secure. Here’s how this looks on a waterfall:

SSL bad waterfall 3

 

Using unnecessarily secure tags is a simple enough mistake to make. Site devs will include the default tag in page templates, so that it’s automatically used on every page of a site, even the non-SSL pages. There are non-SSL versions of these tags. Ideally, devs should use the SSL version on secure pages, and the non-SSL version on the rest of their pages.

2. Security products (e.g., firewalls, IDS/Intrusion Detection Systems, IPS/Intrusion Protection Systems, WAF/Web App Firewalls)

Security products track traffic behaviour at a granular level in order to prevent attacks. They can be used either offline or inline. Products that function offline obviously don’t affect performance, but inline products — also known as “bumps in the wire” — look inside pages in realtime, watching at a much deeper level than load balancers/ADCs.

The problem

It’s difficult to quantify the exact performance penalty caused by security products, but because they’re performing deep packet inspection, we know that they incur extra latency at the packet level.

Solution 1: Ask your security product vendor for details.

Talk to your vendor about the performance impact of their products, and ask them for benchmark tests.

Solution 2: Perform your own A/B tests on your security products.

To test performance impact for yourself, you could set up split tests with the products turned on and off.

3. Browser extensions

As internet users become more savvy about security and privacy, there’s a growing market for plugins that add security support at the browser level. (Here are some industry-recommended plugins for Chrome, Firefox, Internet Explorer, and Safari.) Some of these addons govern your passwords or block ads, which are pretty innocuous from a performance perspective. Others, however, can cause a noticeably performance hit.

The problem

This entire post was inspired by my experience with installing HTTPS Everywhere, an extension for Firefox and Chrome that automatically identifies when you’re visiting a site that supports HTTPS and then serves you a secure version of the page, following the protocol described above in the section on TLS/SSL. After I installed HTTPS Everywhere, I perceived a noticeable slowdown in many pages I visit regularly — most of which don’t really need to be secure, in my opinion.

Some might disagree with this. Google’s motto — “Secure the world” — is a great goal, but right now, given the fact that the average page still takes 8 seconds to load, I can’t rationalize the additional performance hit created by universal HTTPS.

Browser extensions can have other performance implications, ranging from reportedly slower load times due to redirects (KB SSL Enforcer) to preventing pages from working properly (NotScripts and NoScript).

The solution

As a site owner, you have no control over what your users are doing at the browser level. You should, however, have the foresight to anticipate what they’re doing. I recommend that site owners test drive leading security extensions and measure their performance impact from the perspective of a real user

4. Desktop antivirus software

Antivirus software scans incoming files to identify and eliminate computer viruses and other malware such as adware, spyware, trojan horses, etc. It does this by analyzing all files coming through your browser. Like firewalls and security products, antivirus software operates in realtime, meaning that files are paused for inspection before being permitted to download.

The problem

As with security hardware, it’s hard to quantify the performance impact of antivirus software, but a certain penalty is inevitable, depending on the software and on the composition of the page/resource being rendered in the browser.

A few years ago there was an issue with some antivirus software breaking a fundamental performance best practice called compression. This practice involves using gzip to compress content so there are fewer bytes to send. Fewer bytes equal faster pages. The antivirus software ripped out the gzip header in the requests that would have indicated to the site that the browser could compress content. As a result, sites wouldn’t compress content, even if the browser supported compression. So sites kept sending uncompressed content to the browsers. (Steve Souders wrote about this issue here and here.)

The solution

As with browser extensions, you have no control over potential problems caused by AV software if you’re a site owner. But that doesn’t mean you shouldn’t arm yourself with the knowledge that problems are occurring.

One way to do this is by examining your server logs – where you can see if a browser that you know can compress (pretty much any modern browser) showed up without the Accept-Encoding header that would’ve indicated that it supports compression. This will at least tell you if you may have a problem.

Takeaway

In case it needs to be stated, I am emphatically not advocating that people sacrifice security for the sake of speed. That would be ridiculous. Security is an increasingly critical issue, and site owners and internet users need to protect themselves online. The question is: how to protect yourself while reducing the performance penalty caused by your security measures.

While there are some areas, outlined above, in which site owners can improve performance without compromising security, in other areas we have to accept certain performance hits. The only solution then is to focus our efforts on optimizing performance elsewhere.

Related posts:

By: Tammy Everts Category: Tags: , , , ,

The 33 best web performance links of Q2 2012

31 Jul 2012

4 Comments

For some reason, I thought that the past few months had been kind of quiet on the research front, so when I started this post, I thought it would be one of my shortest roundups yet. I was pleasantly surprised to watch it grow to become one of the longest!

There are some great case studies here, of both large and small sites, which I love to see. There’s also some truly excellent debate about responsive design and the mobile web, sparked by a post from Jakob Nielsen last spring, as well as some good stuff about the browser wars and third-party content. So enough with the intro. Let’s get into it.

Case studies

Optimizing Retr-O-Mat’s Web Performance

A casual performance optimizer details her efforts to get Retr-O-Mat’s average load times under 2 seconds. Good information for anyone interested in the nuts and bolts of front-end optimization (FEO).

Web performance can be beautiful too

After performing poorly in a 2011 web performance comparison of leading retailers, Crate and Barrel made WPO a priority moving forward. This blog post from Catchpoint shows just how “beautiful” their performance has been in 2012.

How the Post is improving site performance

Responding to a flood of user frustrations with their website, the IT team at the Washington Post rolled out a number of performance upgrades to their site over the past year. Find out what they did to improve their page speed by 32.4%.

Tips and how-tos

Building a faster web: Tools, tips, and lessons

If “faster connectivity and more bandwidth won’t save us,” then what will? Google’s Ilya Grigorik shares his insight on making the web faster in this in-depth slide deck, and he draws some very interesting conclusions.

How to Make Progress Bars Feel Faster to Users

The human perception of time is anything but linear, and with just minor visual tricks, it gets even more skewed. After reading this post, you may never trust a progress bar again. :)

The 3 white lies behind Instagram’s lightning speed

More cool perceptual tricks. The “secret sauce” behind Instagram’s stellar user experience is rooted in a combination of coding tricks aimed at giving users a feeling of constant responsiveness. Find out how their site “always pretends to work.”

Mobile

The web only works thanks to reload (and why the mobile web fails)

As Mike Belshe points out, web page resources routinely fail, but thanks to the ever-handy reload/refresh button, we can often solve these problems ourselves. With mobile browsing, however, the rules are different. Find out what this means for the future of HTML 5.

Web first for mobile

Performance evangelist Steve Souders focuses his performance research strictly on the mobile web – not on native apps. Why? He’s got more than a few good reasons.

A taste test of mobile website development

A solid webcast on the complex world of mobile development, touching on topics including Responsive Web Design (RWD), server-side device detection, and HTML5 performance on mobile.

Jakob Nielsen on mobile sites vs. full sites

Jakob Nielsen believes that mobile and full sites should be entirely different entities. Summarizing his argument, he states that “good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.”

Is Nielsen wrong on mobile? Arguments abound

From Net magazine: Jakob Nielsen’s assertion that “good mobile user experience requires a different design” is being challenged by a noted mobile expert, who argues that rather than stripping down for mobile, companies should be doing more.

Why we shouldn’t make separate mobile websites

More counterpoint to Nielsen’s post. Smashing Magazine’s Bruce Lawson argues that mobile redirection is unreliable, and excluding features for mobile browsers “perpetuates the digital divide.”

Responsive web design: Missing the point

Still more Nielsen backlash: Brad Frost states that, though mobile browsers are getting better at rendering full websites, creating adaptive sites for mobile users is essential to improving the user experience.

HTML5 features increase mobile usage by 28%

Interesting piece explaining how static pages needing an upgrade can vastly improve mobile user engagement through the addition of HTML5. The new release features interactive galleries, overlays, and expandable/collapsible boxes, driving up pageviews and decreasing bounce rates.

Tools

More ways to measure web performance with User Timings

Google Analytics has expanded its collection of Site Speed reports with a new feature called User Timings. The feature enables tracking of specific load times for discrete hits, images, and other user interactions.

New mod_spdy release supports Apache servers

More from Google. The latest version of mod_spdy – an Apache module that adds SPDY server support – is intended to fix bugs found in the original release.

“Speed Index” introduced as new performance metric

The Speed Index metric has been added to WebPagetest, helping measure the speed at which page contents are visually populated. The tool is especially useful for comparing page experience before and after optimization.

Browsers

Browser Speed Tests: Chrome 19, Firefox 13, Internet Explorer 9, and Opera 12

Lifehacker conducts it’s semi-regular browser speed tests, pitting the four titans of desktop browsing against each other in races for startup speed, tab loading times, and other performance indicators.

Which Browsers are the Fastest?

An interesting companion read to the Lifehacker piece, New Relic’s “Speed Wars” study shows that, while IE 9 speeds past other browsers on Windows, Chrome 13 on Mac was overall the fastest experience. In mobile speed tests, the fastest experience was delivered by Blackberry Opera Mini at 2.6 seconds, twice as fast as Safari 5.1 on iPad.

How the Chrome Predictor hides latency from users

Ilya Grigorik demonstrates how Google Chrome hides latency from users. Interesting stuff here.

Internet Explorer market share surges, as IE 9 wins hearts and minds

From Ars Tecnica: “The browser wars are back on in earnest. For the second time in three months, Internet Explorer made large gains, picking up almost 1 point of market share. Chrome, Firefox, and Safari all lost out, as Internet Explorer 9 won over new users.”

CDNs

A one-size-fits-all CDN solution isn’t always best

Server configurations come in all shapes and sizes, which means a one-size-fits-all CDN is seldom effective. Find out which Level 3 customer was the beneficiary of a custom CDN solution and how it worked out.

Third-party content

10 Golden Rules for 3rd Party Providers

Murphy’s Law reigned supreme throughout June, with a flood of large-scale outages taking down some of the world’s most popular websites. Given the inevitability of online failures, third-party providers must be prepared to deal with the worst. The folks at Catchpoint outline the 10 Golden Rules by which all third-party providers should live by.

The vendor who flunked the web performance test

Are third-party vendors ignorant to the consequences of slow web performance? According to Catchpoint they are, as they detail a story of one such vendor who was completely unaware of the performance impact of their product.

Average UK website has 14 trackers per page

Interesting findings from TRUSTe: Despite the prevalence of privacy policies, over two-thirds of trackers on UK websites originate from third-party companies, and almost half embed themselves permanently.

Google releases +1 button preview – loads 20% faster

Google announced that they’ve improved performance of the +1 button and Google+ badge. By reducing the size of the js/plusone.js loader and making the code smarter, page elements now load 20% faster.

Third-party JavaScript should be loaded asynchronously

Old news to some, but still worth mentioning: Third-party JavaScript should be loaded asynchronously, as it helps avoid slowdowns and can speed up page loads.

Third-party front-end performance, Act 1

Application provider Bazaarvoice is delving into the realm of front-end performance, and provides an interesting third-party perspective.

Opinions and analysis

Performance Nightmare: Nasdaq & the Facebook IPO

When Facebook began trading on May 18, 2012, a series of performance failures on Nasdaq.com caused a huge headache for the company. This article from Intechnica asks how much these badly timed hiccups cost investors.

More, better, faster: Steve Souders on WPO

Steve Souders kicked off O’Reilly’s Velocity video podcast series with an in-depth discussion of the state of web performance optimization. Key topics included measuring slowness, performance monitoring tools, and whether mobile disrupts performance.

Other research

How complex systems fail

As a complex and interdependent system, the web is prone to catastrophe at the highest levels. In this fascinating paper on resilience engineering, presented at Velocity 2012, Dr. Richard Cook outlines the reasons why all complex systems are intrinsically hazardous, why disaster is always just around the corner, and how failure-free operations still require experience with failure.

The growing epidemic of page bloat

I don’t usually pimp my own writing here, but this information is too important not to share. I wrote a piece for GigaOM showing that the average page size is now over 1MB, according to the HTTP Archive. At current growth rates, the average page could hit 2MB by 2015, which is a really big deal, especially for mobile users.

How fast are websites around the world?

Some fascinating findings here. Google’s Site Speed Reports provides detailed latency data for page load times by separating data according to device, location, and industry.

These links were all sourced from Strangeloop’s Web Performance Hub, which contains hundreds (and by now, possibly even thousands) of industry-wide links, organized by topic, source, research type, and industry. It’s a pretty good resource, if I do say so. If you have any new links to recommend, let me know.

http://t.co/EHbRdT6r
10 Golden Rules for 3rd Party Providers [article]
Catchpoint – June 26, 2012
Summary: Murphy’s Law reigned supreme throughout June, with a flood of large-scale outages taking down some of the world’s most popular websites. Given the inevitability of online failures, third-party providers must be prepared to deal with the worst. Find out the 10 Golden Rules by which all third-party providers should operate by.
http://t.co/LGYUpGn1
End-to-end optimization: Taking content delivery to the next level [blog post]
Web Performance Today – June 27, 2012
Summary: Strangeloop Networks is thrilled to announce the launch of our latest product, Network Accelerator. Learn all about how this product works, what it does – and most importantly – why it’s a major step forward for content delivery networks.
http://t.co/T4z69s7k
How complex systems fail [research paper]
CTALab.org – June 26, 2012
Summary: As a complex and interdependent system, the web is prone to failure and catastrophe at the highest levels. In this fascinating paper on resilience engineering, Dr. Richard Cook outlines the reasons why all complex systems are intrinsically hazardous, why catastrophe is always just around the corner, and how failure-free operations require experience with failure.
http://bit.ly/LzGPqN
Mobile optimization starts with mindset: Hooman Beheshti interviewed at Velocity 2012
O’Reilly Media – June 25, 2012
Summary: Where are we in the mobile optimization life-cycle? What mindset should site owners adopt when boosting mobile performance? Are performance measurements improving? In this video, Strangeloop Technology VP Hooman Beheshti offers his unique insight on the current state of mobile.
http://t.co/Vnced8tq
The 90-Minute Mobile Optimization Life Cycle [slides]
Strangeloop Networks – June 25, 2012
Summary: Strangeloop Technology VP Hooman Beheshti wowed attendees at this year’s Velocity Conference with a presentation on the mobile optimization life cycle. For those who missed it, be sure to check to check out these fascinating slides.
http://bit.ly/Nu1gCi
Ghosts of Velocities Past: 9 presentations that are still relevant today [blog post]
Web Performance Today – June 20, 2012
Summary: Velocity’s short (yet incredibly important) history is filled with memorable moments, and these 9 presentations from past conferences remain relevant today. Perhaps not trendsetting anymore, but certainly trend affirming, which may just be better.
http://bit.ly/MFuxMR
My recent post on SEOMoz: 13 Questions (and Answers) About Google, Site Speed, and SEO [article]
SEOmoz – June 18, 2012
Summary: In this article, Strangeloop president Joshua Bixby breaks down how site speed and performance metrics affect Google page ranks. For anyone who has ever wondered how Google manages to make performance metrics affect SEO, this article is a must-read.
http://mz.cm/M24fGc
Introducing: New Browser Tax feature for our ecommerce customers [blog post]
Web Performance Today – June 14, 2012
Summary: Ever wish you could arbitrarily tax your customer base for failing to stay current, with zero repercussions? With the new Strangeloop Browser tax, your wish is now a reality!
http://bit.ly/NC5Q65
Optimizing Retr-O-Mat’s Web Performance [blog post]
Finding Marbles – June 9, 2012
Summary: For the “WPO guy’s wife,” average load times just aren’t good enough. In this post, a blogger and casual performance optimizer details her efforts to get Retr-O-Mat’s average load times under 2 seconds. Great information for anyone interested in the nuts and bolts of WPO.
http://t.co/k0lXkniG
Browser Speed Tests: Chrome 19, Firefox 13, Internet Explorer 9, and Opera 12 [article]
Lifehacker – June 12, 2012
Summary: It’s a battle of startup times, tab loading times and other KPIs between the four titans of Windows browsing. Lifehacker’s speed tests are always entertaining for what they’re not afraid to say, and this article is no exception.
http://bit.ly/Nb2ibS
Marrying CDNs with front-end optimization for maximum acceleration [blog post]
Web Performance Today – June 12, 2012
Summary: Front-end optimization (FEO) has been weaving its way further into content delivery networks (CDNs) over the past two years, and the dynamic between these two technologies continues to evolve. In this video presentation, Strangeloop’s Joshua Bixby breaks down the benefits of combining these performance solutions.
http://bit.ly/L3aatz
How the Chrome Predictor hides latency from users [article]
Igvita.com – June 4, 2012
Summary: Google Chrome features countless tools for supercharging load times, but when those aren’t enough, the browser can hide latency from users. Find out how!
http://bit.ly/Nw6ZMh
Building a faster web: tools, tips, and lessons [slides]
Igvita.com – June 3, 2012
Summary: If “faster connectivity and more bandwidth won’t save us,” then what will? Google’s Ilya Grigorik shares his insight on making the web faster in this in-depth slide deck, and draws some very interesting conclusions.
http://bit.ly/L0eERH
The “performance poverty line”: What is it and why does it matter? [blog post]
Web Performance Today – June , 2012
Summary: The “performance poverty line” is the point at which business metrics have sunk so low, load times cease to matter. But how is this line measured? Does it differ between industries? And most importantly: is there hope?
http://bit.ly/NJAqs2
A one-size-fits-all CDN solution isn’t always best [article]
Level 3 – June , 2012
Summary: Server configurations come in all shapes and sizes, which means a one-size-fits-all CDN is seldom effective. Find out which Level 3 customer was the beneficiary of a custom CDN solution.
http://bit.ly/M9P5xt
Why the Facebook outage is (yet another) wakeup call for site owners [blog post]
Web Performance Today – June , 2012
Summary: The hazards of running third-party scripts are well documented, but the May 31st Facebook outage was another stern reminder. In this post, Strangeloop’s Joshua Bixby discusses all things third-party, including rogue content and common performance pitfalls caused by third-party content.
http://bit.ly/JQj7GX
The web only works thanks to reload (and why the mobile web fails) [article]
Belshe.com – June , 2012
Summary: Web page resources routinely fail, but thanks to the ever-handy reload/refresh button, we can often solve these problems ourselves. With mobile browsing, however, the rules are different. Find out what this means for the future of HTML 5.
http://bit.ly/NAAQ3O
How to Make Progress Bars Feel Faster to Users
UXMovement – June , 2012
Summary: The human perception of time is anything but linear, and with just minor visual tricks, it gets even more skewed. After reading this post, you’ll never trust a progress bar again!
http://bit.ly/NcsVfg
Does the average web user waste two days a year waiting for pages to load? [blog post]
Strangeloop Networks – June , 2012
Summary: It may not be true, but in web performance, perception is reality. Web users in the UK are less than pleased about their online experience, but just how cranky are they?
http://bit.ly/LSFIlv

Related posts:

By: Tammy Everts Category: Tags: , , , , , , , , , , , , , , , , ,
1 2 3 4 5 6 7 8 »