Tag: web performance

Web Caching and Old Age

In 2002, I was invited to speak at an IBM conference in San Francisco. When it came time to give my presentation, no one showed up.

I had forgotten about it until I was perusing the Wayback Machine and found the PDF of my old presentation.

The interesting thing is that the discussion in this doc is still relevant, even though the web is a very different beast than it was in 2002. Caching headers and their deployment have not changed much since they were introduced.

And there are still entities out there who get them wrong.


If you like ancient web docs, check out what webperformance.org looked like in 2007. [Courtesy of the Wayback Machine]

Core Web Vitals and Web Performance Strategy: A Reality Check

Google’s Core Web Vitals initiative has become a larger part of discussions that we have with customers as they begin setting new performance KPIs for 2021-2022. These conversations center on the values generated by Lighthouse, WebPageTest, and Performance Insights testing, as well as the cumulative data collected by CrUX and Akamai mPulse and how to use the collected information to “improve” these numbers.

Google has delayed the implementation of Core Web Vitals into the Page Rank system twice. The initial rollout was scheduled for 2020, but that was delayed as the initial disruption caused by the pandemic saw many sites halt all innovation and improvement efforts until the challenges of a remote work environment could be overcome. The next target date was set for May 2021, but that has been pushed back to June 2021, with a phase-in period that will last until August 2021

Why the emphasis on improving the Core Web Vitals values? The simple reason is that these values will now be used as a factor in the Google Page Rank algorithm. Any input that modifies an organization’s SEO efforts immediately draws a great deal of attention as these rankings can have a measurable effect on revenue and engagement, depending on the customer.

While conversations may start with the simple request from customers for guidance around what they can do to improve their Core Web Vitals metrics, what may be missed in these conversations is a discussion of the wider context of what the Core Web Vitals metrics represent.

The best place is to define what the Core Web Vitals are (done by Google) and how the data is collected. The criteria for gathering Core Web Vitals in mPulse is:

Visitors who engage with the site and generate Page View or SPA Hard pages and are using recent versions of Chromium-based browsers.

However, there is a separate definition, the one that affects the Page Rank algorithm. For Page Rank data, the collection criteria gets a substantial refinement:

Visitors who engage with the site and generate Page View or SPA Hard pages who (it is assumed) originated from search engine results (preferably generated by Google) and are using the Chrome and Chrome Mobile browsers.

There are a number of caveats in both those statements! When described this way, customers may start to ask how relevant these metrics are for driving real-world performance initiatives and whether improving Core Web Vitals metrics will actually drive improvement in business KPIs like conversion, engagement, and revenue.

During conversations with customer, it is also critical to highlight the notable omissions in the collection of Core Web Vitals metrics. Some of these may cause customers to be even more cautious about applying this data.

  • No Data from WebKit Browsers. None of the browsers based on Webkit (Safari, Mobile Safari, Mobile Safari WebView) collect Cumulative Layout Shift or Largest Contentful Paint values. Recent updates have allowed for the collection of First Contentful Paint, but that is not one of the metrics used in Core Web Vitals. The argument can be made that Safari and Mobile Safari already deliver highly optimized web experiences, but not providing insight into a significant (if not dominant) user population will leave organizations wondering what global performance metrics (i.e., metrics collected by all browser families) they can use to represent and track the experience for all visitors.
  • Limitations in CrUX Data Collection. The data that Google collects for CrUX reporting only originates from Chrome and Chrome Mobile browsers. So, even though Chromium-based browsers, such as Edge and Opera, currently collect Core Web Vitals data, it is not used by Google in Page Rank. This narrow focus may further erode the focus on Core Web Vitals in organizations where Chrome and Chrome Mobile are only one part of a complex browser environment.
  • Performance Delta between Mobile Safari and Chrome Mobile. With only very limited exceptions, Mobile Safari substantially outperforms Chrome Mobile in standard performance measurement metrics (Time to Visually Ready, Page Load, etc.). This forces organizations to focus on optimizing Chrome Mobile performance, which is substantially more challenging due to the diversity in the Android device and OS population. As well, without a proven business reason, getting customers to update their mobile performance experience based on Core Web Vitals data could become challenging once this exception is realized.
  • Exclusion of SPA Soft Navigations. Up until recently, none of the Core Web Vitals metrics were captured for SPA Soft Navigations (see below for changes to Cumulative Layout Shift). This is understandable as the focus for Google is the performance of pages originating from Google Search Results, and navigating from the results will not generate a SPA Soft navigation. However, the performance and experience advantages of SPA Soft Navigations for visitors is almost completely lost to Core Web Vitals.
  • Current Lack of Clear Links Between Core Web Vitals and Business KPIs. Google has been emphasizing the Core Web Vitals as the new the new metrics that companies should use to guide performance decisions. However, there has yet to be much (or any) evidence that can be used to show organizations that improving these metrics leads to increased revenue, conversions, or engagement. Without quantifiable results that link these new performance KPIs to improvements in business KPIs, there may be hesitancy to drive efforts to improve these metrics.

Google is, however, listening to feedback on the collection of Core Web Vitals. Already there have been changes to the Cumulative Layout Shift (CLS) collection methodology that allow it to more accurately reflect long-running pages and SPA sites. This does lead to some optimism that the collection of Core Web Vitals data may evolve over time so that it includes a far broader subset of browsers and customer experiences, reflecting the true reality and complexity of customer interactions on the modern web application.

Exposing the Core Web Vitals metrics to a wider performance audience will lead to customer questions about web performance professionals are using this information to shape performance strategies. Overall, the recommendation thus far is to approach this data with caution and emphasize the current focus these metrics have (affecting Page Rank results), the limitations that exist in the data collection (limited browser support, lack of SPA Soft Navigations, mobile data only from Android), and the lack of substantial verification that improving Core Web Vitals has a quantifiable positive effect on business KPIs.

The Performance Implications of Android Dominance

When working with customers in Europe or who serve their data in the US and Europe, I am stunned when they ask why their performance is so much slower in certain European countries compared to the US.

Glimpsing at some publicly available stats (thank you Statcounter!), the reason is clear: Android is the dominant Mobile platform in Europe.

Mobile OS Breakdown – Europe – March 2021 to March 2022

This doesn’t hold true everywhere in Europe – in the UK (yes, it is still in Europe!), Android and iOS have nearly equal Mobile device market share.

Mobile OS Breakdown – UK – March 2021 to March 2022

But in Germany, the divide is vast, with Android clearly dominating the playing field.

Mobile OS Breakdown – Germany – March 2021 to March 2022

But there is yet another divide that is greater than even the Android/iOS split – the Android version difference. Depending on the country, your performance could be dependent entirely upon the versions of Android that the visitors use.

Starting with Germany in Q1 2022, Android usage is dominated by the three latest OS versions: 10, 11, and 12.

Android OS Breakdown – Germany – 2022-01-17 to 2022-03-27

But in countries like Spain and France, Android/9 is still a prevalent OS. This version of Android runs on much older hardware and is more likely to experience degraded performance compared to those running 11 or 12.

Android OS Breakdown – Spain – 2022-01-17 to 2022-03-27
Android OS Breakdown – France – 2022-01-17 to 2022-03-27

For teams trying to design performant web sites, this is a critical piece of information. While Mobile is the dominant platform, sites need to be designed to deliver excellent user experiences for all visitors. And in Europe, this means Android users.

What can you do?

  • Focus on rendering – Get your critical content and functionality on the page as quickly as possible. Items that are secondary (ads, tracking, marketing, etc.) can be delayed
  • Reduce your JS as much as possible – Older Android versions struggle with hardware limitations, so reducing the upfront JS processing will be critical
  • Optimize your images – Sounds simple enough, but using an image management service that provides the right image for the device that is viewing the content will make your site device appropriate

And, most importantly, use an Android device. If you make your development team use Android for a week, they might get the message that they need to do more to reach into this neglected Mobile population.


If you’re a browser geek like I am, check out this post I wrote in 2009 about the browser stats. The world is a very different place now.

Real User Measurement – A tool for the whole business

The latest trend A key tool in web performance measurement is the drive to implement the use of Real User Measurement (RUM) in a web performance measurement strategy. As someone who cut their teeth on synthetic measurements using distributed robots and repeatable scripts, it took me a long time to see the light of RUM, but I am now a complete convert – I understand that the richness and completeness of RUM provides data that I was blocked from seeing with synthetic data.

[UPDATE: I work for Akamai focusing on the mPulse RUM tool.]

The key for organizations is realizing that RUM is complementary to Synthetic Measurements. The two work together when identifying and solving tricky external web performance issues that can be missed by using a single measurement perspective.

The best way to adopt RUM is to use the dimensions already in place to segment and analyze visitors in traditional web analytics tools. The time and effort used in this effort can inform RUM configuration by determining:

  • Unique customer populations – registered users, loyalty program levels, etc
  • Geography
  • Browser and Device
  • Pages and site categories visited
  • Etc.

This information needs to bleed through so that it can be linked directly to the components of the infrastructure and codebase that were used when the customer made their visit. Limiting this data pool to the identification and solving of infrastructure, application, and operations issues isolates the information from a potentially huge population of hungry RUM consumers – the business side of any organization.

The Business users who fed their web analytics data into the setup of RUM need to see the benefit of their efforts. Sharing RUM with the teams that use web analytics and aligning the two strategies, companies can directly tie detailed performance data to existing customer analytics. With this combination, they can begin to truly understand the effects of A/B testing, marketing campaigns, and performance changes on business success and health. But business users need a different language to understand the data that web performance professionals consume so naturally.

I don’t know what the language is, but developing it means taking the data into business teams and seeing how it works for them. What companies will find is that the data used by one group won’t be the same as for the other, but there will be enough shared characteristics to allow the group to share a dialect of performance when speaking to each other.

This new audience presents the challenge of clearly presenting the data in a form that is easily consumed by business teams alongside existing analytics data. Providing yet another tool or interface will not drive adoption. Adoption will be driven be attaching RUM to the multi-billion dollar analytics industry so that the value of these critical metrics is easily understood by and made actionable to the business side of any organization.

So, as the proponents of RUM in web performance, the question we need to ask is not “Should we do this?”, but rather “Why aren’t we doing this already?”.

Performance Trends 2013 – Employees are Customers too

Peter Levine from Andreesen Horowitz wrote an article on The Renaissance of Enterprise Computing yesterday that finally sprouted the seed of an idea that has been dormant at the back of my brain for a few months. While the ideas of enterprise computing and web/mobile performance seem disconnected, they’re not.

When companies begin to rely on outside services (Levine mentions Box, Google Docs, and others in his article) they have given part of their infrastructure over to an outside organization. And, when you do that, this means that any performance hiccups that affect us as consumers can have a very major effect on us as employees.

Even if your company decides to purchase and deploy an enterprise application within your own infrastructure or datacenters, the performance and experience that your employees experience when using it on their desktops or on their mobile devices can affect productivity and effectiveness in the workplace. An unmanaged (read unmonitored) solution can have shut down groups in the company for minutes or hours.

Think of the call-center. No matter the industry you’re in, what increase customer calls: slow performance or a poor experience with the web/mobile application. Now, if your employees rely on a variant of the same web application to answer questions in the call-center, have you actually improved the customer experience and increased employee productivity?

Some considerations when managing, designing, or buying an enterprise application in the coming  year:

  • What do your peers tell you about their experience implementing the solution or using an outside service – has it made employees more effective and efficient?
  • Are employees already using a “workaround” that makes them more effective and efficient? Why aren’t they using the internal or mandated solution?
  • Is performance and experience a driving factor in the lack of adoption of the mandated solution?
  • Do you have clear and insightful performance information that shows when employees are experiencing issues performing critical tasks? Can you clearly understand what the root cause is?
  • Are employees experiencing issues using the application in certain browsers or on certain mobile devices? How quickly can your design or your outside service respond to these issues?
  • Are you reviewing the chosen solution regularly to understand how usage is changing and how this could affect the performance of the application in the future?

Performance issues are not simply affecting the customers you serve. Your own employees use many of the same systems and applications in their day-to-day tasks, so a primary goal of managing these application should be to ensure that the applications deliver performance and experience that encourages employees to use them, no matter whether they are developed in-house or purchased as software or SaaS.

Web Performance Trends 2013 – Third Party Services

Every site has them. Whether they’re for analytics, advertising, customer support, or CDN services, third-party services are here to stay. However, for 2013, I believe that these services will face a level of scrutiny that many have avoided up until now.

Recent performance trends indicate that while web site content has been tested and scaled to meet even the highest levels of traffic, the third-party services that these sites have some to rely on (with a few exceptions) are not yet prepared to handle the largest volumes of traffic that occur when many of their customers experience a peak on the same day.

In 2013, I see web site owners asking their third-party service providers to provide verification that their systems be able to handle the highest volumes of traffic on their busiest days, with an additional amount of overhead – I suggest 20% – available for growth and to absorb “super-spikes”. Customer experience is built on the performance of the entire site, so leaving a one component of site delivery untested (and definitely unmonitored!) leaves companies exposed to brand and reputation degradation as well as performance degradation.

In your own organizations, make 2013 the year you:

  • Implement tight controls over how outside content is deployed and managed
  • Implement tight change control policies that clearly describe the process for adding third-party content to your site, including the measurement of performance impacts
  • Define clear SLAs and SLOs for your third-party content providers, including the performance levels at which their content will be disabled or removed from the site.

When speak to your third-party content and service providers about their plans for 2013, ask them to:

  • Explicitly detail how they handled traffic on their busiest days in 2012, and what they plan to do to effectively handle growth in 2013
  • Clearly demonstrate how they are invested in helping their customers deliver successful mobile sites and apps in 2013
  • Lay out how they will provide more transparent access to system performance metrics and what the goals of their performance strategy for 2013 are.

Take control of your third-party content. Don’t let it control you.

Web Performance Trends for 2013 – Performance Optimization

As we approach the end of 2012, I will be looking at a few trends that will become important in 2013. In a previous post, I identified optimization as an important performance trend to watch. It is one of the items on a performance checklist that companies can directly influence through the design and implementation of their web and mobile sites.

The key to optimization in any organization is to think of objects transmitted to customers, regardless of where they originate, as having a cost to you and to the customer. So, a site that makes $100,000 in a day and transfers 10 million objects to customers has an object-to-revenue ratio of 100. But, if the site is optimized and only 7.5 million objects are transferred to make $100,000, that ratio goes down to 75; and if the reduction in objects causes revenue go up to $150,000, the ratio drops to 50.

This approach is simplistic and does not include the actual cost to deliver each object, which includes costs for bandwidth, CDN services, customer service providers, etc. as well as revenue generated by third-party ads and services you present to customers. The act of balancing the cost of the site (to develop and manage), the performance you measure, the revenue you generate, the experience your customers have, and the reputation of your brand is an ongoing process that must be closely considered every time someone asks, “And if we add this to the site/app…”.

There is no optimal figure for site optimization. But there are some simple rules:

  • Use Sprites where you can. Combing multiple small images into aggregated image maps that you can use CSS to display gives you a double-plus good improvement – fewer objects to download and more text (HTML, JavaScript, and CSS) that can be delivered to visitors in a compressed format
  • Combine JavaScript and CSS files. Listen to your designers – they will likely try to convince that each file needs to be separate for some arcane reason. Listen and then ask if this is the most efficient way to deploy this particular function or formatting. Ask the developer to produce a cost/benefit analysis of doing it their way versus using something that is already in place
  • Control your third-party services. This means having a sane method for managing these services, and shutting them off if necessary. Have every team that is responsible for the site meet to approve (or deny) the addition of new third-party services. And those who want it better come with a strong cost/benefit analysis.

Optimization is the act of making the sites you create as effective and efficient as the business you run. No matter how “low” the cost to operate a web site is, each object on a site can cost the company more money than it is worth in revenue. And if that object slows the site down, it could turn a profitable transaction into a lost customer.

Web Performance – At What Cost? Trends for 2013

image courtesy of Corey Seeman – http://www.flickr.com/photos/cseeman/

As we moved through the traditional start of the holiday shopping season (Thanksgiving / Black Friday / Cyber Monday), it is clear that most sites were prepared for what was coming. No big names went down, no performance slowdowns rose to the headlines, and online revenue – both web and mobile – appears to have increased over 2011.

But when you these companies do their year-end review, they need to take a step back and ask: “Could we have done it better?”

While performance events were few and far between (if they occurred at all), companies will need to examine the cost of scaling their sites for performance. When planning for the peak performance period, companies will need to asses whether simply scaling-up to handle increased traffic and sales could have been managed more effectively, by implementing sites that were not only fast, but  also efficient.

Joshua Bixby (here) noted that web page size has increased 20% in the last 6 months, an indication that efficiency is not always at the top of mind when new web content is presented to visitors. In order to deliver ever more complex web content, companies are spending more on services such as CDNs and cloud services to deliver their own content, while incorporating ever increasing numbers of third-party items into their pages to supply additional content and services (analytics, performance, customer service, Help Desk, and many more) that they have outsourced.

Increasing page size, outside acceleration and cloud services, and third-party services – a potent mix that companies need to asses critically, with an eye to understanding what all of these mean for the performance experienced by their visitors and customers. Add in the increasing importance of the mobile internet, with its variable connection speeds and service quality, and things become even more interesting.

In 2013, I see companies assessing these three trends with a focus on making sites perform the same (or better!) at the same (or lower!) cost than they did in 2012.
Over the next 12 months, I will be watching the performance industry news to see if those companies that have been successful at making their sites perform under the heaviest loads increasingly focus not just on speed and availability, but on efficient delivery of their entire site at a lower cost with the best user experience possible.

The key strategics questions that online businesses will be asking in 2013 will be:

  • Have we optimized our content? This does not mean make it faster, this means make it better and more efficient. It is almost absurdly easy to make a big, inefficient site fast, but it is harder to step back and “edit” the site in a way that you deliver the same content with less work – think Chevy Volt, not Cadillac Escalade.
  • Are we in control of our third-party services? Managing what services get placed on your site is only the first step. Understanding where the content you have added comes from and whether it is optimized for the heaviest shared loads will also become important checklist items for companies.
  • Can we deliver the design and functionality our customers want at a lower cost? This is the hardest one to be successful at, as each company is different. But Devops teams should be prepared to be accountable for not just cool, but also for the cost of creating, deploying, and managing a site.

The Rule of Thirds: The Web Performance Analyst

Blurry Man - Brian Auer - http://www.flickr.com/photos/brianauer/2929494868/

Recently, there has been a big push for the Dev/Ops culture, an integrated blending of development and operations who work closely together to ensure that poor performing web and mobile applications don’t make it out the door. They have become the rockstars of the conference circuit and the employment boards.

I fit into neither of these categories. I have never run anything more than a couple of linux servers with Apache and MySQL. I write code because I’m curious, not because I’m good at it – in fact, I write the worst code in the world and I am willing to prove it!

I am a member of a web and mobile performance culture that is language and platform independent, to use some buzzwords.

I am a web and mobile performance consultant and analyst.

I can take apart reams of data to find statistical patterns and anomalies. I believe that averages are evil, and have believed this for more than a decade. I have been using frequency and percentile distributions for almost as long and watched as the industry finally caught up.

I can link the business issue that faces your company with the technical concerns you are facing and help guide you to the middle ground where performance and the balance sheet are in careful equilibrium.

I don’t care what you write your code in. I don’t care what you run it on. Now, don’t get me wrong: I respect and admire the Dev/Ops folks I have met and know. I am just not in their tribe.

HTTP Compression – Have you checked ALL your browsers?

Apache has been my web server of choice for more than a decade. It was one of the first things I learned to compile and manage properly on linux, so I have a great affinity for it. However, there are still a few gotchas that are out there that make me grateful that I still know my way around the httpd.conf file.

HTTP compression is something I have advocated for a long time (just Googled my name and compression – I wrote some of that stuff?) as just basic common sense.
Make Stuff Smaller. Go Faster. Cost Less Bandwidth. Lower CDN Charges. [Ok, I can’t be sure of the last one.]

But, browsers haven’t always played nice. At least up until about 2008. After then, I can be pretty safe in saying that even the most brain-damaged web and mobile browsers could handle pretty much any compressed content we threw at them.

Oh, Apache! But where were you? There is an old rule that is still out there, buried deep in the httpd.conf file that can shoot you. I actually caught it yesterday when looking at a site using IE8 and Firefox 8 measurement agents at work. Firefox was about 570K while IE was nearly 980K. Turns out that server was not compressing CSS and JS files sent to IE due to this little gem:

 BrowserMatch \bMSIE !no-gzip gzip-only-text/html

This was in response to some issues with HTTP Compression in IE 5 and early versions of IE6 – remember them? – and was appropriate then. Guess what? If you still have this buried in your Apache configuration (or any web server or hardware device that does compression for you), break out the chisels: it’s likely your httpd.conf file hasn’t been touched since the stone age.

Take. It. Out. NOW!

Your site shouldn’t see traffic from any browsers that don’t support compression (unless they’re robots and then, oh well!) so having rules that might accidentally deny compression might cause troubles. Turn the old security ACL rule around for HTTP compression:

Allow everything, then explicitly disable compression.

That should help prevent any accidents. Or higher bandwidth bills due to IE traffic.

Copyright © 2024 Performance Zen

Theme by Anders NorenUp ↑