Category: mobile (page 1 of 1)

February 11, 2018

AMP in WordPress

If you only have one minute to read this post, here is the gist of it: WordPress users can get a first-class AMP experience without compromising the fidelity of their content or surrendering the flexibility of the WordPress platform. Get a glimpse of what is possible with AMP in WordPress by watching our AMP Conf 2018 talk! https://youtu.be/GGS-tKTXw4Y If you have a few extra minutes, follow me to the next paragraphs to learn more about the state of AMP in WordPress.

The WordPress Ecosystem

In a nutshell, WordPress is: a Content Management System (CMS) for websites; the largest player in the CMS space with ~59% of market share, powering about ? of the web; and a thriving ecosystem of plugins, themes, hosting providers, agencies, freelancers, all working together on the creation of WordPress-powered content. But when I think about WordPress I think about one thing: there are many users publishing and consuming content via WordPress-powered sites, and all of them should get an awesome UX on the platform.

And since AMP is all about enabling an awesome (fast) User eXperience to all users, in this post we discuss two things: (1) the case for AMP in WordPress; and (2) the state of the art of AMP in the WordPress Ecosystem. Curious? Read on!

Why AMP in WordPress

One of WordPress major virtues is the flexibility of the platform. You can accomplish basically anything you can imagine, as demonstrated by the large and ever expanding ecosystem of plugins available to add functionality and customize your website in a myriad of ways. However, this same virtue can also turn into one of the major challenges of the platform. Even taking into account plugins that are very good (i.e. follow coding/performance best practices and coexist nicely with other site components), the likelihood of having plugins colliding in their interactions (or impacting performance) when jointly activated in a site, is definitely not negligible.

This virtue/challenge duality of the WordPress ecosystem has its parallel in the open-web web publishing ecosystem. In the latter, there is nothing restricting a web developer to hamper the performance of a site by following counterproductive coding practices (e.g. loading scripts synchronously, render-blocking CSS). And even if the developer builds a site impeccably, adding a third-party JS library could spell a performance disaster.

AMP emerged as a response to that reality, bringing forward effective design principles and control mechanisms that enable sites to offer predictable performance. The effectiveness of AMP and its impact on UX is demonstrated by plenty of data and examples in the wild. And WordPress publishers would also benefit greatly from having more control of the UX of their sites. This could be achieved by adopting coding and performance best practices in WordPress development, and integrating AMP with the WordPress ecosystem to make the WordPress platform more performant.

The plugin work for enabling AMP in WordPress described in this post, was pioneered by the AMP Plugin initially developed by Automattic. Subsequently Google and XWP joint the open source development effort to help evolve the plugin significantly. Want to know what is possible with AMP and WordPress nowadays? Let’s see!

The AMP Plugin

The initial goal of the AMP plugin was to enable AMP for WordPress.com VIP sites. It certainly met its goals for VIP, and it was also adopted at some level by the general WordPress community either directly, or through other plugins built on top of it. In the context of its initial objectives, the main characteristics of the early versions of the AMP plugin make sense:

Developer oriented. The plugin provided a minimal set of core abstractions to enable AMP in WordPress, and allowed developers (i.e. agencies, plugin and theme makers) to modify it and extend it to tailor its capabilities to the needs of their individual sites.
Pair mode. The plugin adopted a simple-theme approach bypassing the WordPress template hierarchy and generating a separate AMP version of published content based on very basic theme template parts.

These characteristics worked well for sites that have good engineering support to tailor the AMP content to their needs. However, at a larger scale, the adoption of the plugin was more challenging because the baseline capabilities did not offer enough functional and visual parity between the two versions.

Google and Automattic started working together last year with the goal of bringing the AMP plugin to its maximum expression, and enable a rich AMP experience for all WordPress sites. A few months after, XWP engineering team also joined the project to push for the same goals with the expanded scope of integrating modern web technologies in general into the WordPress ecosystem. And since everything is open source, the WordPress community has also been part of this work through many contributions. In the past few months versions 0.5 and 0.6 of the plugin were released, including bug fixes, expanded support for embeds, support for pages, parity with AMP library specification, better configuration capabilities, and much more. And after these, we have focused on one of our main initial goals; since the beginning we have had our sight set on enabling an organic AMP experience in WordPress; that is, an experience where there is no need for a pair mode (unless applied by choice) because there are no gaps, either functional or visually, between the AMP and non-AMP versions of content published in WordPress. Without such a gap, WordPress publishers are able to publish a single version of their content which is beautiful, feature-rich, all-around WordPress, and runs at the speed of AMP! We call this an all-AMP experience.

An all-AMP UX in WordPress

The aforementioned pair mode approach makes sense when there are functional and visual gaps between the AMP and non-AMP versions of a given content. In such a case the pair mode keeps a “version” of the original content and an AMP’d version of it. By enhancing the AMP plugin and devising the right mechanisms for theme/plugin integration, we can eliminate these functional and visual gaps an enable WordPress sites to offer a single, all-AMP experience.

An all AMP experience in a WordPress site requires: (1) a plugin that enables a seamless integration of AMP into WordPress; (2) a theme that integrates nicely with AMP (adds AMP theme support); and (3) the seamless coexistence of third-party plugins in an all-AMP site.

We have made good progress on the plugin work and by the time you are reading this post, many goodies will be available in version 0.7 of the plugin (release). We have also made progress on defining an approach for building progressive themes; that is, themes built following the latest coding and performance best practices, leveraging as much as possible progressive technologies in the web platform, and integrated seamlessly with the AMP plugin. The result on this work was presented at AMP Conf (video), and a prototype of an AMP-Compatible theme is available, and you can experience it live as well. And the cherry on top of the cake, is the work by Morten Rand-Hendricksen on the development of a Progressive Theme Boilerplate project, which enables theme developers to go from 0 to starter progressive theme in an easy way. Today, a native AMP experience in WordPress is possible! On the theme side of the story, native AMP support is enabled by:

Integrating with the standard WordPress templating system, as opposed to the AMP plugin’s initial paired mode bundled theme for post templates
Supporting standard site elements such as the Widget sidebar, native comments, and many others are fully supported
Providing opt-in choice for enabling the experience with fine-grain control: the theme works with or without AMP

And on the AMP plugin side of the story, the seamless integration of AMP into the WordPress workflow is enabled by:

Supporting all standard/default widgets; non-core widgets will also work, but anything they add which is not AMP-compatible will be stripped. And we encourage the plugin community to work with us on their integration
Providing AMP compatibility for all relevant WordPress actions / filters
Preventing WordPress from printing scripts/styles in the header and footer
Having an efficient “AMP preprocessor” ensuring AMP validity with maximum fidelity
Providing functionality in the AMP preprocessor to identify and flag incompatible plugins at runtime. Besides helping the publisher to keep their AMP content valid, this also will help guiding the community to work with us to make every relevant plugin AMP-compatible
Allowing three “use modes”: (1) legacy pair mode, with the pre-0.6 ad hoc post templating system; (2) new (enhanced) pair mode, integrated with the standard WordPress templating system; and (2) AMP Canonical, with a single AMPed version of the content and also integrated with standard templating system.
Supporting all default embeds; other embeds are also allowed but the AMP preprocessor may not make them AMP compatible in the best way (i.e. an may be used)

The combination of these features and capabilities allows WordPress publishers to run a pristine WordPress site that is all-AMP! The following screenshot shows a demo of an all-AMP WordPress site; there is no pair mode, and look at the console!

The Road Ahead

AMP integration with the WordPress ecosystem has come a long way. But there is still quite a bit of work ahead of us; very exciting work indeed! Some of the main areas currently capturing our focus include:

Continue expanding the capabilities and scope of the AMP plugin to fully enable an awesome AMP experience in WordPress at scale, and collaborate with publishers, WordPress users, and the WordPress developer community, to make all relevant plugins/themes AMP-compatible
Continue our work on Progressive Themes aimed at defining a systematic approach to building themes that provide AMP support, follow the latest coding and performance best practices, and integrate the latest advances in the web platform.
Align our efforts with the evolution of WordPress via contributions and integrations with Gutenberg, the new editing experience which is set to revolutionize content creation in WordPress. This includes supporting Gutenberg blocks, including blocks for AMP Components. For example, we’re looking to augment Gutenberg blocks with AMP-specific attributes, like the layout and media attributes, which would then inform the AMP preprocessor on how best transform an element into AMP.
Contribute our collaboration with the Tide project, to empower WordPress developers and site owners with the ability to choose themes and plugins based on concrete quality metrics
Enable the systematic tracking of the performance of the WordPress ecosystem by leveraging extensive datasets and the power of Google’s data processing infrastructure

Advances in the web platform all aim at improving the user experience along different dimensions. AMP design premises focus on the performance of the mobile web and the associated quality of the perceived user experience. With the AMP plugin and a modern approach to building themes, WordPress-powered publishers are able to leverage the performance and ecosystem advantages to be gained from using AMP. There is still quite a bit of work to be done. These are very exciting times to be a web developer, and also a WordPress developer! We are certainly excited as we continue advancing towards our goals and unlock the even greater potential of the WordPress platform. And remember: everything we are working on is open source, including AMP! All the work described in this post is the result of a great collaboration between Automattic, XWP, Google, and the WordPress community. Want to help? Join the effort and participate with your contributions, feedback, and engagement!

December 9, 2017 / 1 Comment

Reasoning about Speed

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.

December 4, 2017 / 0 Comments

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.

December 3, 2017 / 1 Comment

Why Is Attaining Good Performance Hard?

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.

December 3, 2017 / 1 Comment

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

Parse HTML into DOM
Download resources linked from the HTML
Parse CSS into CSSOM
Parse JavaScript
Construct the render tree by combining the DOM with the CSSOM
Layout (calculate the positions and other attributes of all visible elements)
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.

May 16, 2017 / 1 Comment

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:

User Experience (UX): Engagement and delight using apps
Developer Experience (DX): Ability/ease to develop apps
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:

What is performance?
What are the elements of Performance?
Why is attaining high performance hard?
What are the right performance metrics and budgets?
What tools can we use to measure performance?
What is the best performance testing environment?
How do good performance strategies look like? [patterns]
How do I go about analyzing the performance of sites? [methodology]
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?