WebPageTest is an incredibly useful resource for any web developer, but the information it provides becomes much more powerful when monitored regularly, rather than at isolated events. SpeedTracker runs on top of WebPageTest and makes periodic performance tests on your website and shows a visualisation of how the various performance metrics evolve over time.
I recently was invited to give a talk at Spotify in Stockholm, Sweden to the local developer community. My talk centered around performance, since that’s the topic that fills my days at Google, specifically site and application performance.
While almost half of all consumers browse via their phones, only 1 in 5 complete transactions on mobile (page 5). • Optimal load times for peak conversions ranged from 1.8 to 2.7 seconds across device types (page 6). • Just a 100-millisecond delay in load time hurt conversion rates by up to 7% (page 7). • Bounce rates were highest among mobile shoppers and lowest among those using tablets (page 9). • Optimal load times for lowest bounce rates ranged from 700ms to 1.2s across all device types (page 10). • A two-second delay in load time hurt bounce rates by up to 103% (page 10). • Pages with the lowest bounce rates had start render times ranging from 0.9 to 1.5 seconds (page 12). • A two-second delay correlated with up to a 51% decrease in session length (page 14).
Recently my whole team got a chance to spend some time spiking out our proposed upgrade to our codebase, potentially using React. This really got me thinking about how we should build our front end. Pretty quickly I realised that the browser would be a large factor in our approach and equally large bottleneck in our knowledge.
Before getting to the psychological part of performance optimisation, let's answer one question: what is web performance? For the majority of frontend developers, the answer would cover things like page response time, speed of animations, load times.
Stephan Lavavej has a great page outlining the difference between fancy interlacing and plain old progressive rendering: There are four ways to transmit an image over the Internet. Over a fast connection there won't be any apparent difference, but over a modem connection the difference is stunningly obvious. Choosing the right way can make your connection seem much faster than it really is. Wait until every bit of image data has been sucked through the modem before displaying the whole image. So blindingly dumb that not even Internet Explorer does it. Display image data as it is received, resulting in a top-down filling in of the image. One variant -- the one that everyone has seen -- of JPEG does this. This is noninterlaced display, and both GIF and PNG are capable of it as well. Non-interlaced images are smaller than interlaced images. Use a one-dimensional interlacing scheme. This is how GIF interlacing works. Every eighth horizontal line is transmitted in the first "pass", filling up the dimensions of the image in 1/8th of the time that the entire image will take to download. The next pass transmits every fourth line, making the image less distorted. The next pass transmits every second line, making the image even less distorted, and the fourth and final pass transmits the remaining lines. Use a two-dimensional interlacing scheme. This is how PNG interlacing works. Instead of four passes through the image, PNG makes seven passes. In 1/64 of the time that the whole image will take to display, one pass is already completed, showing the image in a very rough manner. Successive passes fill in more information, never distorting the pixels by more than a factor of two to one. Here's a demo of simple progressive as-received rendering: And here's a demo of the superior PNG style two-dimensional interlaced rendering: You don't get this for free, of course -- turning this feature on adds about 20% to the size of PNG images, and about 10% to the size of JPEG and GIF images. Whether this improved rendering behavior is worth the bandwidth cost I leave as an exercise to the reader. I am not aware of any browsers that actually bilinearly interpolate the low-resolution incremental images, as shown in the sample screenshots on Stefan's page. But that would be really cool! Why doesn't Firefox add this? NEXT This Just In: Internet Makes Books Obsolete PREVIOUS UI Follies, Volume III Written by Jeff Atwood Indoor enthusiast. Co-founder of Stack Overflow and Discourse. Disclaimer: I have no idea what I'm talking about. Find me here: http://twitter.com/codinghorror
The Internet is growing exponentially, and so is the Web platform we create. Often though we fail to reflect on the greater picture of connectivity and contexts the audience of our work might find themselves in. Even a short glance at the state of the World Wide Web shows that we haven’t been building with empathy, situation variability awareness, let alone performance in mind.
performance budgets are an essential but under-appreciated part of product success and team health. Most partners we work with are not aware of the real-world operating environment and make inappropriate technology choices as a result. We set a budget in *time of
As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this post, I’ll cover why a little discipline can help if you’d like your site to load & be interactive quickly on mobile devices.
I remember going to a local mall in New Jersey and walking into a T-Mobile store back in 2014. I had just moved to the US the previous year, and I was just about sick of using Google Voice to keep in touch with people. Opening my laptop just to send a text or make a call wasn't very convenient. Unfortunately, it was all I could afford to do because I didn't even have a working phone at that time. I was a recent graduate and very unemployed. So I said to myself that the minute I get hired for a job I was going to get myself a new phone.
You might have heard about features like “Hooks”, “Suspense”, and “Concurrent Rendering” in the previous blog posts and talks. In this post, we’ll look at how they fit together and the expected timeline for their availability in a stable release of React.
Chrome on Android’s Data Saver feature helps by automatically optimizing web pages to make them load faster. When users are facing network or data constraints, Data Saver may reduce data use by up to 90% and load pages two times faster, and by making pages load faster, a larger fraction of pages actually finish loading on slow networks. Now, we are securely extending performance improvements beyond HTTP pages to HTTPS pages and providing direct feedback to the developers who want it.
One of the most impactful things we can do to improve page performance and resilience is to load CSS in a way that does not delay page rendering. That’s because by default, browsers will load external CSS synchronously—halting all page rendering while the CSS is downloaded and parsed—both of which incur potential delays. Of course, at least a portion of a site’s CSS should be loaded before the page should be allowed to start rendering, and to get that initial CSS to the browser immediately, we recommend inlining (or HTTP2 server-pushing) the CSS. For sites with a small amount of overall, that alone might be enough, but if the CSS is large (say, bigger than 15 to 20kb), it can help performance to split it up by priority. Once split, less-critical CSS should be loaded in the background—AKA asynchronously. In this post, I aim to describe up our preferred way to do that these days, which has actually been around for years.
Before we talk about what font-display is, let's talk about the lifetime of a web font. For a super detailed explanation of where web fonts fit in the browser rendering process, Ilya Grigorik has an amazing blog post on web font optimization. But, if we're just trying to understand the basics, there are basically three parts to it:
Quickly generate the correct URL for comparing WebPageTest runs. It should also work with custom instances and SpeedCurve URL's.Simply enter a set of test URL's (e.g. https://www.webpagetest.org/result/191128_E6_8f81ddf9ba2ba82ef814fff7baaa5005/) and click 'Generate'.
Web performance has been a hot topic in web development and browser engineering since the first public web pages. The first book on the topic, Web Performance Tuning: Speeding Up the Web was published in 1998, with Steve Souders kicking off the Web Performance Optimisation industry when he published his book High Performance Websites nine years later in 2007.
jsPerf aims to provide an easy way to create and share test cases, comparing the performance of different JavaScript snippets by running benchmarks. For more information, see the FAQ.
The size of individual GraphQL query strings can be a major pain point. Apollo Server implements Automatic Persisted Queries (APQ), a technique that greatly improves network performance for GraphQL with zero build-time configuration. A persisted query is an ID or hash that can be sent to the server instead of the entire GraphQL query string. This smaller signature reduces bandwidth utilization and speeds up client loading times. Persisted queries are especially nice paired with GET requests, enabling the browser cache and integration with a CDN.
An online lecture course by Scott Jehl Learn to analyze site performance, fix issues, monitor for regressions, and deliver fast, responsive designs from the start.
We’re going to cut straight to the chase. Modern browsers can animate four things really cheaply: position, scale, rotation and opacity. If you animate anything else, it’s at your own risk, and the chances are you’re not going to hit a silky smooth 60fps.
Tarantool - Get your data in RAM. Get compute close to data. Enjoy the performance.
SpeedTracker
Aerotwist - Don't Guess it, Test it!
Performance Tooling Today
The State of Online Retail Performance
Optimising the front end for the browser
Secrets of High Performing Teams: Science Edition • Jez Humble - YouTube
Trick users into thinking your site's faster than it is | Creative Bloq
ImageOptim — better Save for Web
Progressive Image Rendering
The State of the Web – Karolina Szczur – Medium
Can You Afford It?: Real-world Web Performance Budgets – Infrequently Noted
The Cost Of JavaScript – Dev Channel – Medium
Why Bandwidth Still Matters - DEV Community 👩💻👨💻
SpeedCurve | JavaScript Dominates Browser CPU
React 16.x Roadmap – React Blog
AddyOsmani.com - JavaScript Loading Priorities in Chrome
Chromium Blog: Chrome Lite Pages - For a faster, leaner loading experience
leeoniya/dropcss: A simple, thorough and fast unused-CSS cleaner
Create performance budgets and set alerts | SpeedCurve Support
The Simplest Way to Load CSS Asynchronously | Filament Group, Inc.
Font-display playground
Web Perf Links
Metrics
DebugBear | Front-end website monitoring
WPT-Compare - WebPageTest comparison URL generator
Is it time for a Web Performance rebrand? – Simon Hearne
jsPerf: JavaScript performance playground
Automatic persisted queries - Apollo Server - Apollo GraphQL Docs
Maximally optimizing image loading for the web in 2021
Lightning-Fast Web Performance: an online lecture series from Scott Jehl
Access simonmcmanus.com. Simon McManus
critical/README.md at master · addyosmani/critical · GitHub
Stick to Compositor-Only Properties and Manage Layer Count
High Performance Animations - HTML5 Rocks
Web Directions Lazy Load
Will Hotjar Slow Down My Site? – Hotjar Documentation
Style scoping versus shadow DOM: which is fastest? | Read the Tea Leaves
SEO and Web Performance
Interaction to Next Paint (INP)
Will Serving Real HTML Content Make A Website Faster? Let's Experiment! - WebPageTest Blog
Home | wsrv.nl