Frontend Weeky logo

Frontend News

A BRIEF GUIDE TO
USING WEBPAGETEST

Frontend News #5

David East - Author David East — August 22nd, 2018

Web performance is continous

Web performance is a lot like user experience. It's hard to just "sprinkle" in some UX and see the site get "pretty". User experience isn't an add-on, it's a series of fundamental decisions. User experience means you take time to understand the user's needs and you design your app to fit them. This isn't a one time study either. It's a continuous process. Web performance is the same way.

It's difficult to "sprinkle" in some performance to speed up a slow site. Yes, there's some easy wins. Compress images, minify files, use font-display: swap. But creating a performance focused site starts from the ground up. It's not enough to build a performant site and take a break. It's a continuous process. It takes continous monitoring.

WebpageTest is the best free tool to measure performance

WebpageTest allows you to test the performance of a website on real devices and real consumer speeds. Test on an iPad, iPhone, Galaxy S7, and even low powered devices like the Moto G4. Set network speeds from fast FIOS to slow mobile edge networks.

Webpage test main testing page

WebpageTest is built and maintained by the great Pat Meenan. Give him a follow or a thank you. He deserves it.

Fast on slow means fast on fast

You might be confused by the many options provided by WebpageTest. Let's keep it simple. Test on the lowest denominator. Fast sites on slow networks are still fast sites on fast networks. The web's greatest asset is reach. No app stores, just links. Performant sites have better reach across the world.

Instead of messing with dropdowns and checkboxes just use the easy mode: webpagetest.org/easy.

WebpageTest easy mode setting

This mode uses a Moto G4 on a "Slow 3G" network. What makes this setting so slow?

Don't focus on bandwidth. While 400kbps isn't ideal, it's an after thought compared to the latency.

Test with high latency

Bandwidth is the measure of how much data the network can send at once. Latency is how long it takes to make a send the data roundtrip. Bandwidth is the width of the tube and latency is its length.

It's easy to get hung up on bandwidth. More bandwidth means faster downloads right? Well only if your site is large or your in the business of large content like Netflix. What if your site contains 300kb of assets in the critical path? That meaning, your site has 300kb of HTML, CSS, and render blocking JavaScript. Bandwidth isn't your problem. Latency is.

Mobile networks are notorious for high latencies. The "Slow 3G" setting contains a latency of 400ms roundtrip. This means that it takes 400ms for the client to receive data from the server regardless of its size. To make matters worse, the initial HTTP connection takes four roundtrips! That means it's your site can't begin to load other assets for at least 1.6 seconds.

Respect latency. Fight it with HTTP/2, CDNs, and reducing request chains. It's the killer of performance. Mobile networks are fraught with high latencies, make sure to test accordingly.

SIGN UP!

One web topic. Every week. Sorry if you already have 😬

The summary is just the start

The "Easy Mode" test run gives you a summary and three test runs. The summary looks a bit like this:

This table presents a bunch of important metrics, my favorite ones are:

Load Time isn't the metric you're looking for

The metric that jumps out the most is the one I didn't mention: "Load Time". The "Load Time" is an paltry 5.8 seconds. However, it does not tell the whole story. According to the WebpageTest documentation: "The Load Time is the time from when the user started navigating to the page until the Document Complete event (usually when all of the page content has loaded)."

The "Document Complete" event refers to the window.onload event. According to MDN: "The load event fires at the end of the document loading process. At this point, all of the objects in the document are in the DOM, and all the images, scripts, links and sub-frames have finished loading."

While this metric is good to know, the page is possibly usable before this events fires. Deferred scripts and images inflate this number even though the site is likely usable.

To understand the real story of what's going, we'll need to look at the "Filmstrip View".

The Filmstrip View is where the important metrics live

I rarely focus on the summary. I may glance at "First Byte" to make sure nothing funky is going on. But I'm quick to jump into the Filmstrip View.

Table row showing how to get to the Filmstrip View

To the right of each test run is a link to the "Filmstrip View". This is the page you'll use the most. The Filmstrip View provides you more than numbers. It gives you a visual play-by-play of what's happening during page load.

This collection of scrollable thumbnails shows you what it feels like waiting for the page to load. You can even change the interval between thumbnails. The default is 0.5s, but you can set it to 0.1s or even 60FPS. I usually pick 0.1s because it makes it much easier to consult the network waterfall below.

The network waterfall provides hints of performance improvements

Below the filmstrip is a network waterfall. Notice that the vertical red bar moves across the waterfall as you scroll through the filmstrip.

This is how you can correlate visual changes to the loading of assets over the network. As you scroll past a loaded asset you'll see a specific change. Use this to find the series of formal page load metrics.

First Paint, First Contentful Paint, First Meaningful Paint, and Time to Interactive

The sheer amount of page load metrics is sometimes overwhelming. Focus on the overall picture of page load instead of worrying about the importance of each metric. There's a series of formal metrics that are used to understand progression of page load:

This wonderful image was sourced from Web Fundamentals.

The network waterfall tells you when these metrics occur. It's easy to notice when just some content appears and when the main content appears. But how do you know when the page is interactive? The network waterfall also provides this information.

Use the network waterfall to find Time to Interactive

The very bottom of the network waterfall contains information about the activity of the browser's main thread. This main thread is responsible for handling UI updates. If the the thread is blocked there won't be able UI updates. This means the page is effectively frozen.

This graph uses red blocks to tell you when the main thread is blocked. This is common for JavaScript heavy sites, but thread blocking is not caused by JavaScript alone. In the example above we can see a large block of red below a big chunk of purple. This purple represents the layout of the screen. What's causing this? Let's consult the entire waterfall.

 A frozen thread on a webpagetest profile

At just before 5.4 seconds a web font finishes loading. Then immediately after there's a bunch of purple which blocks the thread. This is because of font-display: swap. The browser had to layout the page to swap to the custom web font. This was an intensive, but brief process. Remember that we're on a Moto G4, modern devices wouldn't have this problem.

The main thread chart is clear after this point. This means we can consider the site interactive at 5.5s. This isn't a completely meaningful metric in this case however.

Use Time to Interactive as a guide

Time to Interactive is tricky. At first glance it can appear that a site isn't interactive until that meric. But that's not always the case. In the example above the thread is clear for several seconds before and after. This blocked section is a hiccup. What would be more concerning in an large chunk of red that starts early when content is visible. This is common in server side rendered sites like below:

A waterfall of an server-side rendered JavaScript framework site

This server-side rendered JavaScript site has a First Meaningful Paint of 2.8 seconds. However the thread becomes blocked at two separate intervals: at 5s and around 6.7s. This means the user starts to use the page but at those intervals the page freezes up. This just a small example, but this is the behavior we're concerned about. Not just a singular small hiccup.

Page load performance is not one metric

If this guide has taught you anything, I hope it's that page load is not one metric. Looking at "Load Time" won't tell you when a user begins to see content. Focusing on First Meaningful Paint won't tell you if a user can actually use your site. Using Time to Interactive alone isn't a wise strategy either. It's up to you to understand metrics are most important to your site. It's up to you to continously monitor your site and make sure it's performing for your users.

THE HEAP

Links to articles I actually read

Web performance

Web assembly is here!

blogs.unity3d.com
WebAssembly is touted as the future of the web. However, it has felt like it's still too early to do anything significant. The tooling has been too raw. But that's starting to change. Unity now supports an export to WebAssembly, that's a big game changer.

CSS Scroll Snap

developers.google.com/web
CSS Scroll snap allows you to create better scroll experiences. This is particularly useful for components like carosels and swipe screens. Don't you just love it when CSS gets a feature that once required JavaScript?

Shadow DOM in Ionic (and Why it's Awesome)

blog.ionicframework.com
Shadow DOM encapsulates styling within a "shadow tree". Mike Hartington does a fantastic job explaining what what Shadow DOM is by covering its API. This is a great read even if you're not an Ionic developer.

Resources

Undraw

undraw.co
Undraw is an "collection of beautiful svg images that you can use completely free and without attribution." In other words, if you're not a graphics designer, this will be a really userful tool for you.

Space X API

github.com/r-spacex
Space X... launched... an API. See what I did there?

PWA

NOTE! This section is curated my Maxim Salnikov! He's one of the most knowledgeable and passionate PWA developers out there. Give him a follow on Twitter.

Shipping PWAs as Chrome Extensions

dev.to/samthor
Distributing your PWA as a Chrome extension? That's possible! Sam Thorogood gives all the details about his Emojityper PWA.

Twitter PWA Release Notes

twitter.com/i/release_notes
The Twitter Lite team started to publish the version history. In the latest update: better integration with Windows 10 - viewing live events or moments will add an entry to your Windows Timeline so you can easily return later to see updates. Plus 8 more feature added.

Service Worker Caching Strategies Based on Request Types

medium.com/dev-channel
Thomas Steiner from Google is explaining how to use Request.destination property in your service worker to determine the type and/or caching strategy of requests.

Frameworks

NgRx: Parameterized selectors

blog.angularindepth.com
Selectors are the most underused piece of NgRx. They act as queries to your store which makes it easier to structure. Great article by Time Deschryver, a member of the NgRx team.

Lit Element

github.com/Polymer
A flexible, lightweight, custom element base class. If you're working with custom elements this class will provide you a lot of conveniences.

CSS keyframes in FramerX using React and Styled Components

twitter.com/MengTo
Meng To with a short video on integrating CSS keyframes in FramerX, a React + Design too.

Fonts

Berlingske Serif

playtype.com
A modern and friendly looking serif font.

Platform

commercialtype.com
A nice geometric sans serif font.

Machine Learning

The 7 Steps of Machine Learning

youtube.com
In just 10 minutes, Yufeng Guo will explain what an ML workflow looks like at a high level.

FEEDBACK

I need to hear from you. It's super important

Every week I ask you what was good and what might have sucked. I read each piece of feedback and work to incorporate it into the future editions of the newsletter. It's just a brief Google Form.

Preview of Google Form for feedback

Contact / Privacy Policy