Alberto Medina's Blog

Common sense is good; enough of it is genius

Archives (page 2 of 2)

Reasoning about Speed

rail

One challenging aspect of web performance is that it is often addressed once it has become a problem already; this can be referred to as a “reactive approach to handling performance”. A reactive approach is challenging because the symptoms of the problem emerge way after they were introduced early on during the initial design/implementation phases of the a project; and it is often very difficult, if not impossible, to change design/implementation decisions that have pervasively percolated through the whole system.

Another challenging aspect is that we are trying to achieve globally-optimal results (i.e. good overall performance), from a collection of local optimization decisions (e.g. defer the evaluation of a JS file, etc).

Performance models are one approach to mitigate these challenges and enable us to reason about performance. The use of performance models during the process of designing and implementing applications provides guidance to our decision making process; they provide a framework for reasoning about how design/implementation decisions affect performance and user experience and to strike the proper tradeoffs at every step along the way.

Another benefit of defining and using performance models is that they provide a Lingua Franca, a common language for teams to talk about performance and ensure that they are all looking at the reality of the app from the same perspective.

Two specific performance models/patterns relevant for designing/implementing websites are: (1) the Response, Animation, Idle Load (RAIL) model; and (2) the Push, Render, Pre-cache, Lazy-load (PRPL) pattern.

The RAIL Performance Model

The RAIL model seeks to capture the four major areas of a web app life cycle; it stands for: Response, Animation, Idle, Load. If we look at them in chronological order, we would read the acronym backwards:

  • Load. We want our initial load and rendering to happen in about one second.
  • Idle. An app is usually idle while waiting for the user to interact; idle time is divided into chunks of fifty ms each, and they offer a great opportunity to squeeze work that the app needs to do.
  • Animation. This part of the model relates to one of the most challenging aspects of the performance of web apps: the need to achieve animations that render at 60fps (frames per second). This means that we have about 16 ms to render one frame; or even less since in reality, browsers have to squeeze other tasks in that time budget, leaving us with an actual budget of  about 10 ms. Check this reference for more detailed information.
  • Response. This responsiveness corresponds to how quickly the app reacts to user interactions; that is, how quickly the app becomes interactive. Research has shown that there is a limit of about 100 ms from when a user interacts with the application (e.g. tap a button, scroll) and when she gets the desired response.

In practical terms, the RAIL model translates into this :

  • Focus on the user; the ultimate goal is to make users happy
  • Respond to users immediately; acknowledge user input in under 100ms.
  • Animate smoothly. When animating or scrolling, produce a frame in under 10ms.
  • Be efficient. Maximize main thread idle time.
  • Load fast (keep users engaged). Deliver interactive content in under 1000ms.

The PRPL Pattern

The acronym PRLP refers to a pattern for structuring and serving Progressive Web Apps (PWAs), with an emphasis on the performance of app delivery and launching. The pattern comprises the following elements:

  • Push critical resources for the initial route.
  • Render initial route.
  • Pre-cache remaining routes.
  • Lazy-load and create remaining routes on demand.

In a nutshell, PRPL seeks to optimize three aspects of the development, launching, and performance of a web app:

  • Minimize the Time-to-Interactive (TTI) metric: especially on first use (regardless of entry point), and on real-world mobile devices
  • Maximize caching efficiency: Simplify app development and deployment

The PRPL pattern is less about specific technologies or techniques that can be used, and more about a mindset and a long-term vision for improving the performance of the mobile web applications. The goal is to keep the PRPL pattern in mind when planning for performance.

So…

If there is one takeaway from this post, is this: web performance is more than technique; it is a mindset. A mindset that should encompass every aspect involved in the development of our products: designers, developers, decision makers. And for that mindset to be effective, we need to be able to reason about performance. Performance models are your tools to do that and harness control of the performance of your sites and apps.

The Cost of Bad Performance

As we discussed before, users have high expectations with respect to the performance of websites; and when those expectations are not met users react in ways that clearly impact the outcome of key business metrics. There have been a variety of studies aimed and showing this reality. For example, a study made by Double Click and published in September, 2016, results like the following were reported.

User expectations

  • 46% of consumers say that waiting for pages to load is what they dislike the most when browsing the mobile web
  • 50% of people expects a page to load in less than 2 seconds
  • About 53% of all mobile visits are abandoned if the page loads in more than 3 seconds

Load times

  • 77% of mobile sites take longer than 10 seconds to load
  • On 3G networks, the average time to load is 19 seconds
  • On 4G networks, the average time to load is 10 seconds

Site structure

  • The average mobile web page is 2.5MB in size!. This implies that the data alone takes 13 seconds to load on a 3G network (first view).
  • The average mobile page makes 214 server requests; some of those take place simultaneously, while others are serialized.
  • About half of all server requests come from ad-related calls

The same study reports results indicating the positive effects of better performance. Specifically, the study found that sites that load in 5 seconds vs. those loading in 19 seconds exhibit:

  • 25% higher ad viewability
  • 70% longer average sessions
  • 35% lower bounce rates
  • 2X greater mobile ad revenue

So…

These results paint a clear picture of the impact of bad performance on our sites: a dramatic loss of users, inability of delivering our content, and serious monetization challenges. I agree, we can’t afford bad performance.

Why Is Attaining Good Performance Hard?

performance-dog

TL;DR attaining good performance is hard because there has been a drastic change on the dominant platform on which users access the web: the Mobile Web, and that change has been out of sync with the techniques and approaches we use to develop applications that run on that platform.

In the previous post, we discussed what is encompassed when we talk about mobile performance. In this post we discuss why is achieving good performance hard?

In a sense, the Mobile Era, took the underlying computing platform of the web “back in time” (sort of). Mobile devices are significantly more limited than their fellow desktops; or we can argue that today’s mobile devices are as powerful as desktops were several years ago. In a sense, we are trying to squeeze today’s software on yesterday’s computers.

The performance and functionality provided by mobile devices are not in sync with the need for resources of the applications that run on them; the access platform became more limited, but the approach used to develop applications to be run on such limited environments has not changed. One of the issues seems to be how to balance Developer eXperience (DX) and User eXperience (UX). Due to the limitations of mobile devices and the unrelenting demand of speed by users, the balance between these objectives should be drawn closer to the UX side of the picture, which means that websites and mobile web applications must be fast.

The challenges that make high performance hard to achieve on mobile devices and networks are two-fold: (1) Mobile-platform Specific; and (2) Website specific.

Mobile-platform Specific

This Section captures the message in this Chrome Dev Summit talk in a nutshell; in that talk Alex Russell discusses the underlying reasons why mobile devices are challenging from three angles influencing performance: mobile-device CPU, memory and storage, and mobile networks. This article, referenced in the talk, is a useful read to gain more insights in this context.

Mobile device CPUs

CPUs on mobile devices are less powerful than desktop CPU; one of the main reasons for this difference is the constraints imposed by heat dissipation, which is an important factor playing a role in the way mobile devices are built. For example, mobile devices do have multiple cores, but the are not used as Symmetric Multiprocessing (SMP) machines; that is, they asymmetric with respect to their capabilities and use frequency: there are some infrequently used, “big” (high-power) cores, and some aggressively used,  “little” (low power), cores. This construction in turn influences the way the software that runs on them operates.

The OS in mobile devices has what is called a Global Task Scheduler, which uses heuristics to control the way in which the asymmetric cores are used:

  • Touch Boosting: the user touching of the screen signals the scheduler to power the big cores in anticipation of the starting an activity or some other kind of user-triggered task
  • Application launching: the launching of an app signals the scheduler to power the big cores, bring up the app, and then send them back to sleep.

Things get tricky because the way in which mobile devices are designed does not correspond to the way the web works. A good “heuristic” in the web scenarios looks more like Link Clicking: when the user clicks on a link, wait until the associated resources are loaded from the network, and then let the user interacts with it. However, in a mobile device, if the big cores are started when the link is touched, the awakening on the big cores will be wasted while waiting for the data to arrive from the network.

Memory and Storage

Memory pressure and the need for smaller memory footprints on mobile devices do not allow for the trading of space for speed in the same way that can be done on desktops.

The physical limitations of mobile devices also influence the way Storage systems are designed and built. For example, due to space constraints, mobile flash storage is constructed using Multi-level Memory Cells (MLC) as opposed to Single-level Cells (SLC, which are faster, but also require more space and are more expensive.

Mobile Networks

There is a dichotomy between the web’s network infrastructure and the mobile infrastructure, which imposes a variety of challenges to mobile web app performance. A study by Radio Up reports:  “[in mobile networks], last-mile delays add 400% to the total of Internet lag time. In other words, the mobile last mile is the major drag on for the mobile web”.

The web runs on top of TCP/IP protocol suite, which is essentially a control system with feedback loops optimized to operate under certain assumptions such as some level of stability on network conditions, and low error rates. Mobile (cellular) networks often violate such assumptions (i.e. high variability of RRR and error conditions). The result is often degraded performance, which implies that, as Ilya Grigorik points out, a 4G user is not actually a 4G user most of the time. The same type of network may mean different things for different user.

The bottom line is this: cellular networks impose a set of challenges on the performance of mobile web apps. This book is an excellent resource to gain more depth in the area of network (including mobile) performance

Website specific: Webpage bloating

The average size of content for a mobile website is 2.2MB; those who argue that there is a web obesity crisis have a point. This graph (from httparchive.org) shows the trend of the overall transfer size for the top sites in the web. And this graph following graph [httparchive.org] shows the trend of JS requests and transfer sizes for the top 1000 websites since 2011 till now.  More details on the state of the art of page weight can be seen here. The reality is that page bloating contributes to loading delays with the consequent degradation of  UX quality. 

A variety of  experimental evidence exists exposing the problem; for example, here are some stats from a Double Click study:

  • The average mobile page makes 214 requests to servers
  • Half of all server requests come from ad-related calls
  • Average mobile page loading time is 19 seconds
  • 77% of mobile sites take 10+ seconds to load

Overall Performance

The takeaway from this post is this: the constraints of the mobile platform, and the prevalence of certain issues in the development of modern websites, are at the root of most of the performance problems being perceived by users. And the call for action is this: in order to make good, high-performant apps in today’s environment, a change is needed in our outlook, our tools, and our priorities. We (developers, platform, frameworks) must strive to develop lean websites.

What is Mobile Performance?

In the previous post we started a thread aimed at advancing our understanding of the fundamentals and challenges of mobile performance. In this post we continue the discussion, asking: what is performance?

Users have high expectations and demands regarding their website experience; we want simplicity and ease of use (don’t make me think), we want safety and security (don’t betray me), and, most importantly, we want speed (don’t make me wait). When websites are not fast, we get grumpy; every user hates slowness. It is true that performance is only one component of the overall user experience, together with appearance, accessibility, content strategy, usability; but it is a very important one. Some even argue that web performance IS user experience; and in some sense it is, because the lack of good performance often cancels out the role of the other UX components.

Since performance is so closely related to user experience, we can’t really think about one without thinking about the other; thinking about them congruently leads to design and implementation decisions at all levels that strike the best balance between User eXperience (UX), Developer eXperience (DX), and Monetization eXperience (MX). Therefore, it is important to: (1) focus on the right performance metrics; those strongly correlated with an improved UX; and (2) design and implement for performance by making deliberate decisions at every step along the way trying to strike balanced tradeoffs between seemingly conflicting goals.

The performance of a web app, as perceived by users, is influenced by both server-side and client-side components. Steve Sounders’ performance golden rule states that 80% of the end-user response time is spent on the frontend; therefore, our focus is mostly on the frontend side of the equation.  In a nutshell, from receiving the HTML code and the associated resources to rendering the corresponding pixels on the screen, the browser goes through the following steps in order

  1. Parse HTML into DOM
  2. Download resources linked from the HTML
  3. Parse CSS into CSSOM
  4. Parse JavaScript
  5. Construct the render tree by combining the DOM with the CSSOM
  6. Layout (calculate the positions and other attributes of all visible elements)
  7. Paint

These steps are executed for every page rendered by the browser, and there are a number of things that can be optimized in order to enhance the performance as perceived by the users:

  • Requests: Optimize the number and size of requests made by the application
  • Connections: Reduce the number of connections needed to load the app; andKeep in mind that number of requests is not the same as number of connections
  • Page weight: Optimize the size of the resources required by our page: HTML, CSS, JS, Images
  • Critical Rendering Path: Prioritize the display of content that relates to the current user action
  • Geography: Reduce the distance between your users and your content by using some kind of Content Delivery Network

In a following post, we will discuss why is so hard to achieve good performance on mobile devices.

Busting my Gender Biases

Biases

Recently I attended an awesome class at Google called Bias Busting. Initially I thought that I would not get anything out of it; after all, I have absolutely no biases whatsoever, right? Not so fast, buddy.

I quickly realized that something in my perception was not quite clear. I felt the need to question the use of personal pronouns. Specifically, I felt friction with the use of them, theirs when referring to singular individuals.  Initially my perception was based on my understanding of the transgender concept and also on my own use of language.

IMG_20171214_081612.jpg

The dictionary definition for the term transgender states: “denotes or relates to a person whose sense of personal identity and gender does not correspond with their birth sex“; and this is compared to the term cisgender, which “denotes or relates to a person whose sense of personal identity and gender corresponds with their birth sex.” I understood the transgender definition as the rightful choice of any person to identify with their inner gender as opposed to the gender that was assigned to them at birth. This makes complete sense to me, and I support it. But for me it also means that a transgender person is not genderless. Therefore, there is still an association of gender in my perception according to their gender identity. And, from a linguistic perspective,  that gender association corresponds to gender-specific language constructs. This is particularly true in my native tongue, Spanish, where every single thing I can refer to has a linguistic gender (i.e. she, he, his, her, etc). This certainly plays a role in the difficulty I experienced referring to individuals by theirs or they.

The other aspect is also related to language. I find it difficult to use plural pronouns when I am referring to individuals; e.g. “Hey, have you seen Alberto? Yes, I saw them.” That kind of language use triggers some sort of short-circuit in my brain. Perhaps if I use it for an extended period of time I will rewire those linguistic neural connections and it will feel better; but at the moment, it is hard.

I expressed these difficulties and received a kind response: don’t worry about it, just apologize when you notice and try to do better next time. The problem with this approach is that people who “suffer from the same things as me” will have to be frequently apologetic when their linguistic constructs make them appear insensitive to the needs of transgender people. But until we agree on another approach I will continue doing my best to adapt to the new uses of familiar linguistic constructs, and apologize when I get it wrong.

In the meantime, I just want to ask honest questions and find out where my perception is wrong and where I may not be wrong. The question is this: why is calling an individual their (instead of she/he) an important battle to fight? Does not referring to an individual using the language constructs for their chosen gender identity make sense? Does that violate any fundamental principle? I think we can have another debate on the merits of having notions of gender engrained in our society and focus first on ensuring full inclusion and equality.

Update: 08/13/2018

Since I wrote this post, I have talked a few time with my colleagues and friends, and we discussed the topic, their perspective on it, their perspective on my perspective. It is great to engage in thoughtful dialogues on the deeper reasons of things that make us wonder. The conclusion at this point is this.

I may have a point on my argument, but the fact is that that is not the important point. I understand that when it is related about our identity in any form, the power for people to chose what is best for them is inalienable. I am in. I confess that it worries me that I am going to make mistakes because I know my absent-minded self, my english-as-a-second-second-language self, and the self that is living at a time where things like this represent the cutting edge boundaries of our evolution as a society.  When I make mistakes, I will apologize, and I will keep doing my best.

Progressive Web in LATAM

[Post written with Demian Renzulli, my colleague @ Google]

Almost ten years have passed since the mobile revolution started with the emergence of iOS and Android; nowadays a large percentage of web traffic is generated from mobile devices. In LATAM, this reality is prevalent. A recent study on the penetration of mobile technologies in the region shows incredible stats such as:

  • By 2020, a smartphone adoption rate of 71%, ahead of the global average of 66%
  • An additional 171 million new smartphone users across the region
  • By 2020, 42% of 4G connections, close to the global average of 44%
  • Brazil, in particular, is seeing a strong 4G growth spurt

These stats are staggering and organizations in the region have been rapidly realizing they must provide great user experiences across all platforms, both mobile and desktop.

To achieve an awesome experience on mobile platforms, an organization can choose to develop a native application (iOS or Android). This path can indeed provide a great user experience, but still leaves two aspects in need of solutions: the distribution problem, which is one of the hardest problems in software; and matching the mobile experience on desktop to ensure an awesome UX across all platforms.

The distribution challenges of native apps are apparent from studies like the 2017 US Mobile App Report, which indicates that 51% of users download zero apps per month. Although these numbers may actually be better when based on larger datasets from the Play Store, for example, it still is true that there exist a high friction for users getting to native apps, and that users tend to download and keep only a handful of top-ranked apps. Furthermore, the limitations of the devices predominantly used in the region compound on the distribution challenges for native apps; one of most sold phones in 2017 in LATAM is the Samsung Galaxy J5; this device may be considered above average, but it is still fairly limited in terms of storage and capabilities.

The other option an organization may choose is to develop a web application tapping into the great reach of the web, reducing the storage capacity needed on user devices, and avoiding the high install friction of native apps.

Despite the appealing advantages offered by web applications, native apps have been perceived, rightfully so, as more prevalent than web applications. Historically, there are several reasons for the disparity between the use of native apps vs. web apps: limitations in the mobile platform, which do not play nicely with the traditional web access model; failing to adapt the web development workflow and strategies when moving from desktop to mobile platforms;  and limitations of the web platform, which until not long ago used to lack most of the capabilities needed to provide a user experience on web at par with that provided on native apps.

Of these challenges, achieving high performance on mobile web apps emerges as one of the main ones and certainly the one of most concern and frustrations for users.  But why is it so hard to achieve high performance on web apps? The reasons are two-fold:

  1. Mobile-platform Specific: differences in CPU architectures (e.g. non-symmetric multi processors), differences in storage characteristics (e.g. multi-layer memories), and differences in the quality and operational characteristics of the cellular networks used to connect mobile devices to the Internet (e.g. latency and error rates)
  2. Website specific: page bloat (size and number of resources used), page structure and rendering strategies, and things like intensive animations and other coding anti-patterns.

This is a challenge faced by users and developers alike at a worldwide scale, but it’s exacerbated in the LATAM region where OS fragmentation is the norm, low-end devices represent a high percentage of the market, and connectivities are far from ideal.

Performance is User eXperience

Users have high expectations for the performance of websites; and when such expectations are not met, users react in ways that clearly impact the outcome of key business metrics. There have been a variety of studies aimed and showing this reality. For example, a 2016 DoubleClick study reported the following results:

User expectations

  • 46% of consumers indicate that waiting for pages to load is what they dislike the most when browsing the mobile web
  • 50% of people expects a page to load in less than 2 seconds
  • About 53% of all mobile visits are abandoned if the page loads in more than 3 seconds

Load times

  • 77% of mobile sites take longer than 10 seconds to load
  • On 3G networks, the average time to load is 19 seconds
  • On 4G networks, the average time to load is 10 seconds
Read more

The Perils of Mobile Web Performance

Niklaus Wirth (remember Pascal and Modula?) wrote a paper back in 1995 issuing a Plea for Lean Software. He starts by stating a fact that has remained true in the desktop world since then:  “Memory requirements of today’s workstations typically jump substantially whenever there is a new software release. When demand surpasses capacity, it is time to buy add-on memory; when the system has no more extensibility it is time to buy a new, more powerful workstation”.  And then he poses the question that is discussed in the paper: “Do increased performance and functionality keep pace with the increased demand for resources? Mostly the answer is no”. Today, 22 years later, we have a seemingly completely different reality, but we still can observe the consequences of Wirth’s statement in the harsh challenges involved in attaining highly performant mobile websites; there is a performance problem in the mobile web that needs to be solved.

In essence, we need to solve an optimization problem with three main dimensions:

  1. User Experience (UX): Engagement and delight using apps
  2. Developer Experience (DX): Ability/ease to develop apps
  3. Monetization Experience (MX): Monetization goals.

If we care only about UX, then developers may have to work at the lowest levels of abstractions to achieve the highest speeds, and publishers will make less money by interrupting the user the least with ads and monetization strategies. If we care only about DX, then users will likely  experience slowness from bloated/inefficient websites, and publishers will make less money because a decreased level of user engagement. If we care only about MX, then users will get annoyed with intrusive ads, and developers will be forced to implement aggressive monetization strategies. What we need is, at least, an approximation to an optimal solution to a 3D optimization problem that strikes the proper balance between UX, DX, and MX.

The common factor across these three dimensions is performance. Users want fast websites (UX), which leads to higher engagement and higher ROIs (MX), and developers of apps and frameworks want to design and develop fast products effectively (DX).

This essay argues about the need and approach to building for performance that drives the developing and evolution of mobile websites: the importance of performance in UX and MX, the role DX plays in the overall equation, and a suggested approach for thinking about and analyzing the performance of mobile sites.  The target audience is two-fold: (1) Web Developers; the community who makes design and implementation decisions; and (2) Decision makers; the community who decides what are the most important features and constraints. The goal is to define common grounds to think about performance so that we can reach the best solution to our three-dimensional optimization problem.

Specifically, we want to discuss:

  1. What is performance?
  2. What are the elements of Performance?
  3. Why is attaining high performance hard?
  4. What are the right performance metrics and budgets?
  5. What tools can we use to measure performance?
  6. What is the best performance testing environment?
  7. How do good performance strategies look like? [patterns]
  8. How do I go about analyzing the performance of sites? [methodology]
  9. How can I learn more about this?

Much of the content mentioned, described, and analyzed in elaborating our perspective in this series of articles can be (and has been) found scattered across many resources such as books, online videos, external online courses, internal documents, product documentations, internal performance trainings and presentations, etc. As Wilson Mizner said: When you steal from one author, it is plagiarism; when you steal from many, it is called research. Well, consider this guide the outcome of our research on the performance of mobile websites.

In the next post we ask the question: what is performance?