by Ryan Irelan
You hear a lot about web performance testing but you’re still unsure why you should spend the extra time (and money) doing this type of work. How does it add value to you project? How can you convince your client or boss that it’s a good use of time and money?
There are a lot why you want to do performance testing but these three are the most important reasons. They are also broadly applicable to most projects.
The three performance testing reasons are:
Let’s talk about each of these three reasons for performance testing a little bit more.
More than five years ago, Google announced that it was going to eventually include page speed as part of its ranking algorithm for organic Google search results.
The reason for this is clear: slow pages tend to be abandoned by visitors rather quickly. If you look at a page that may take, let’s say five seconds to load, most users will abandon that page and not even try to pursue it again.
If that page was listed at the top of the rankings for a certain search term on Google, then that search results page will no longer be as valuable to the user as it would be if all of the results at the top of the list were fast accurate and relevant.
Google prides itself on providing accurate relevant and good search results. That’s one of the reasons that it became the most popular search engine on the web! If Google served results that are accurate and relevant but slow to load, causing the users to wait a long time to see the page, then that threatens the very thing that made Google so popular in the first place.
In fact, Google even tested out user behavior with slower search results returning.
Back in 2009 they tried a test where they slowed down the search results page so it served a slower page to some visitors. What they found was that their experiment “demonstrated that slowing down the search results page by 100 to 400 ms has a measurable impact on the number of searches per user.”
As Google slowed down the page speed the engagement of their users decreased. When you search Google you are after an answer—the search result or relevant page—and you want to get there as fast as you can. It’s not a surprise that slowing down the results page caused a drop off in the number of searches.
Who wants to sit and wait for a page to load? Do you find that enjoyable? I certainly don’t.
Google reaffirmed their belief that performance matters. And in a big way.
As part of the performance initiative, Google added the PageSpeed Insight, which is a freely available tool for measuring your page speed and getting recommendations for how to improve performance.
Performance is a design feature. -Brad Frost
Just like with Google and the noticeable change in user engagement when they increase the page time for the search results, having a slow performing website or webpage also decreases the user experience on your site.
If we think of web performance as another part of the project, just like we would think about the user experience, information architecture, and the design, we are less inclined to neglect performance during the project pushing it off to be something that we just handle later on after the site is complete and implemented.
By making Web performance something that matters as part of the user experience and design, we are then forced to consider it very early on in the project.
In the old days, and by that I mean 5 to 10 years ago, a typical project methodology was the waterfall process. Each discipline would do their work and then pass it down the line to the next discipline. Decisions were not made inter-disciplinary, instead in a silo of each discipline.
Designers were working in a silo without any consideration or understanding of what it would take to develop the features that they designed. Developers were working in their silo without communicating with designers on implementation details that might impact their designs. This includes how a design decision would impact the implementation when done within the bounds of the agreed timeline and budget.
A certain feature, as designed, could require twice as many database queries or some API that will add overhead, which in turn could slow down the performance of the page. It could also mean that the developer would need extra time to implement proper caching and other performance enhancements on the back-end in order to make the feature acceptably performant.
But now, a trend in the work of people to whom I’m connected—and I’d argue this is an industry-wide trend—is that designers and developers are working closer together so that they are making the decisions on the features of the website in unison. Developers can help influence and inform the designers decisions for both visual design and user experience design. And designers can work closely with developers on the implementation of their designs.
This new trend is encouraging. It is not only encouraging because we are all more focused on working together as a team but also because it helps us create better performing websites at beginning of the project instead of waiting until the end, as spackled-on, last-minute consideration.
When you wait until the end to consider performance you have the weight of all of the decisions of the entire project on your shoulders pressing down and preventing you from really making it absolutely best decisions for performance.
When we wait until the end for performance improvements we usually need to pull in more technology and resources, some of which can be very expensive, instead of designing and implementing a performant website from the beginning.
Performance is both a design feature and a way of working.
Just add another server. Add more RAM. -Someone, somewhere
We design, code, and build the new website and start testing it. If it’s not fast we look immediately at more server resources as the solution.
We increase memory, increase bandwidth, we offload assets to a CDN, we move the database to a dedicated server.
All of these solutions are expensive. And maybe not even necessary.
These solutions are especially expensive if you’re working on a site that gets high traffic and requires infrastructure beyond just one virtual server or some cheap shared hosting.
Just because a high traffic website will need some additional services to run properly doesn’t mean we can slack on performance.
In fact, the converse is true. The higher traffic the site the more careful we have to be about performance.
Increasing server resources is, of course, unavoidable if the website traffic requires it. But for a site that serves tens of thousands, hundreds of thousands, or even millions, of visitors in a month, making sound user experience and design decisions with performance in mind can literally save thousands of dollars in costs.
(Webpagetest.org has a small part of its test results that shows how expensive your site is in consuming resources.)
If you’re doing client work, you can literally save your clients a lot of money by keeping web performance in mind throughout the project. And, since client work is always done in the service of the clients needs and requirements, saving the money is definitely a good thing.
Those are the three reasons to web performance testing:
The three core pieces of launching a successful and sustainable website.
Learn everything you need to know to get up and running with web performance testing in our 2 hour video course.
by Ryan Irelan
Web pages are getting bigger. In 2015, according to the HTTP Archive, the average web page increased in size by 16%.
2 MB pages are common now.
But assigning blame isn’t a solution. Hand-wringing and finger-pointing do nothing to improve the situation.
However, understanding how your pages perform_while you are developing them_ does.
If we can become more aware of how our feature, design, and development decisions impact the performance of the website, we can address problems before they impact the site’s user experience.
And that’s what we’re after in Web Performance Testing.
by Ryan Irelan
In a previous lesson I covered how to find TTFB, the Time to First Byte. TTFB is one of several metrics we can use to measure the performance of our websites.
In this lesson, we’ll expand the coverage of performance testing metrics and review the most important performance metrics to consider when building and testing your website.
by Ryan Irelan
The main reason to create a performance budget is to have a tangible starting point for conversation around a web page or website. It shouldn’t act as gospel, but it’s a thing you can measure against. It’s your frame of reference. -Dan Mall
A performance budget is a plan.
It’s a guide against which to measure your work: your design and development decisions, and feature choices. The performance budget is meant to aid you during the web design and development process and then be a data point when you deploy the new site to a staging and production server against which to measure other performance testing and metrics.
A performance budget is not a hard line that you cannot cross.
You certainly should not ignore it completely (otherwise what’s the point of having one) but treating it as a best case scenario is a pragmatic approach.
A performance budget lets you make informed decisions.
Consider the performance budget when you are:
Current knowledge is that the term “performance budget” was first mentioned in an article by Tim Kadlec in the context of web design and development teams.
Tim covered this in the context of improving the performance of responsive websites after a trend of heavier page weight sites being designed. On a fast connection the extra weight was nary a problem, but on mobile, where bandwidth is often more limited, loading a full desktop site worth of assets for a more constrained mobile device view was an issue.
You can think of a performance budget the same way you think of a budget for your personal finances. You set a limit on what you want to spend in a given month and then assign values to categories accordingly, until that limit is met.
As the month progresses, you have to make choices along the way. Do you go out to that fancy steak dinner for $200 and deplete your Eating Out budget? Or do you skip it so you can get lunch out for the next couple weeks instead of bringing a ham sandwich to the office?
It’s okay to choose either option, but if you choose both, you’ll exceed your budget.
The same approach is used for performance budgets. Instead of setting a monetary amount we can’t exceed, we set some webpage metric. This could be one of the following:
The first two are fairly straight-forward to test and shouldn’t vary much across environments.
The last one, total render time, is a bit harder to test because it could vary depending on the environment (bandwidth being the wildest variable here) and the web browser used.
I like to use the total page weight and total number of HTTP requests because I can regularly and reliably test it.
The advantage of using number of HTTP requests and page weight is that they nicely adapt to a site that is out of active design and development and in the QA/Launch phases.
This is when you are ensuring the site performance meets your expectations based on the budget you set earlier in the project. No matter which environment we’re in, the number of HTTP requests and the page weight are still good measurements. This is the case even if those environments affect the total measurements (due to extra code for analytics, A/B testing, etc); we still want to hit—or come close to—our performance budget.
A performance budget helps us make informed choices both during the site development and over the course of its life.
by Ryan Irelan
When we do web performance testing, one of the performance metrics that we’ll want to test is Time to First Byte (TTFB).
Before I jump in to how to measure TTFB (via the video below–wait don’t skip!), let’s review what TTFB is and how it fits into the bigger picture.
Firstly, is not a sole actor. It is only one of the four network metrics that can impact page load time.
There are also:
We’ll cover the rest another time, but for now let’s focus on TTFB.
Time to First Byte, TTFB for short, is the amount of time it takes for the browser to receive the first byte of data from the server after the browser makes the request.
TTFB does not include DNS lookup or any SSL negotiation that has to take place before there is a connection to make the request to the server. You can see this demonstrated in the video below where I show how to find out your TTFB using both Google Chrome and the Webpagetest.org.
Let’s roll the video:
TTFB is important to measure is because it can create the perception that your page load is slow.
A fast TTFB will not help us if we have other performance problems with our webpage (e.g. if our page weight is too heavy or its assets not optimized).
Even if we have a snappy page in terms of other non-network metrics, a slow TTFB can give the perception of a slow page speed.
You can do all the work you want on improving other metrics for your webpage performance, however, if the TTFB is unacceptably slow, then your page speed will be perceived as slow by the end-user.
by Ryan Irelan
A performance budget sounds great but how do I implement this in the real world, with real clients?
One bit of advice to get started (I learned this the hard way): don’t have an internal-only performance budget and use it to fend off client feature or design requests without first including the client in the formation of said performance budget.
They’ll be confused and you will probably look defensive at best, aloof at worst.
If you have clients that are not used to having a performance budget in a project, then here are some tips for talking about performance budgets with clients:
It’s always (always!) easier to be upfront and transparent with your clients. Doing the same with performance budget will yield better project results.
The burden is on you–the designer, developer, owner–to show why a performance budget isn’t just some nerdy, tech-y thing that makes us feel good about ourselves and the tools we use. Make it yet another tool that helps you work together with the client toward the project’s larger goals.
The end goal is never to “build a website” so don’t approach sales, design, or development like it is.— Mijingo (@mijingo) May 11, 2015
Our courses are offered in Team Packs (up to 5 people) and Company Packs (up to 25 people), so you can make one simple, fast purchase to train your entire staff.
Prices are listed with each course. Need more than 25 or something custom?Send Your Requirements