Tag: Effective Web Performance

People in every organization are happy (in an unhappy way) to tell you exactly what their level of Web performance pain is. They go into great detail on how every performance issue affects them and and why it makes every day an unpredictable and almost unmanageable challenge.

If you take the personal perspective of Web performance pain, the risk not finding the real problem, the true cause of the pain.

Talking to customers at all levels of organizations has shown that when you ask “where it hurts”, they can tell you exactly what they want you to work on. And once you solve that problem, you get another person from the same organization with a different pain coming to you, complaining that you have ignored them.

A whole-organization focus is required when working to solve a customers Web performance pain. And it starts by asking questions of everyone in a company, not just the one who came to you for the initial diagnosis. Different groups at different levels have different questions.

Here’s a (very basic) list of some of those that you should be prepared to answer as you work to diagnose a company’s Web performance issues.

C-Level

• How am I doing against my competitors?
• How does performance affect my revenue?
• If I want to use the Web for more revenue, what do I need to do to make it work?
• How does Mobile deliver what I need?

VP, Operations

• How much will it cost me to deliver the necessary Web performance?
• What is critical for me to deliver now, and what can I delay until the next budget cycle?
• How do I ensure that Web performance issues don’t affect revenue?
• Are my partners helping or hindering us?
• How do I get Marketing to the table to understand the technology boundaries we have?

VP, Marketing

• How do I effectively use the Web without alienating customers with slow performance?
• How do I ensure that our design is delivered appropriately to both fixed-Web and mobile users?
• What parts of the site are customers unsatisfied with due to performance? Do my promotions scale to handle the surge in customers?
• How do I get Operations to understand that delivering new experiences with leading-edge technology is critical for us to be successful?

Director, Operations

• I spend most of my time on troubleshooting conference calls. How can I reduce this drain on my time and resources?
• My team spends most of its time trying to correlate data between 5 different systems. Help!
• The latest design is putting a massive strain on our infrastructure. Didn’t anyone test this on the production servers before it went live?
• I know that we need to take a load of our servers, but I don’t know how to choose a CDN. What do I need to do?

Operations Staff, NOC

• Man, I get a lot of alerts. How do I tell which ones I need to care about?
• This sure looks like a problem. How do I show the appropriate folks that this issue is their responsibility?
• Most of the time, the issues I investigate are with one third-party. Who is responsible for fixing this and does it really affect customers?
• I get bonused on fast MTTR. How can I figure out what the problem is faster?

In the sections above, notice that none of the questions need to be answered with product descriptions. Companies are desperate to understand not how other companies deployed the latest Kazoo to solve their Waka-waka problem, but how they made life easier and more manageable.

Coming to the customer with an open mind and a listening ear is the new hallmark of Web performance.

Every so often, you wake up and realize that the world has changed around you. Or, to say it better, your view of the world has changed so profoundly, but also so subtly and slowly that it is imperceptible unless you take the time to look back at where you came from.

Six years ago, if you had asked me what the most important problems in Web performance were, I would have reeled off a list that was focused on technology and configuration: HTTP compression, HTTP persistent connections, caching, etc. In fact, six years on, these are still the concepts that dominate Web performance conversations.

Slowly, glacially, shaped by six years of working with customers and clients, listening to the Web performance conversations that flow across the Web and within companies, I realize that technology is only one component of the Web performance solution.

Web Performance is NOT Just Technology

Most organizations focus too much of their efforts on solving the technical problems because they are discrete, easy to track, and produce quantifiable results.

Fair enough.

But a highly tuned engine with a rusted chassis, four flat wheels, and a voided warranty still has a Web performance problem, even if it is technically sound.
The complexity of the issue arises from the terminology used. Web performance, in current parlance, refers almost completely to the delivery of the site in an appropriate and measurable manner.

Web performance is not simply the generation and delivery of HTML and other objects. Web performance is conversation that defines the basic nature of any Web site.
Approaching Web performance, as I had for so many years, as a technical problem with a discrete solution overlooks the true nature of Web performance. A culture of effective Web performance absorbs a number of different inputs, and then ensures that the site performs across many different vectors, not just the two-dimensional response/success over time graph.

Web Performance is Culture and Communication

Web performance is an issue of culture. And at the root of all cultures lies communication.

The Web performance conversation has three components, each one shaping the potential response to the problem and providing elements of the solution.

1. Technical Capabilities

Technical organizations spend a great deal of their time defining what they can’t do. In an organization that has a culture of effective Web performance, the technical teams provide clear definitions of the current capabilities, and clearly demonstrate how far they can take the organization down the chosen path, hopefully without spending all of the company’s treasure.

2. Business Objectives

Just as the technical organization has to define what they can do with what they have, the business organization has to come to the table with a clear definition of what they want to achieve. If a business goal is clearly stated to the technical team, then a conversation about where there may be challenges and opportunities can occur. When business and IT talk and listen, a company is becoming far more effective at delivering the best site they can.

3. Customer Expectations

Neglected, forgotten, nay, even ignored, the role of the customers’ expectations in the Web performance equation is just as critical as the other two participants. With clear business objectives and defined technical capabilities, a site can still be seen as a Web performance failure if the expectations of the customer are not met. And it is not simply listening to customer and providing everything they want. It’s understanding why they need a feature/function/option in order to be more successful at what they do, and balancing that against the other two players in the conversation.

Now What?

But where does an organization that wants to take Web performance beyond the technical problem, and into the realm of the strategic solution go?

Do a search on any search engine and you will find page upon page of technical solutions to a supposedly technical problem. Web performance is not solely a technical problem. In many cases, the site is configured and tweaked and tuned and accelerated to such a degree that you have to wonder if is under-performing out of spite more than any other reason.

Scratch the surface. Look beyond the shiny toys and massively-scaled infrastructure and you will find that technology is not the issue. The demand placed on the site by the business are bogging the site down in ways that no amount of tuning could improve.

Perhaps the business goals of the site, the need to support the business, have pushed the technology to its breaking point or beyond, but the technology team cannot clearly articulate what the problem or solution is.

Maybe customers, used to competitors delivering one level of Web performance and experience are simply not happy with the site, no matter how tuned it is and how clearly the call to action may be.

Making a Web site perform effectively means stepping back and asking some key questions:

• Why do we have a site?
• How does this site help our business?
• Why do our customers use our site?
• Do we like using our site?
• What are our competitors doing?
• What are the best Web companies doing?

These seem like silly questions. But you may be surprised by the differing answers you get.

And from there, the conversation can start.

Takeaways

Simply put, Web performance is not about understanding how to make your site faster. Web performance is about understanding what you can do to make your site better. An effective Web site is one that is shaped by a culture of effective Web performance.

Striving to make a better, more effective Web site may lead to such profound cultural and organizational changes that the process ends up making a better company. A company where the Web site is seen as an active conversation shared with employees, shareholders, investors, and customers.

A conversation where you explain what can be done, why you are doing it, and how you will do it. A conversation where you listen to what must be done, how it is expected to work, and what the customer defines as success.

So when you wake up six years from now, and realize that the day you stopped treating your Web site as a technical problem that needed to be fixed, and started seeing it as an opportunity to create a more effective business, I hope you smile.

The moment a Web site goes live, the publishers lose control of the performance.

When I say lose control of the performance, I mean that despite everything that has been done to ensure scalability and capacity, the Web is inherently an infrastructure that is out of anyone’s direct ability to manage.

This is something that needs to be accepted. And while the datacenter is only that part of an application/infrastructure/network that can be directly managed by the Web site’s owners, a company has to accept that the real datacenter is the Internet. Not a datacenter that is on the Internet; the Internet as the datacenter.

Now that your head is spinning, let’s step back and consider this idea for a minute. The whole concept of the Internet being the datacenter makes operations and IT folks very uncomfortable. Why? There is no way for one company to manage the Internet. As a result, the general perspective is that the Internet can’t be trusted, and all that can be done is manage what can be managed directly.

Ignoring the Internet allows many organizations to leave the entire Internet out of their application or performance planning. They will measure and monitor, and they may even employ third-parties to help improve performance. When the shiny exterior is peeled back, it’s pretty clear that these organizations have built their entire performance culture on the assumption that if a problem exists on the Internet, there is nothing that can be done by them to fix it.

This may be effectively true. And it is not positive way to ensure effective Web performance

Having a what-if, emergency response plan in place is never a bad idea. If a problem appears on the Internet, and it affects your Web site, what are you going to do about it? Whine and moan and point fingers? Or take actions that effectively and clearly communicate to customers the steps you are taking to make things right?
Wait. Managing the Internet through customer communication?

I argue that besides working feverishly behind the scenes to resolve the problem, customer communication is the next most critical component of any Web performance issue management plan.

Web performance issue management plan. You have one, don’t you?
Well, when you get around to it, here are some concepts that should be built into the plan.

Effectively monitor your site

How can measurement and monitoring be part of issue management? Well, isn’t it always good policy to detect and begin investigating problems before your customers do?

Key to the measurement plan is monitoring the parts of your application that customers use. A homepage test will not give you vital information on issues with your authentication process, and is the same as saying the car starts, while ignoring the four flat tires.

If you aren’t effectively monitoring your site, your business is at risk.

Measure where the customers are

If your organization is focused on what it can control, then it will want to measure from locations that are controlled, and can provide stable, consistent, repeatable data.

Hate to break this to you, Sparky, but my Internet connection isn’t an OC-48 provisioned through a large carrier with a written SLA. Real people have provider networks that are congested, under-built, and deliver bandwidth using the old best effort approach.

Some customers may have given up on wires altogether, and access the site through wireless broadband or mobile devices.

Understand how your customers use your site. Then plan your response to managing the Internet from the outside-in.

Test with what your customers use

The greatest cop-out any Web site can make is Our site is best viewed using…
I’m sorry. This isn’t good enough.

Customers demand that your site work the way they want it to, not the other way around. If a customer wants to use Safari on a Mac, or Chromium on Linux, then understanding how the site performs and responds with these browsers is critical.
The one-browser/one-platform world no longer exists. If a large number of customers with one particular configuration indicate that they are having a problem with the new site, what is the proper reaction?

And why did this happen in the first place?

Monitor and respond to social media

No, this isn’t just here for buzzwords and SEO. In the last year, Twitter and Facebook have become the de-facto soapboxes for people who want to announce that their favorite site isn’t working. Wouldn’t hurt to monitor these sites for issues that might not be detected by traditional performance monitoring.

This approach means that you have to be willing to accept responsibility when something affects your site performance or availability, even if it isn’t your fault. No need to tell folks exactly what the problem is, but acknowledging that there is a legitimate issue that you recognize will go a long way toward making visitors/customers more understanding of the situation.

Get your message out effectively

Communicating about a performance issue means that the Marketing and PR teams will have to be brought in.

What? Marketing and Operations/IT working together? Yes. In a situation where there is a major outage or issue, Marketing will DEMAND to be involved. Wouldn’t it be easier if these two parts of the organization knew each other and a plan for responding to critical performance issues?

If Marketing understands the degree of the problem, what it will take to fix, and what is being done about it, they can craft a message that handles any question that might come in, while acknowledging that there is an issue.

A corollary to this: If there is an issue, don’t deny it exists. Denying a problem when it clear to anyone using the site that there is one is worse than saying nothing at all.

Takeaway

Practicing effective Web performance means a company understands that directly managing the Internet is impossible, but having a process to respond to Internet performance issues is critical. A Web performance incident plan shows that you understand that stuff happens on the Internet and you’re working on it.

Slap up some measurements. Look at some graphs. Make a few calls. Your site is faster. You’re a hero.
Right.

Effective Web performance is something that requires planning, preparation, execution, and the willingness to try more than once to get things right. I have discussed this problem before, but wanted to expand my thoughts into some steps that I have seen work effectively in organizations that have effectively established Web performance improvement strategies that work.

This process, in its simplest form, consists of five steps. Each step seems simple, but skipping any one of them will likely leave your Web performance process only half-baked, unable to help your team effectively improve the site.

1. Identification – What do we want/need to measure?

We want to measure everything. From everywhere.

This is an ineffective approach to Web performance measurement. This approach leads to a mass of data flowing towards you, causing your team to turn and flee, finding any way possible to hide from the coming onslaught.

Work with your team to carefully chose your Web performance targets. Identify two or three things about your site’s performance that you want to explore. Make these items discrete and clearly understood by everyone on your team. Clearly state their importance to improving Web performance. Get everyone to sign off on this.

Now, what was just said above will not be easy. There will be disagreements among people, among different parts of the organization, about which items are the most crucial to measure. This is a good thing.

Perhaps the greatest single hindrance to Web performance improvement is the lack of communication. An active debate is better than quiet acceptance and a grudging belief that you are going the wrong way. Corporate silos and a culture of assurance will not allow your company to make the decisions you need to have an effective Web performance strategy.

2. Selection – What data will we need to collect?

In order to identify a Web performance issue (which is far more important than trying to solve it), the data that will be examined will need to be decided on. This sounds easy – response time and success rate. We’re done.
Right.

Now, if your team wants to be effective, they have to understand the complexity of what they are measuring. Then an assessment of what useful data can be extract to isolate the specific performance issue under study can be made.
Choose your metrics carefully, as the wrong data is worse than no data.

3. Execution – How will we collect the data?

Once what is to be measured is decided on, the mechanics of collecting the data can be decided on. In today’s Web performance measurement environment, there are solutions to meet every preferred approach.

• Active Synthetic Monitoring. This is the old man of the methods, having been around the longest. A URL or business process is selected, scripted, and them pushed out to an existing measurement network that is managed/controlled. These have the advantage of providing static, consistent metrics that can be used as baselines for long-term trending. However, they are locked to a single process, and do not respond or indicate where your customers are going now.
• Passive User Monitoring – Browser-Side. A relative newcomer to the measurement field, this process allows companies to tag pages and follow the customer performance experience as they move through a site. This methodology can also be used to discretely measure the browser-side performance of page components that may be invisible to other measurement collection methods. It does have a weakness in that it is sometimes hard to sell within an organization because of its perceived similarity to Web analytics approaches and its need to develop an effective tagging strategy.
• Passive User Monitoring – Server-Side. This methods follows customers as they move through a site, but collects data from a users interaction with the site, rather than with the browser. Great for providing details of how customers moved through a site and how long it took to move from page to page. It is weak in providing data on how long it took for data to be delivered to the customer, and how long it took their browser to process and render the requested data.

Organizations often choose one of the methods, and stay with it. This has the effect of seeing the world through hammer goggles: If all you have is a hammer, then every problem you need to solve has to be turned into a nail.

Successful organizations have a complex, correlative approach to effective Web performance analysis. One that links performance data from multiple inputs and finds a way to link the relationships between different data sets.

If your team isn’t ready for the correlative approach, then at least keep an open mind. Not every Web performance problem is a nail.

4. Information – How do we make the data useful?

Your team now has a great lump of data, collected in a way that is understood, and providing details about things they care about.
Now what?

Web performance data is simply the raw facts that come out of the measurement systems. It is critical that during the process of determining why, what and how to measure that you also decided how you were going to process the data to produce metrics that made sense to your team.
Strategies include:

• Feeding the data into a business analytics tool
• Producing daily/weekly/monthly reports on the Key Performance Indicators (KPIs) that your team uses to measure Web performance
• Annotate change, for better or worse
• Correlate. Correlate. Correlate. Nature abhors a vacuum.

Providing a lot of raw data is the same as a vacuum – a whole bunch of nothing.

5. Action – How do we make meaningful Web performance changes?

Data has been collected and processed into meaningful data. People throughout the organization are having a-ha moments, coming up with ideas or realizations about the overall performance of the site. There are cries to just do something.
Stick to the plan. And assume that the plan will evolve in the presence of new information.

Prioritizing Web performance improvements falls into the age-old battle between the behemoths of the online business: business and IT.
Business will want to focus on issues that have the greatest effect on the bottom-line. IT will want to focus on the issues that have the greatest effect on technology.
They’re both wrong. And they’re both right.

Your online business is just that: a business that, regardless of its mission, based on technology. Effective Web performance relies on these two forces being in balance. The business cannot be successful without a sound and tuned online platform, and the technology needed to deliver the online platform cannot exist without the revenue that comes from the business done on that platform.

Effective Web performance relies on prioritizing issues so that they can be done within the business and technology plans. And an effective organization is one that has communicated (there’s that word again) what those plans are. Everyone needs to understand that the business makes decisions that effect technology and vice-versa. And that if these decisions are made in isolation, the whole organization will either implode or explode.

Takeaway

Effective Web performance is hard work. It takes a committed organization that understands that running an online business requires that everyone have access to the information they need, collected in a meaningful way, to meet the goals that everyone has agreed to.