Visualizing Speed Without Real Data

CROSSPOST: This article was originally posted as part of PerfPlanet Calendar on December 12th, 2019

Many of us are facing the challenge of promoting the idea of speed of user experience within our organizations and crave any support data to help “sell” it to business stakeholders, product managers and engineers.

Real User Measurement (RUM) is a great tool to capture speed from actual users in the wild, measure their engagement and with one swift gesture point at an A/B test comparing speeds of two versions of the app or even use awesome “what-if” diagram to predict the impact the planned improvement.

Unfortunately, sometimes we just didn’t fund the purchase of a RUM tool, did not integrate it or simply don’t have A/B test set up and did not roll out new code to any of our user yet. This leaves us without data and therefore without a powerful convincer and visualization tool.

I was struggling with some of these problems on multiple occasions and at one point I realized that many conversations do not require actual user data.

  • some of these conversations were just about training team members who needed better grasp in statistics of web speed, distributions, percentiles and effect variability plays
  • some of them needed showing the reasoning behind prioritization of speed and visualization of known industry trends like conversion rate decay or increase in bounce rate as experiences slow down
  • and some other conversations were about supporting the very purchase of a RUM solution so business decisions could be made with real data

One day in early spring, frustration of luck of data overpowered lazy opensourcerer’s brain and I spend couple weekends coding up a visualization tool that lets you pretend you have the data simulate data and visualize it to drive your point across.

The tool is called “UX Speed Calculator” and you can use it at and contribute to it on Github – it is open source and you can help add bells and whistles to satisfy your inner data geek.

UX Speed Calculator does a few useful things:

  • it calculates a log-normal distribution based on base speed and variability so you can simulate your page’s distribution and show how it is different from a normal, “bell curve” distribution people media truly assume
  • shows median, 90 and 95 percentiles so you can try and match your existing stats or simply educate engineers on what those numbers are
  • calculates bounce rate distribution and let’s you adjust the slope of degradation to your hearts desire to help explain to marketing teams the impact of speed on their marketing campaigns
  • calculates exponential decaying conversion rate distribution and helps you explain conversion poverty line and why running experiment by slowing down pages is not necessarily predictive of how much savings you’ll get by speeding them up the same amount
  • it also tries to shine light on the phenomenon on of low conversion / high bounce rates on the very left of the chart (near the zero) where despite the logic of “faster means more business” we often see unexplainable data. Many RUM experts believe it is due to the low numbers which do not produce statistically significant results, but my work with UX metrics and general lack of understanding of statistics always made it hard for me to accept that as the whole story so I postulate that is is caused by a high percentage of errors in that part of the chart and experiences that are measured as “fast” were actually incomplete, functionally broken experiences or outright error pages. So in the tool you can adjust decaying failure rate distribution. Charts also show theoretical bounce and conversion rate distributions as dotted lines and distributions that reflect error rates as solid lines
  • based on a combination of failure rates, bounce rates and conversion rates, charts also show color-coded bars for each of the populations to make it sleazier time relate to each pixel as a user who had different experience and help consumers of this visualization empathize with the data.
  • if so many lines and labels confuse you and your stakeholders, feel free to click on the legends on the right to hide those that do not matter for your story
  • and if you need to share a chart, just copy a URL and send it over, it updates as you tweak the knobs and dials so you can always jump to the right chart and don’t need to re-create perfection from scratch
  • ohh yes, it also shows you the $$$ all these conversions amount to so those of your peers who don’t like math or can’t bear the cognitive load of charts can still translate the value of speed to something tangible. Substitute $ for €, £, Â¥ or even ₽ if that works better for you.

Hope this tool will help you with your creative story telling and you’ll be able to push the limits even further.

Happy #webperf-orming!

And remember, there are lies, damn lies and statistics! So don’t overuse this or other scientific data tools in your battles for the better within the fuzzy world of user experience!

Speed Patterns

CROSSPOST: This article was originally posted as part of PerfPlanet Calendar 2017 on December 6th, 2017

Speed is a major contributor to user experience on modern web sites.

It is important to pay attention not only to technologies that said experiences are build with, but to the way they are designed as well.

Proper speed design is a collaboration between product managers, UI designers and developers as all the aspects of the page composition must be balanced to achieve fast experience that is useful for end-users and deliver on the goals set by creators of the site.

Start bringing speed into the process early on, when design is just being born. I hope to help with this task by documenting a series of patterns that are commonly seen in fast web sites!

No Spinners Introducing a new project to collect speed patterns:

Below are a first two patterns: “Fast Start” and “Immutable Layout“, I hope you enjoy the format and will help by contributing to the project on GitHub.

Fast Start

Before user can start the experience, there is an inevitable delay as user’s browser goes away from previous view to the current view.

This delay manifests itself in waiting for first piece of the UI to be painted on the screen. Usually user waits for page to show while looking at the previous page, e.g. search engine results page or another page where they performed an action that led him to the page in question.

On this filmstrip, previous page is shown as white:

Slow first paint filmstrip

The usual cause for such delays are either a bottleneck of a first request for HTML page:

Slow first request

Alternatively, delay can be caused by various render-blocking assets loaded on the page, like CSS stylesheets, fonts or pure rendering delays due to time-consuming layout and painting or JavaScript compilation and execution that compete for same CPU resources:

Delayed first paint


Making it a requirement to start painting quickly is critical, especially as it competes with other technical and design goals of loading large amounts of code and displaying a large number of elements on the page.

Set timing SLAs during product and design discussions: 50-200ms

Immutable Layout

A common problem on web sites that use ads or other 3rd party display elements (widgets), but also manifests in regular websites is change in layout as page loads.

This is particularly noticeable by users when they start scrolling down the page and element at the top of the page (e.g. ad banner or carousel image that finally loaded) suddenly changes it’s height pushing content down.

Pushy Ads


Instead of shifting the layout, always set the expected size of the available space.

Expected ad

Use CSS to set height/width of the container when loading element into it and for images, simply specify width and height directly on a tag so layout engine doesn’t have to wait for image bytes to come back from the network to determine its pixel dimensions.

<img src="awesome_logo.png" alt="Awesome Logo!" width="400" height="300">

I’d love to see this project grow as a community effort, you can help by submitting new patterns, reviewing drafts and existing patterns as well contributing illustrations, links and examples.

OpenSCAD Visual editor, Brett Victor style

I feel uncomfortable with traditional click-n-drag visual editors, whatever it is a pixel-based editing in Photoshop or 3D editing in Tinkercad.

I’m spending time editing something, but comparing to development, result is very “fragile” and depends on exact sequence of pre-planned events and relies on precise drag-and-drop capabilities and heavy use of undo even with years of mouse handling skills.

The gap is currently addressed by OpenSCAD, a language that allows you to generate 3D models so they can be parametrized and can power tools like Thingiverse Customizer so you can make adjustable prosthetics for kids who grow up (and dimensions need to adjust).

I feel that ultimate solution in this very creatively imaginative and visual space heavily mixed with scientific and precise engineering is in combining the two in Bret Victor-esque way (here’s a video in which he talks about his approach and shows some game development tool prototypes which influenced or directly contributed to Swift Playgrounds, if I understand it correctly):

Imagine editing using visual editor on the right of the screen, adding and removing objects, moving them around, intersecting and so on like you would in Tinkercad, but on the left, seeing the code as it changes with every change you make.

For example, you drag the object and coordinates in the code change, or you press a button to combine one object with another and it starts a function and puts first object as first parameter, waiting for you to pick second object.

Needless to say, if you edit the code, visual editor would also update to reflect the changes. And if you point at a number in the code and drag up down, it updates the code and corresponding visual at the same time

This can be combined with timeline feature similar to the one Fusion 360 has:

but in our case as it works with code, it would not only roll-back/replay visual objects, but will also visually represent OpenSCAD commands highlighting corresponding part of the code when you click or hover over a step. It can also act as version control for the code too (imagine branching, merging and pull-request workflow of git integrated with it).

Just though I’d share before it goes into non-being.

Progressive Storyboards

CROSSPOST: This article was originally posted as part of PerfPlanet Calendar 2016 on December 7th, 2016

Speed needs to be designed

Speed of User Experience (UX) is important for your web sites and mobile applications, but it often takes a back seat to functional improvements and is always thought of as purely technical exercise – proactive at best, but more commonly coming after a newly released product fails to perform.

While technology plays a big role in delivery and rendering of user experiences in modern applications that depend heavily on networks and on-demand content and functionality, it only provides solutions and often has serious constraints.

In order to create products that deliver great experience, it is critical to start designing speed and planning on how it can be delivered at the very early stages of the process.

Movies or paintings?

Unfortunately, today’s deliverables that are passed from product people to designers and from designers over to development teams are inherently static.

Both early product wireframes and more elaborate Photoshop (or Sketch) comps/mockups only depict the final view of the user experience and do not articulate the inherently progressive nature of web medium.

In his talk, Speed vs. Fluency at Velocity New York 2015, Kent Alstadt asks if today’s web designers are more like film makers who direct “short films” of digital experience or if they are artists who paint beautiful oil paintings that show final picture. He argues that human’s brains enjoy experiences with higher “processing fluency” and web pages that are designed/directed to achieve it would be more effective in meeting their goals.

Performance Choreography

Tim Kadlec in his WebPerfDays NY 2014 talk about Performance Choreography also draws parallels with movie making and cartoon animation where transitions and “in-between moments” are given a lot of thought as they heavily impact perception.

He points out the importance of concentrating on techniques like skeletal designs that focus on progress instead of using spinners and other artificial progress indicators that emphasize waiting.

Revealing Features

In order to achieve a smooth transition between different views/pages of our interface it is critical to concentrate design thought on this transition.

It’s important to ensure that the sequence in which features are revealed to the user is natural and follows user’s incremental needs as they wait comfortably for all the information and interactive functionality to be shown.

Rendering Stages

The whole universe of views and pages is very diverse and unifying all the experiences is impossible. What we can do instead is concentrate on user’s needs as they experience information in human-computer interaction on the web.

If we step back from specifics of individual pages and experiences and look at the wider problem, we can group rendering into several important stages.

Identifying these stages for their digital experience would help product and design teams come up with appropriate visual solutions and create smooth transitions.

1. Verify Destination

First step of any web navigation from one page to another or interaction within website interface is to assure the user that the action they performed was the one they intended to do so they can comfortably wait while it loads without wondering if they need to click the Back button.

This applies equally well to navigation from a search engine results page or external listing page where a link to a competitor’s site can be right next to your own as well as navigation within your own site with many alternative navigation paths.

If the user is waiting too long for any piece of interface to show, they can cancel their action out of sheer frustration and leave. This means that we need to identify the minimum amount of User Interface that we need to load as quickly as possible to reduce the uncertainty and to keep them interested.

Here are the most common UI components that are relatively easy to quickly show to the user:

  • Core branding elements like logo and brand colors as part of top navigation
  • Breadcrumbs and page headline/title for specific detail pages

Amazon logo and breadcrumbs

truTV header with logo and section

2. Provide Primary Content

After the immediate feedback was provided, it is most critical to show the user the primary content we intend them to experience.

One challenge that we have here however is to separate core, primary pieces of content on the page from all content that we’d like to provide.

It’s important to narrow down the set of components so they can be loaded as quickly as possible and users can immerse themselves into content while waiting for the full experience to load.

Primary content is usually easy to identify in today’s design process because it is naturally given the most attention in product conversations and has the most prominent place on the pages.

Here are a few examples:

  • Leaderboards/hero images on marketing pages and the home page of the site
  • Article text & photo for the news articles
  • Product title & image on e-commerce product detail pages

3. Allow Interaction

Usually, the most important part of user experience on the web is user’s action; almost all design concentrates around soliciting an action from the user.

It is critical to show points of interactivity to the user as soon as the primary content is shown and the user was able to make a decision to act upon it.

Calls to action (CTA) are quite different from business to business: “Add to cart” buttons for e-commerce or “Play” button on a video player are good examples.

Amazon CTAs

Keep in mind that even though an action is probably the most important goal of each page, it cannot be performed until the user consumes the content to convince themselves to perform such action.

Same as in primary content, it is critical to ensure that primary actions are prioritized and included in this stage as we all have great temptation to put everything we, as builders of the UI, envisioned and you will have many opinions in the room with various product stakeholders.

Good news again is that business teams probably have a great grasp on what the primary actions are and they spend plenty of time in those conversations so it’s relatively easy to identify and isolate those components during the design phase.

4. Show Secondary Content

There is always something other than primary content and actions on the page, find this content and secondary CTAs and load them early in case the user is not interested in primary ones.

It is somewhat harder to do that as one can argue that everything that is not primary goes into this secondary category, but it is important not to lump everything into this group and leave things that are not as important to load in the next stage.

Good examples of secondary content and calls to action include:

  • Sidebars, secondary headlines or content blocks
  • Additional navigation
  • User-generated content, sharing buttons, ads

5. The Rest & Invisible Tasks

Once you’re done identifying the first 4 stages, you are left with many other parts of the content and listing them would help you ensure that you don’t have any unaccounted items and avoid the desire to add any of them to the earlier stages.

There are always elements that are there for some political or legal reasons, like majority of footer content, for example, as well as interactions that you don’t have any business owner for and are slowly dying out, but you still don’t want to remove (you probably should).

This stage/group is also for elements that are not within user’s viewport and cannot be viewed or interacted with simply because they are literally invisible.

This applies to elements “below the fold” on search results pages that are already a consideration for “lazy-loading” or “post-loading” after initial page is rendered, especially if interface calls for “infinite scroll” or some other interaction that requires unbounded amount of data to be loaded over the network.

One particularly tricky category of element to identify as part of this stage are subsequent slides for the “carousel” widget that are not visible initially, but are shown either automatically after period of time or upon user interaction. It is very important not to prioritize these as they are often quite heavy and require significant amount of code and page manipulation and will delay more important components.

In addition to elements that are visible later, it is important to include all elements that are never visible, like analytics beacons or other tracking software. Luckily it’s already rarely discussed during design sessions so listing them here can be left for this last step, just don’t forget about those non-visual requirements that still warrant code download.

6. Acknowledge Action

This stage is the last, or the first, in the whole human-computer interaction model depending on how you cut the user path into distinct chunks we call pages or views.

In default page-to-page interaction users just wait until the page starts to load and only get first clue that they did successfully perform an action after viewport is cleared and replaced with next page.

Sometimes it is very hard to speed up these processes as heavy network operations happen at this point and complex server actions might also take significant time (e.g. calculating search results for an arbitrary query over large dataset).

What we can do to give the user an acknowledgement of their action is to provide visual feedback. Historically first examples included disabling form elements upon form submission (reducing double-submission).

Disable submit buttons

More creative ways were discovered over the years, including the following:

  • Providing “loading…” label on the form or next to submit button
  • Transition overlays spelling out that user’s acction is accepted and app is hard at work to perform it
  • Erasing content area of the current page emulating next page’s initial render before request even went through to the server
  • Animating-away the current view while next one is rendered
  • Rendering skeletal layout of the next view within single-page app

This is only possible for interactions that are initiated when user is already on your site, but can provide a good flow once user is already engaged.

IMPORTANT NOTE: Please avoid using spinners and design good progress indicators that feel natural and don’t require users to concentrate attention on interpreting them.

Progressive Storyboards

When you include this work within your product design process, it is only natural to start thinking about how to adjust the established deliverables to better represent the results.

You can start by simply isolating the components of the “final” mockups that are currently used as deliverable and producing a sequence of views by simply whiting out the elements of the original mockup that are not supposed to be represented at particular stage of rendering.

Here’s an example for a CNN Home Page (screenshot of final view):
Final view screenshot

And corresponding sequence of rendering stages depicting identified steps as a Progressive Storyboard:

Progressive Storyboard

You can also go into more detail for more complicated transitions acknowledging user’s actions, as they are in your full control and can significantly help mask slow server-side and network performance.

Acknowledge Action Storyboard

Having these deliverables as a result of product design work can help the tasks of graphical design, animation and development teams; clearly stating expectations and making it clear what needs to be achieved.

Establishing Technical Constraints

Performance work can never be done by one team in isolation, it is always a collaboration between product and design teams who know the experience they try to create and technical implementation and operations teams who know technical realities of web medium.

It is easy to answer the question of how fast the experience has to be with a quick “very fast” and to expect that everything will be loaded and rendered in-front of the user immediately without realizing the costs of accomplishing that or hard technical limitations that do not allow for arbitrary wish granting.

To help both business teams with high-level cost assessment and technical teams with creating solutions for each stage of rendering, it can be practical to establish a series of technical constraints that map to stages we identified.

Here’s an example of such mapping:

Rendering Stage Technical Constraint
1. Verify destination Inline CSS & Logo, fit content and code in first 14K
2. Provide primary content no external JS or CSS, just HTML, 1 or 2 images
3. Allow interaction Skeletal CSS, async JavaScript
4. Show secondary content All CSS, above the fold images, fonts, AJAX-in content
5. The rest + invisible tasks
* Acknowledge action Pre-transition feedback, animation, fake transition

You can notice that optimizations that are higher on the list are at the same time more complex and provide more aggressive constraints, for example fitting a lot of code and content into 14K of payload is not possible and only limited functionality is possible without JavaScript during primary content stage.

A good rule of thumb to have is that each stage is 10x more expensive as previous one in terms of time for development, testing and maintenance. So putting some element into secondary content can cost $1K while moving it up the chain to primary content can convert to $100K and to first stage would cost you $1M. This can give more structure to prioritization conversations and allow to pick only most important components to be promoted.

Design, Implement, Measure

I really hope that this approach to designing for speed early on can help your team establish better performance practices and account for the complicated nature of the web performance across all the stages of experience creation.

Make sure to keep paying attention to speed and measure each stage as closely as possible to ensure that users have smooth experience.

Let’s reduce the amount of frustration in the world and make our sites fast!

Web Performance Full Time

I’ve been at truTV, formerly Court TV for 11½ years which by industry standards is pretty long run with any company. Well, I’ve worked with some great people and done quite a few interesting projects in-house and outside, especially in Web Performance space so I consider it a good and productive run.

Keynote SystemsAnyway, doesn’t matter how long something lasts, there will be a moment when it’s time for a change and now is that moment for me. I am leaving truTV/Turner to join Keynote Systems as consultant for their Insights team that helps company’s clients with Web Performance needs.

truTVNeedless to say, I’m proud of the team at truTV Web Services that has a grasp of their tech, can both innovate and know when to stick to proven solutions and more importantly, is a bunch of great and passionate people! I’m positive they will only be pushing the boundaries of what can be done by a small team within a large organization and be able to sustain rapid pace required by media industry!

As you can imagine joining Web Performance-centric team is an important step for me personally and a chance to do what we do at NY WebPerf meetup – speeding up the web, but now on a full time basis. Obviously, I will continue to run New York meetup, help other organizers around the globe and promote Web Performance with talks, blog posts and every other possible way, and now with help of Keynote, I will dedicate more time to this public work.

There is no better time to rid the web of slowness!