Category: Web Performance

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 https://ux-speed-calculator.netlify.com/ 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: https://www.speedpatterns.com/

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

Solution

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

Solution

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.

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!