Performance Zen

Category: Web Performance

  • Customer Experience: Standing on your own four legs

    Tables. They’re pretty ubiquitous. You might even be using one right now (although in the modern mobile world, you may not. LAMP POST!).

    A strong business is like a table, supported by four legs.

    • The Business. The reason that resources and people have been gathered together. There is a vision of what the group wants to do and what success looks like.
    • The Design. Don’t think style; think Design/Build. This is where the group takes the business idea and determines how they will make it happen, where the stores will be, what a datacenter looks like, who they will partner with.
    • The Presentation. How the Business and the Design are shown to people. How the shelves are stocked, the landing pages look, the advertising is placed, how the business looks to potential customers.
    • The Delivery. This is the critical part of how the business uses the systems they have designed and the presentation they have crafted to deliver something of value to the potential customer.

    Without any one of these, an organization will fail to meet the most critical goal it has set to be successful: an experience that turns a visitor or browser into a customer.

    All the Business and MBA grads in the audience are yawning, and slapping their Venti non-fat, no-whip, decaf soy lattés down on the table. This message isn’t for you. Well, it is, but you can stand up and give your chair to one of the people behind you.

    Now that I have Dev, QA, and Operations sitting with me (remember, the Business guys are still in the back of the room, tapping away on their Blackberries), tell me what you think of this conceptual table. How does the Table of Customer Experience relate to you?

    Ok, put down the Red Bulls and Monsters and listen: Everything that Dev, QA, or Operations does has an effect on the experience (negative or positive) of the potential customer. If one of the table legs is broken (or even shorter than the others), the rippling shockwaves will eventually affect the entire operation.

    So, if I were to ask the member so of your organization how their daily activities supported the online application in each of these four areas, do you think they could answer?

    Grab a white board. This is going to be a long day.

    Picture courtesy of sashafatcat

  • The Nomenclature Problem (or "What's in a name?")

    Someone walks into your store. They say hello, poke around the racks, ask a few questions. Then they walk out.

    Now, if I asked you, how would you describe that person?
    Customer? Visitor? Yes?

    I have been asking this question in preparation for some session for a group of motivated partners and employees in Singapore and Bangalore. As I prepare the presenter slides (not the dense textbook slides the participants get – thank you Garr Reynolds!), I keep correcting the words, typing customer to describe a visitor who is not.

    When you and your teams discuss deep topics like conversion rates and transaction abandonment (WAKE UP! NO MEDITATION!) does the group classify non-buying, real people as  customers or visitors?

    The label customer should be reserved for those visitors who complete the transaction and provide the revenue/information to the company whose online application they are interacting with. This means that the customer is the visitor who has bought into the entire online application experience.

    A visitor becomes a customer only when they are happy with:

    • The Business
    • The Design
    • The Presentation
    • The Delivery

    Where in the four areas has your application let the company down before?
    If you asked a random visitor why they haven’t become a customer, what do you think the typical answer would be right now? Next week? A year from now?
    Then ask your parents (or your spouse, if you’re brave) to use your application. You must show incredible restraint during this exercise (I suggest a remote operated camera and 6,000 miles of separation) to stop yourself from leaping in and telling them what to do,  shaping their experience and guiding them to your expected and desired outcome.

    Can they do it? Would your parents or spouse become a customer?
    When you look at your online applications tomorrow, use beginners mind to truly look at what you are doing in the four key areas. If you find yourself shaking your head and saying that this doesn’t make sense, put yourself in the visitors’ shoes.
    You may ask yourself if the application you provide to support your business is truly improving the visitor experience.  What you have a strong chance of finding is that your application is designed for customers at the expense of visitors.

    When a visitor doesn’t complete the tasks you defined for them to reach the goal of becoming one of your customers, what do you call them?

    And do you know what to do next?

  • Overcoming the Momentum of Traditional Web Performance

    When I asked if traditional Web performance still mattered, the post generated a flurry of comments and questions that I haven’t seen in in a long time.

    After some reflection and discussions with people who have been tackling this problem for longer than I have, the answer is yes, it does matter. However, synthetic Web performance measurement will not matter the way it does now. The synthetic approach will decrease in importance within fully evolved companies, organizations that have strong cultures of Web performance.

    In these organizations, the questions change as the approach becomes foundational and integral to the operation of the online business. Ways of examining competition and performance improvement evolve, and the focus moves – from the perspective of We have a problem to one of of Our customers / visitors have a problem.

    The shift is fundamental and critical. For as long as I have been in the business, synthetic measurements have served as a proxy for customer experience. But unless you get into the browser, out to where and how the customer uses the online application, the margin of error will remain large.

    The customer is not an operational issue. There is no technical fix for perceived performance.

    There is no easy solution for evolving the experience of performance.

  • Does Traditional Web Performance Still Matter?

    More than two years ago, I created a post that was frank in its statement that Web performance measurement isn’t just a technology issue, it’s a business issue.

    As we approach 2012, a new question is driving how I examine the world I work in: Does traditional Web performance still matter?

    Seems drastic and will raise the ire of more than a few folks I know, but it is a valid point of discussion. The entire Web performance industry needs to look around and determine how they got where they are and what the world will look like in 5 years.

    The “Web” as it was defined when I started in the industry was simple – browser and page driven, with a growing focus on delivering services to visitors. Now, there is no definition of “Web” that can encompass everything that can be used when talking to companies. And in many cases, if asked, companies may not fully understand how customers interact with their online properties on a daily basis.

    I used to be able to say what determined fast Web performance. Now, the simple answer is irrelevant, replaced with the reality of “It depends”. Fast is completely dependent on what is being done, when and where is it happening, how things being done, and who is driving the way it is is done.

    I am issuing a challenge to the entire Web performance industry: Step back and and ask yourself if we are asking and answering the right questions for the companies we work with.

    If we don’t find out now, in 5 years it won’t matter.

  • Pain at Every Level – Web Performance in the Organization

    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.

  • Black Friday 2011

    Black Friday 2010 is upon us.

    Now, what are you doing to get your Web site ready for Black Friday 2011?

    While this may be a shocking slap in the face, it is a very realistic one. If you take what happened today, and what you think may happen over the next 4 weeks, what will your organization really need to be ready for next year – same time, same place?

    You were thinking about that as you got ready for this year, right?

    Well, it’s never too early to start planning. Here are some items you should be putting on your January 1 2011 wish-list.

    • Better Web monitoring. What did you get caught without any insight into this year? Where do you need to get more information? Inside or outside the firewall? Third-party components? What surprised you this year?
    • Earlier load testing. Is it less stressful to test your capacity and focus your optimization efforts in Q1 2011 or in October 2011? The advanced customers we work with start running their load tests in April, not September. How much change can you make to your systems by the time you discover a problem in September?
    • Real-world inputs and projected growth. When you take your analytics data and project your growth for next year, are you factoring in macro-economic inputs? No, I’m not an economist, but if the economy isn’t projected to grow as fast, aim your projected growth for the middle of the range for testing, not for the top-end.
    • Test capacity to the maximum. No, this is not mutually exclusive of the previous item. When you test your capacity, you want to make sure that you know exactly how much growth it can take. Even if growth is not projected to break it this year (and you can prove this with load testing), how about in 2012?
    • Mobile Commerce Readiness. Mobile is the latest buzzword. But do you have a real plan to handle a rush of people checking your prices from other stores on Black Friday? And if they want to buy it right there, can they? Mobile is not a separate silo; All sales channels make you money, so stop treating them differently. If you are going mobile, do it with a plan that scales with sales.

    Whatever you do, don’t rest on your laurels (or bed of broken glass, depending on how your day went). Have a plan. Write it down. Set some deadlines.

    Give yourself a head start.

    Black Friday 2011 is only 364 days away.

  • Web Performance Concepts: Customer Anywhere

    Companies are beginning to fully grasp the need to measure performance from all perspectives: backbone, last mile, mobile, etc. But this need is often driven by the operational perspective – “We need to know how our application/app is doing from all perspectives”.

    While this is admirable, and better than not measuring at all, turning this perspective around will provide companies with a whole new perspective. Measure from all perspectives not just because you can, but because your customers demand performance from all perspectives.

    The modern company needs to always keep in mind the concept of Customer Anywhere. The desire to visit your site, check a reservation, compare prices, produce coupons can now occur at the customer’s whim. Smartphones and mobile broadband have freed customers from the wires for the first time.
    If I want to shop poolside, I want your site to be as fast over a mobile connection on my Android as it is on my WiFi iPad as it is on my Alienware laptop on ethernet. I don’t care what the excuse is: If it’s not fast, it’s not revenue.

    Knowing how a site performs over the wire, in the browser, around the world made “Web” performance a lot harder. The old ways aren’t enough.

    How does your “Web” performance strategy work with Customer Anywhere?

  • The Complexity of Web Performance

    Helping a colleague this week, we uncovered some odd behavior with a site whose performance he was analyzing. Upon first glance, it was clear that this site had a performance issue – they had HTTP persistence disabled. Immediate red flag in the areas of network overhead and geographic latency.

    Further digging exposed something more sinister. It seems that HTTP persistence was only disabled for browsers with MSIE in the user-agent string. Even if the user-agent string was just MSIE, HTTP persistence was off.

    The customer was very forthcoming and sent us their standard httpd.conf file. This showed no sign of the standard (and frustrating) global disabling of persistence for Internet Explorer.

    Finally, it came to us. The customer had provided a simple network diagram, and there, just before packets hit the Internet, was a Layer 7 firewall. How did we know the Layer 7 firewall was the likely cause? Because this device was also the one that provided compression for the content going out to customers.

    A Layer 7 firewall happily rewrites HTTP headers to reflect the nature of the compressed content (content-length or transfer-encoding: chunked) and to add the gzip flag (accept-encoding:gzip). Since this device was already doing this, it was pretty clear to us that it also had a rule that disabled HTTP persistence for anything with MSIE in the user-agent string.

    This was a fine example of the complexity of the modern Web application infrastructure. In effect, there were two groups with different ideas of how Internet Explorer should be handled at the network layer, and neither of them seems to have talked to the other.

    When you have a Web performance problem, indulge in a thought experiment. Create an imaginary incoming Web request and try to see if you can follow it through all the systems it touches on your system. Put it on a whiteboard, a mindmap, whatever works.

    Then invite the system architects and network engineers in and get them to fill in the gaps.

    No doubt that will lead to the “ah ha!” moment. If nothing else, it’s a good excuse to put pizza on the company card. But I have no doubt that you will walk away with a better understanding of your systems, which will make it easier for you to talk to all the people responsible for keeping your systems running.

    TAKEAWAY: Just because the part of the Web application you work on is working fine, it may be affected by other components that are not tuned or configured for performance. Get to know the entire application at a high level.

  • Compression and the Browser – Who Supports What?

    The title is a question I ask because I hear so many different views and perspectives about HTTP compression from the people I work with, colleagues and customers alike.

    There appears to be no absolute statement about the compression capabilities of all current (or in-use) browsers anywhere on the Web.
    My standard line is: If your customers are using modern browsers, compress all text content — HTML (dynamic and static), CSS, XML, and Javascript. If you find that a subset of your customers have challenges with compression (I suggest using a cross-browser testing tool to determine this before your customers do), write very explicit regular expressions into your Web server or compression device configuration to filter the user-agent string in a targeted, not a global, way.

    For example, last week I was on a call with a customer and they disabled compression for all versions of Internet Explorer 6, as the Windows XP pre-SP2 version (which they say you could not easily identify) did not handle it well. My immediate response (in my head, not out loud) was that if you had customers using Window XP pre-SP2, those machines were likely pwned by the Russian Mob. I find it very odd that an organization would disable HTTP compression for all Internet Explorer 6 visitors for the benefit of a very small number of ancient Windows XP installations.

    Feedback from readers, experts, and browser manufacturers that would allow me to compile a list of compatible browsers, and any known issues or restrictions with browsers, would go a long way to resolving this ongoing debate.

    UPDATE: Aaron Peters pointed me in the direction of BrowserScope which has an extensive (exhaustive?) list of browsers and their capabilities. If you are seeking the final word, this is a good place to start, as it tests real browsers being used by real people in the real world.

    UPDATE – 09/24/2012: I found a site today that was still configured incorrectly. Please, please, check your HTTP Compression settings for ALL browsers your customers use. Including you MOBILE clients.

  • Effective Web Performance: The Wrong 80 Percent

    Steve Souders is the current king of Web performance gurus. His mantra, which is sound and can be borne out by empirical evidence, is that 80% of performance issues occur between the Web server and the Web browser. He offers a fantastically detailed methodology for approaching these issues. But fixing the 80% of performance issues that occur on the front-end of a Web site doesn’t fix the 80% of the problems that occur in the company that created the Web site. Huh? Well, as Inigo Montoya would say, let me explain.

    The front-end of a Web site is the final product of a process, (hopefully) shaped by a vision, developed by a company delivering a service or product. It’s the process, that 80% of Web site development that is not Web site development, that let a Web site with high response times and poor user experience get out the door in the first place.

    Shouldn’t the main concern of any organization be to understand why the process for creating, managing, and measuring Web sites is such that after expending substantial effort and treasure to create a Web site, it has to be fixed because of performance issues detected only after the process is complete?

    Souders’ 80% will fix the immediate problem, and the Web site will end up being measurably faster in a short period of time. The caveat to the technical fix is that unless you can step back and determine how a Web site that needed to be fixed was released in the first place, there is a strong likelihood that the old habits will appear again.

    Yahoo! and Google are organizations that are fanatically focused on performance. So, in some respects, it’s understandable how someone (like Steve Souders) who comes out of a performance culture can see all issues as technical issues. I started out in a technical environment, and when I locked myself in that silo, every Web performance issue had a technical solution.

    I’ve talked about culture and web performance before, but the message bears repeating. A web performance problem can be fixed with a technical solution. But patching the hole in the dike doesn’t stop you from eventually having to look at why the dike got a hole in the first place.

    Solving performance Web problems starts with not tolerating them in the first place. Focusing on solving the technical 80% of Web performance leaves the other 80% of the problem, the culture and processes that originally created the performance issues, untouched.