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.

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.

I just did a quick experiment to validate my hunch, and it’s true – WP Super Cache can cut your HTML load time in half in your WP deployment. Just check out the GrabPERF Measurement that backs this up.

Posted via email from Newest Industry Express

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.

One of the traditional areas of frustration for Operations and Development teams in the Web world is that their performance, Web performance, is measured from the outside-in.

The resistance of this camp is strong, and they will appear without warning, even from amongst the most enlightened of companies.

How can they be recognized?

You will hear their battle-cry, their mantra, their fundamental belief that their application, their infrastructure is a misunderstood victim. That if they could only get their one idea across, the whole of the company would be enlightened.

The fundamental tenet of this group is simple and short.

How can we manage the Internet?

The obvious fallacy of this argument is clear to any Web performance professional or business analyst: Customers get to our business across the Internet, not via psychic modem. In order to keep close tabs on the experience of our customers, the site, application, code must be measured from the outside-in.

In order to prevent making enemies and perpetuating already ossified corporate silos, take the initiative. Gently steer the discussion in a new direction by making this incredibly vast problem into one everyone in the company can understand. By adding a single word to the initial question, the fearful and reactive perspective can be dramatically shifted to one that could make the members of this camp see the light.

Make the question:

How can we manage for the Internet?

Now the focus of the discussion is now proactive – is there something we are missing that could reduce the problems and/or prevent them from ever happening?

Taking the all-encompassing and awe-inspiring challenge that is the Internet and turning it into a Boy Scout moment may reinvigorate the internal conversation, and give people a sense of purpose. Now they will be galvanized to consider whether everything in their power is being done to prevent performance issues before bits hit the Internet.

Effective Web performance hinges on taking the obvious challenges that face all Web sites, and turning them into solutions that mitigate these challenges as much as possible. So, in the next team meeting, the next time you hear someone say that it’s just the Internet, ask what can still be done to manage the application more effectively for the Internet.

A hallway conversation this morning brought up a very interesting point about the relationship between Web performance measurements and Content Delivery Networks (CDNs). When choosing between a Web performance measurement solution and a CDN, which service should come first?

Companies facing dire and obvious Web performance issues will want immediate results, leading them to fall into the CDN-First camp. Deploying a CDN will have a positive effect on response times, increase user satisfaction, and may even increase customer conversions, in the short term.

In six months, deeper questions may start to be asked. A core question that will need to be answered by CDN-First organizations will be “Are we using the CDN effectively and efficiently?“.

A company that makes the leap to CDN deployment without assessing the overall performance environment of their Web site may be faced with a situation where they can’t tell if they need more, less, or different CDN strategies in order to continue to succeed.

As a result of the buyers remorse that can result from the leap directly to a CDN, I highly recommend the Measurement-First approach when selecting a CDN.

To help you become an advocate for the Measurement-First approach, come to the table during the CDN discussions and ask three questions. The answers will allow your organization to make the best and most appropriate CDN decision.

1. Is the CDN necessary?

In most cases, the answer to this is a resounding yes. But what can happen with a sudden shift to the CDN is that a organization overlooks those things that they can do themselves to gain some initial performance improvements.

Baselining the existing site before deploying a CDN will allow items and elements that need to be improved to be clearly identified. In some cases, an organization can fix some of these on their own to improve performance before investing in a CDN. In other cases, measuring the performance of a site may clearly indicate that third-party content is responsible for the performance issues, which would likely not be fixed by a CDN deployment.

A Measurement-First policy helps clearly identify the geographies that have the worst performance before deploying the CDN. If performance in the US is acceptable, while performance in Europe or Asia-Pacific is intolerable, then the CDN deployment may initially be targeted to respond to the greatest pain first.

Understanding the current performance of your existing site can reduce the cost of the initial deployment and maximize the the long term effectiveness of the deployment.

2. Which CDN is best for us?

For a complex modern Web site, content comes in many different shapes, sizes, and formats. The thing is, so do CDNs. As I’ve discussed before, understanding what the CDNs vying for your business do and do well is as critical as the process of vetting their effectiveness compared to delivering the site yourself. The performance boost given to you site by a CDN may vary by region, leading your team to select one CDN for Europe and another for the Asia-Pacific region.

CDN performance can also vary based on the content you are asking them to accelerate. One CDN may be good at streaming media, while another may be better at static content (JS, CSS, Images, etc.), while yet another is better at accelerating the delivery of dynamic content.

Choose your CDN(s) based on what you need them to deliver. In some cases, one size does not fit all.

3. Is the CDN delivering?

This may look like a question for after the purchase has been completed and the solution deployed, but you will never know if the solution is working effectively unless you have a baseline of your performance before the deployment, and from your origin servers after deployment.

Measuring the performance of the CDNs under all conditions and from all perspectives (Datacenter, Last Mile, and from within the Browser) doesn’t stop with the selection of a CDN(s). It becomes even more critical once the CDN solution(s) is rolled into production in order to ensure that the level of service that was promised during the sales cycle is delivered once you become a customer.

Constantly validate the performance of the CDN-accelerated site with the performance of the non-accelerated origin site. Have regular meetings with, and channels of communication into, your CDN(s) to discuss not only existing performance, but how changes you and/or the CDN provider are planning may affect performance in the future.

Takeaway

CDNs are a critical component for any Web business that wants to scale and deliver services to a national or global audience. But selecting a CDN should come after you have a very strong understanding of the current performance of your own Web site.

After you have measured and identified the items you can do to improve your own performance, your team will have greater insight into the areas of your site where the services of a CDN(s) can have the greatest impact.

The Measurement-First approach to selecting a CDN will ensure that you select a set of services that exactly meets the unique performance challenges of your site.

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.

It’s a rare Web site these days that hosts all of its own content. From the smallest blog to the largest retailer, Web sites farm out their images, streams, and pages to CDNs, and absorb feeds, ads, and data streams from any number of outside providers.

Effective Web performance demands that a site take responsibility for the entire site, not just the parts under direct local management. Why? Because customers see a problem with your site, not with a provider.

How can the performance all of the third-party content on a site be managed? Using the exactly the same strategies already place to manage the performance of local content.

Measure from the outside-in

Customers come from the Internet. That measuring the performance of a site from the perspective of visitors is being mentioned here should not be a surprise. Critical to this part of managing third-parties is the ability to see into the page and determine if there are performance issues requesting and transmitting data from third-parties.

In the first article of this series, I detailed a number of approaches to actively gathering performance data. This method, whether from the datacenter or the last mile, will provide the early warning signs that there is an issue with a third-party, and feeding this data into the performance issue management plan.

Measure from inside the browser

The network and application performance of a third-party page component is just the start of the process, as this is what it takes to get the object to the browser. But what if this object then launches a number of actions, or starts to render on the screen. This may lead to a whole different range of issues that are a blind spot when analyzing Web performance.

Measuring the performance of discrete page elements from within the visitors browser will provide deeper insight into what effects the customer sees and which third-parties will need to be approached in order to improve the overall Web performance of the site.

Have clear and useful SLOs and SLAs

Service level objectives and service level agreements are often thrown about whenever there is the suspicion that there is a Web performance issue. Using these documents and frameworks as a club to beat up partners with is counter-productive.

SLOs and SLAs should clearly detail:

• the performance expectations of the Web site owner
• the performance and delivery capabilities of the third-party provider

Guess what? Arriving at this in a way that doesn’t lead to resentment and mistrust on both sides requires open and honest discussion.

Share data

If Web site owners and third-parties are going to work together to ensure the most effective Web performance strategy possible, then data must flow freely. Vendors will need access to the same data that Web site owners have (and vice versa) in order to ensure that if an issue is detected, everyone can examine all of the available data, and solve the problem quickly.

Communication

A recurring and critical theme when establishing a culture of effective Web performance is communication. When working with third-parties, this is even more critical, as the performance culture of one organization may be completely different from another. The Web site owner may have one site of criteria that determines a Web performance issue, while the vendor has another, and unless these are understood, problems will occur.

Clear communication paths must be baked into the SLA. Named contacts or contact paths will be there, as will expected response times for inbound requests, and escalation procedures.

When there is a performance issue, both sides will need to be very clear about how each other will respond.

Takeaways

Third-party content on Web sites is a fact. It shouldn’t be a headache. Effective Web performance measurement strategies, shared sources of Web performance data, and clearly understood paths and methods of communication will make using third-party content less stress-inducing to everyone.

A quote from Avinash Kaushik (Occam’s Razor and @avinashkaushik) to start this post.

I have a 10/90 rule . If your budget is $100 then spend $10 on tools and professional services to implement them, and spend $90 on hiring people to analyze data you collect on your website.

The web is quite complex, you are going to access multiple sources of data, you are going to have to do a lot of leg work. Blood, sweat and tears. You don’t just need tools for that (remember 85% of the data you get from any tool, free or paid is essentially the same). You need people!

Hire the best people you can find, tools will never be a limitation for them.

from This I Believe [A Manifesto for Web Marketers & Analysts]

Staring at this as I sipped my coffee stopped me dead.

Beside me I have two full pages of notes on what makes up the Web performance culture of company, and here is one of the most succinct points summed up for me in two short paragraphs.

Web performance is not just about tools and methodologies. Effective Web performance requires dedicated and trained human resources. And those people need to be able to work in a culture that values and understands the importance of Web performance to the business. Without a culture of Web performance, any tool, technology, and methodology purchased to make things better is useless.

In a previous post I touched on the question of whether an organization sees Web performance as a technology or business issue. Answering this question is key to understanding a company’s perspective on Web performance issues.

Start by asking Who is responsible for Web performance? at a company. Is there a cross-functional team that meets regularly to discuss current performance, long-term trends, the competitive landscape, effects on customer experience, and how performance concerns are shaping and guiding upcoming development efforts?

Or is Web performance a set of anonymous charts and tables that have no context ,originating from the inscrutable measurement system, bundled up into an executive report by an unnamed staff member for a once a month meeting?

Most companies understand Web performance is crucial. They understand it affects the bottom line and customer experience. They understand all of the ideas and concepts of Web performance. But like the proverbial horse and water, they don’t drink from the stream in front of them. They don’t drink because they are too busy watching for cougars, wolverines, and poachers. They have too much going on to make Web performance a priority.

Part of developing a strong culture of Web performance is creating a business culture that is customer-centric. When a company turns their perspective around and makes delighting the customer a part of everything they do, the customer experience on the Web becomes a critical component of the culture.

The key to making Web performance a part of a customer-centric culture is to shift Web performance discussions from the abstract (full of numbers and charts representing the potential of Web performance to affect customers) to the real (effect of Web performance on towns and cities and people and the bottom line). Attaching a name, a place, or a value to every number on a Web performance chart makes it easier for people in an organization to absorb the effect it has on them as an employee.

Moving the discussion about Web performance from the testing lab and NOC to the breakroom and the hallway takes a greater effort. It starts by making Web performance data available to all, not just those who are tasked with monitoring it.

A culture of Web performance means that the $90 you spent on people is supplemented by a team of avid amateurs who notice changes and trends that may slip through the cracks. These amateurs are encouraged to participate in Web performance discussions, where the experts are encouraged to listen then contribute.

Why listen to avid amateurs? In many cases, they are the people who work directly with customers and use the products on a daily basis. Their feedback comes from real experience, set alongside abstract values. Once a measurement has a story, it makes it easier to understand the problem.

An example of the success of amateurs is Wikipedia. A population of amateur contributors, as well as a core of experts in certain fields, have ensured that this is a useful resource. A Web performance culture full of avid amateurs allows comments and stories to flow from the customer-centric parts of an organization into the technology and business parts of the organization. These stories and inputs make the Web performance more real, and make a chart in a report more important.

A culture of Web performance is one that is adopted by an entire company. It is a way of examining the reality of a site in a way that is customer-centric and customer-driven. A strong Web performance culture absorbs information from many sources, and filters the data through a customer filter, and makes every measurement count.

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.