Category: Mobile Performance

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.

Effective Web Performance – Will A CDN Really Solve The Problem? – UPDATED!!!!

Content Delivery Networks (CDNs) have been available for over a decade, with companies leaning on these distributed networks to accelerate the delivery of their content, absorb the load of the peak traffic periods, and help deal with the problem of geography. During my career I have helped companies assess and evaluate CDN solutions so that they understood the performance improvement benefit they would receive for the money they were spending.

But a something bothered me during these evaluations. I felt that companies were rushing into the decision because it was the “right” thing to do, that their site could only get faster if they used a CDN. This rush often left question unasked and unanswered.

In this post, I want to provide 4 questions that you should ask before deploying a CDN, questions that will help you ensure that a CDN is the performance improvement solution you need right now.

Is the performance issues due to slow application components?

If the performance issue can be tracked down to application elements, then a CDN is likely not the immediate starting point for you and your team. If generating dynamic content or database lookups are causing the performance issue, this is on you, in your datacenter.

CDNs do not make slow applications run faster; CDNs move bits to customers faster more efficiently.

[UPDATE: There are now CDN solutions that can move processing to the Edge (see Akamai Edgeworkers)]

How are we measuring page response times?

If you are measuring response times using the load time of the entire page, then you may be inflating your response times by including all of the third-party content that has been included. You may want to set up parallel measurements that allow you to compare the full page with a page measurement that only includes the content you are directly responsible for managing. If you find that third-party content is slowing down your pages, then a CDN can’t help you.

Full page load times only give you one performance perspective. Modern performance measurement teams need to understand how long it takes for a page to be ready and usable for the customer – the perceived rendering or page ready time. What you could discover is that customers can do 90% of what they want on your page well before all of the content fully loads. If this is true, than the perceived load time for your company to determine that a CDN isn’t necessary right now.

[UPDATE: Google’s Web Vitals metrics are an example of how far the industry has evolved since I wrote this post a decade ago. As well, ensure that your organization does not have tunnel vision on a single performance metric!]

Have we done everything to optimize our own performance?

Often companies choose the easy way (CDN) to solve a hard problem (improve performance). Unfortunately, the easy way can be more expensive than taking the time to design pages and content that ensure long-term and sustainable performance. A CDN could mask a bad design until it slows down so much that even the CDN can no longer help.

Measure your page and challenge the devops team to tweak the exiting design until they don’t think they can get any more performance out of it. Then, during your CDN evaluations, set up measurements that compare the performance of origin and CDN delivered pages. You might find that making the pages as fast as you possibly can before purchasing the services of a CDN make the difference between the origin and CDN times less dramatic than they would have been before optimization.

[UPDATE: I have been doing web performance for 23 years and organizations are still challenged with the design and implementation of performant web applications before they reach the CDN. If the median TTFB for key pages is greater than 500ms, start there.]

Can we effectively estimate if the CDN cost will be offset by an increase in revenue?

CDNs don’t come cheap, so choosing to deploy a CDN better pay for itself over time. Challenge the CDNs you are evaluating to present you with ROI calculations that show how their service more than pays for itself and case studies (or customers) that prove that the cost of the CDN was offset by a business metric that can be easily tracked.

Summary

Don’t misunderstand the questions I am posing here: I am still a strong advocate for the use of CDNs. However, the days of companies simply purchasing the services of a CDN because it’s the “right thing to do” are long over.

As companies evolve their perspective on web and mobile performance, they need to ensure they have done everything they can to make their own applications faster. Once the hard work of tuning and optimization is complete, the process of choosing a CDN must include deeper, more probing questions about the performance and business benefits that come along with the service.

Performance Trends for ???? – Smarter Systems

IF-repair by Yo Mostro (Flickr)

Most of the trending items that I have discussed in the last two weeks are things that can be done today, problems that we are aware of and know need to be resolved. One item on my trend list, the appearance of smarter performance measurement systems, is something the WPO industry may have to wait a few years to appear.

A smarter performance measurement system is one that can learn what, when, and from where items need to be monitored by analyzing the behavior of your customers/employees and your systems. A hypothetical scenario of a smarter performance measurement system at work would be in the connection between RUM and synthetic monitoring. All of the professionals in WPO claim that these must be used together, but the actual configuration relies on humans to deliver the advantages that come from these systems. If RUM/analytics know where your customers are, what they do, and when they do it, then why can’t these same systems deploy (maybe even create and deploy!) synthetic tests to those regions automatically to capture detailed diagnostic data?

Why do measurement systems rely on us to manually configure the defaults for measurements? Why can’t we take a survey when we start with a system (and then every month or so after that) that helps the system determine the what/when/where/why/how of data and information we are looking to collect and have the system create a set of test deployment defaults and information displays that match our requirements?

The list of questions goes on, but they don’t have to. Measurement systems have, for too long, been built to rely on expert humans to configure and interpret results. Now we have a chance to step back and ask “If we built a performance measurement system for the a non-expert, what would it look like?”

More data isn’t the goal of performance measurement systems – more information is what we want.

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.

Copyright © 2024 Performance Zen

Theme by Anders NorenUp ↑