Web Performance: Trends and Insights from 4 Top Performance Experts

A: I’ve been using WebPageTest for over a decade so it’s really cool to be working on it now. Pat Meenan, who created WebPageTest, built it from his basement on his own dime. WebPageTest has always been free and much lauded by the developer community. My team and I are immersed in ensuring its continued success by improving the documentation, adding features, and enhancing the overall platform experience. Our goal is to better incorporate WebPageTest into the workflow for performance testing.

A: We’ve received numerous inquiries about the CWVs. We were aware that web performance affected the search-engine algorithm but didn’t know the specific metrics. Now we do know and have concrete targets. In fact, this is the clearest signal from Google yet on what constitutes good web performance.

A: A performant website enhances user experience, which bodes well for business and for engagement, but there’s a threshold. If performance was the only criterion, we’d revert back to the original websites of the 1990s: a plain, white background with only hypertext and no unique fonts or visual elements.

Striking that balance is tricky because it varies by organization. Some companies might be less tolerant than others of less-performant pages. So, to find that sweet spot, you must measure performance against your business goals, connecting business data and performance data. Tammy Everts calls that “performance poverty line,” which means “the plateau at which your website’s load time ceases to matter because you’ve hit close to rock bottom in terms of business metrics.”

Also, do not overlook the metrics from other browsers. Chrome is a moving target, and Google is constantly working to improve its metrics. In a prior version of Chrome, you could hide elements because the shift wasn’t visible, but that could’ve counted against your Cumulative Layout Shift (CLS) score, for example.

A: Some organizations use that as an easy way to ship fixes, skipping the full development cycle. That approach encourages a culture of experimentation, like in the case of personalization, whereby marketing can plug in things and quickly measure their effect on business performance. Companies that practice A/B testing might find it simpler than server-side testing and, in most cases, it’s more affordable. It has tradeoffs, however.

To apply A/B testing on the user’s device, developers must block the page display until the script has been downloaded or executed. Or, the script is loaded asynchronously, but then you need a CSS snippet to apply opacity zero to the page. That snippet is turned off when the JavaScript runs. However, snippets time out if the JavaScript doesn’t kick in, and users would be left staring at a blank screen.

A: First, ensure that you’re collecting real user data, whether that’s CWVs or page weight. Record those metrics alongside business data, after which strategic testing can take place.

To conduct an even test, roll out an optimization to a fraction of your users. For example, if you’re compressing images, 50% of users should continue to view the old format and 50%, the improved version. You then have a more direct comparison of the transition.

That way, you also guard against mistakes that can occur. For example, YouTube Feather developers reduced their webpage to one-tenth of the size. It performed worse than expected, but a group of new YouTube users were interested in the light and data-constrained version. If those developers had enough data to begin with, they’d have identified the original problem, and the implementation would have run more smoothly.

A: Currently, Chrome is the only browser that records metrics related to loading time. To avoid privacy issues and statistical anomalies, however, the data does not reflect low-traffic sites. For example, if country A’s traffic volume is below the predetermined level for one month, the data is not recorded; but if the traffic spikes in the future, the data will be in the next Chrome report. That fluctuation can skew data so you must build a defensive design to ensure that your data collection is resilient and reliable.

A: My take is that we’ll never get to a point where we need not optimize media. When 4G came out, user expectations rose, and developers believed that web performance was no longer a concern because “the network will take care of the flaws.” That was not the case and, according to the tests conducted in the early stages of the 5G transition, likely not with 5G either. A faster network doesn’t solve the performance problem, making it even more imperative that brands keep up with media optimization.

A: Images alone are not the problem; rather, it's the inability to process the memory overhead. Therefore, we tend to dismiss images. The problems add up quickly, however, especially in verticals like e-commerce, where images are central to their strategy. For platforms like Google, large images have been cited (anecdotally) as the number-one reason for memory crashes in Chrome. Even if you compress to the maximum, every pixel in an image is still four bytes, making imagery the bulk of a website’s weight.

A: Historically, we correlated performance to loading speed because it was the easiest thing to measure, but minimal data was available on the effect of responsiveness on website engagement. The CWVs related to responsiveness incorporate First Input Display (FID), the first response of a page load, and CLS.

FID is important because unresponsive pages lead to “rage clicking” and a negative reaction to the webpage. You certainly don’t want that as a brand.

CLS refers to the page’s lifecycle and answers such questions as “Are things shifting unexpectedly?” and “Does it take more than 5 milliseconds to respond?” It’s a more well-rounded way for measuring performance by pushing beyond that initial page load into a more continuous experience perspective—hence an illuminating metric.

A: Honestly, all the CWVs will struggle with single-page-architecture apps. You're never going to get those subsequent navigations where the SPA was already up and running. In running an SPA, we pay an upfront cost in the hopes that subsequent navigations are faster. It's always slower on the initial load to use an SPA than not. Problem is, we have no standard way of measuring how fast the subsequent navigations are. From a browser perspective, they just don't exist, so only that first slower one is recorded. CLSs will accumulate.

If you have server-side-generated markup—which is great for displaying the first content faster—and then Angular initializes it, it guts all those components that you would put in the markup and then inserts them again. But Chrome deems them brand-new elements, which means that you could trigger your LCP early but then the components become potential LCP candidates again. If one of those new paints is even a couple of pixels larger than its initial size, your LCP fires long after JavaScript initialization and much later than what it would have otherwise. That scenario can occur in React, too, if the rehydration is broken.

I don't ever advise anyone to switch from one framework to another because, from my experience, no organizations have had a specific framework solve their problem by itself.

A: CLS will largely come from images, especially if height attributes are absent. Large images always cause more problematic layout shifts. The lighter a header image or banner, the higher the LCP score. Don’t ever serve large, uncompressed images, which invariably cause delays. If JavaScript is at play, serving background images instead of a content image would also raise your LCP score.

Many browser mechanisms are now available for native lazy-loading, also picture-element and source settings for serving appropriate sizes. A lot of JavaScript is still in use, but be sure to test, download, and execute the code before launching it.

A: Speed perception is hardwired. Our brain’s short-term memory retains information for at most 10 seconds before deciding to do something with it or wipe it out. That concept applies to the web, which our brain wants to feel seamless and instantaneous.

A study on task switching found that even a minor delay in website loads causes people to work 50 percent harder in terms of mental capacity. A similar study on mobile devices showed a comparable peak of user frustration. That means our brains don’t manage expectations based on a device or task—we’re frustrated either way with lengthy load times.

A: Several years ago, I directed an EEG study to find out if performance affects mobile users’ long-term perception of retail brands. Participants were asked to do standardized shopping tasks on several mobile sites, where the only differentiator was perceived rendering time. Interestingly, we found that those who experienced a slower site used three times more negative adjectives to describe the brand—boring, tacky, unhelpful—than those who experienced the faster version of the same site.

Literally hundreds of potential performance metrics are out there. To enhance user-perceived performance, you should focus on metrics that answer these three questions: is the page loading, can I use it, and how does it feel? Start Render is a good metric to consider, along with Google’s Core Web Vitals (Largest Contentful Paint, Cumulative Layout Shift, Total Blocking Time, and First Input Delay), called CWVs. What counts the most is that you evaluate those metrics in relation to your pages and ensure that the results are meaningful.

A: There’s been a lot of good research among news and media sites. You can find several in WPO Stats, an aggregator of performance case studies. One recurring finding is that degradation in performance correlates to reduced engagement and greatly diminishes the likelihood of return visits. That’s another confirmation that poor online experience causes people to develop a lasting negative perception of a brand.

A: When businesses ask me what’s wrong with their site performance, I usually start by looking at three things.

First up is server response time. If you’re focused on the front end, it’s easy to overlook this factor, but slow back-end times push out all your other metrics.

Second is new assets, such as animated GIFs, videos, and large images. Their file sizes could slow down loading across pages, devices, and browsers.

Finally, third parties. These days, some pages contain literally hundreds of assets, 90 percent of which could be from third parties. It’s not enough to look at the number or size of third-party assets on your pages. You must find out how many of those assets are blocking scripts. Also, be aware that even a nonblocking script can hurt user experience if it has an excessive Long Tasks time. A Long Task is a JavaScript function that takes more than 50 milliseconds to execute. Longer than that could lead to a disappointing user experience. If you can’t control how third-party assets are served, user experience might suffer.

A: In a study I worked on a few years ago, where we explored user response to various image formats, we discovered that almost half of our participants would start interacting with a page once the text appeared, but all the remaining participants would wait until most or all the images had loaded. That was a significant finding: while visual assets are loading, many people are just passively waiting for them all to render. It definitely makes you think harder about how you’re serving images!

In another study I did with Google, we threw about a million beacons’ worth of user data into a Google machine-learning system and found that the sessions that converted tended to have fewer images. In fact, the converted sessions had on average 19 images per page; the unconverted sessions had 31 images per page.

A: What I love about the CWVs is that they aim to address a problem in our industry—the proliferation of metrics—and offer a simplified bundle of metrics as a starting point.

If you care about how quickly you’re serving media assets, Largest Contentful Paint (LCP) is a good metric because it lets you know when your largest visual element—image or video—is rendered in the viewport.

If you care about how smoothly your visual assets are rendered, Cumulative Layout Shift (CLS) captures how often a user experiences unexpected layout shifts as the page loads. Elements like ads and custom fonts can push important content around while a user is already reading it. A poor CLS score could be a sign that the page feels janky to your users.

Be aware of a few gotchas with LCP and CLS. For example, they can be thrown off by image carousels and pop-ups. You should validate your CWVs with a tool like WebPageTest or SpeedCurve, which can show you what the visual elements are and how they actually behave on the page. That way, you can ensure that the CWVs are measuring what’s meaningful for your unique pages.

Also important, CWVs are only supported in Chrome-based browsers, so if many of your visitors use other browsers, you need to track other metrics.

A: Circling back to the EEG test I mentioned earlier, if your site is slower than people expect, your brand still bears the blame. It’s important to remember that just because a network promises 10x greater download speeds, or whatever claim it makes, doesn’t actually mean pages will render 10x faster. Latency is still a huge issue, and with pages containing more assets than ever, the problem of latency is only going to get worse.

Pages keep getting bigger and more complex year over year, which pretty much negates bandwidth improvements. In fact, if you live outside an urban center and are accessing the Internet on older infrastructure, you could actually be having a slower experience than ten years ago! That’s a real challenge for brands because people are expecting the faster experience promised by Internet providers. So, be sure to conduct webpage tests and see how your pages actually perform in the real world.

A: If your page takes five to 10 seconds to render, the metrics hardly count any more because visitors might’ve bounced already.

The first performance metric that I like to examine is Time to First Byte (TTFB), which measures the latency time spent on the server and network. Some of that is beyond your control, but you can shorten TTFB by delivering mostly static assets from as close by (geographically) to visitors as possible. Content delivery networks (CDNs) ensure that proximity. For dynamic pages, fix the bottlenecks on the server.

A server response ushers in the second set of more user-observable metrics, which measures how quickly visitors spot background colors, the first pixels, and content layers. One newer metric is Google’s Largest Contentful Paint (LCP), which depicts the earliest meaningful moment in content rendering.

Displaying pixels as fast as possible requires serving the most critical parts of the page first, ideally alongside HTML to minimize back-and-forth browser trips. So, deliver noncritical content in a way that doesn’t block that process, such as by asynchronously loading scripts or in a deferred manner.

Once the content is delivered and functional, the next group of metrics to look at is Time to Interactive (TTI), which is now called FID for First Input Display. It measures the time it takes for the components to receive user interaction and to respond to user input. You can score higher by reducing the page’s JavaScript code, especially if it impacts the look and feel.

JavaScript is often problematic because it could create a performance bottleneck if the UI depends on the loading and execution of JS code for key components to function. Trimming JavaScript and relying more on HTML and CSS is the best solution.

A: The average video weight is increasing dramatically every year, more so on mobile than on desktop. That scenario means that mobile devices need higher-resolution videos than desktop, but we lack effective, simple tools to address that issue. Delivering video fast is a challenge, and a lack of support for controlling video size with HTML complicates matters. Consequently, mobile devices are getting larger video files than necessary.

Unlike video, the tools for delivering images with HTML alone are extremely effective. Since around 2016, responsive images have been working on more browsers. Plus, you can deliver an appropriate size on HTML by setting <src> and <size> attributes on <image> elements. Why not also apply all your options with CSS and SVG for a rich look? Additionally, new and well-supported image and video formats, such as WebM, WebP, and AVIF, help deliver media faster and keep their weights in check.

Furthermore, services like Cloudinary, which efficiently compress media and deliver pages, are a tremendous help, especially for large e-commerce sites.

A: Responsiveness is the time a site takes to respond to user interaction—users notice delays if the lag exceeds 200 to 300 milliseconds. For a good FID score, Google suggests less than 100 milliseconds. The best practices I mentioned, including removing the JavaScript, count a lot. FID, which relates less to runtime but more to timeline, doesn’t replace TTI. Both are important metrics.

A: Media is not the only contributing factor to an LCP score, albeit an important one. If LCP is slow due to imagery or video, optimizing their files and means of delivery is a good bet.

Optimized media notwithstanding, factors that contribute to delays in earlier metrics also impact later ones. If scripts and styles are noncritical for the initial page, avoid loading them in a blocking manner. Reduce the number of round trips to the server for the site to begin rendering content. Even if you can optimize all the UI-Related scripts and styles for delivery, remember that other teams are involved between that step and production. On e-commerce sites, for example, marketing would have script managers, a live-chat widget and one for reviews, etc. Moving those operations to the server side can significantly improve performance, but complexity arises if developers and other teams are constantly implementing product enhancements.

A: First of all, user experience will suffer. Beyond that, search engines like Google are starting to factor performance metrics like its Core Web Vitals (CWVs) into page ranking. For those and other reasons, it'd be wise to figure out where your site stands now from a performance perspective and check out the great tools, such as PageSpeed Insights, that recommend changes you can make if you come up short.

Performance metrics have captured tremendous attention in the last five years. Even though the web community is still debating which metrics matter most, I believe that momentum will continue.

A: It’s easy to point the finger at images as the cause of a slow site, but the problem is more nuanced. Most companies I’ve audited have worked hard to accelerate page loads with responsive images, but they haven’t dipped into their pockets for a media platform, missing out on efficient optimization of media and on the basics, such as by inadvertently lazy-loading key content.

A shortsighted scenario is that businesses shy away from optimizing key product images that must be front and center but which take five times longer than normal to load. Applying lazy loading as a one-size-fit-all rule ruins LCP scores and the overall user experience.

A: Companies rely too much on JavaScript, which is heavy and expensive. What often happens is that one megabyte loads slowly, resulting in an enormously bloated website.

Developers must focus on serving the end-user. Before committing to a single framework like React fix, they should perform a technical audit, and management should do a business analysis. Isolating technical decisions from their effects on the business can cost companies a bundle.

A: Nearly every inquiry we’ve received in 2021 relates to the CWVs. People panic because that Google decision can really change the game. I’ve been advising against panic. Those measurements are just one of many ranking factors. Google will also characterize the quality of site content and, if two sites offer similar content, Google will defer to the CWVs as the tiebreaker.

Businesses should also aim for high rankings on a per-page—not on a site—basis by ensuring that the pages they want ranked load fast, especially since Google focuses on page-level speed. Problem is, the rankings are all based on the Chrome user-experience report to the exclusion of traffic on Firefox or Safari.

Additionally, businesses must take into account consumers who are on different browsers and devices, also visitors from various locations. Even if the majority of visits are from powerful maps on Safari, test on a slow Android device, too. Also, remember that the aggregation is global, meaning that audiences on the other side of the world might hold back a site’s rankings.

A: Every company’s priorities for performance optimization are unique. Businesses keen on accelerating page loads should focus on content delivery and metrics like LCP. Once a measurement is in hand, identify a page’s primary goal and work backward from there to form a hypothesis on why that page might be loading slowly, and then fix the issue. Rinse and repeat.

A: You can test performance in three ways:

• Proactively — Find out a page’s loading speed during the development phase.
• Reactively — When deploying a site, test it to ensure that it’s not slower than it was yesterday versus the day before.
• Passively — Keep testing outside the performance process, for example, find out what happens if image X goes offline. Promptly address issues that slow down the site.

A: Optimizing websites is daunting, especially those that comprise countless pages. Visitors don’t know where to go from the home page and how to cross-reference patterns across pages. The Site Speed Topography Sheet helps you overcome the inefficiencies in the workflow.

I discovered that the solution is to break down pages by type and category. Afterwards, compare the pages to one another and capture the same metrics for them all. With those measurements in hand, dig deeper for differences. For example, if the home page loads much more slowly than the page with the first article, the problem is likely on the server—and you need not hunt around the site for the issue. Just plot the bar chart; the gaps will reveal the culprits.

That simple yet helpful trick blows my clients’ minds. They’re amazed that, to identify the issue at hand, I just look at the spread without even accessing the site.

A: Fonts are powerful displays being embraced far and wide. The good news is that they’re becoming increasingly less problematic. Before, it was a binary decision: use web fonts or have a fast website. Now, more and more, you can have both by optimizing performance self-host fonts on the same domain as the HTML. If you can’t self-host because of a licensing issue, just load the fonts asynchronously.

A: Many companies have adopted digital asset management (DAM) solutions that aren’t visual optimizers. But then those companies must send images back through three different domains—an inefficient and costly process. E-businesses must keep in mind the difference between file storage and file delivery, always prioritizing efficient delivery of images.