With images making up a whopping 65% of all web content, page load time on websites can easily become an issue. Even when properly optimized, images can weigh quite a bit. This can have a negative impact on the time visitors have to wait before they can access content on your website. Chances are, they get impatient and navigate somewhere else, unless you come up with a solution to image loading that doesn’t interfere with the perception of speed.
Web performance is something I care deeply about both as a developer whose work affects millions of people around the world, and as a user who often accesses the web on slow & unreliable connections. I have regularly and loudly complained that the BBC News website is unnecessarily slow, so when I was given the opportunity to help rebuild one of the most visited pages of BBC News —the front page— I jumped at the chance.
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.
Before the browser can render content it must process all the style and layout information for the current page. As a result, the browser will block rendering until external stylesheets are downloaded and processed, which may require multiple roundtrips and delay the time to first render. See render-tree construction, layout, and paint to learn more about the critical rendering path, and render blocking CSS for tips on how to unblock rendering and improve CSS delivery.
Images play an important role on the web today. Imagine a world without images on our web pages! High quality images can really make a website stand out, but unfortunately they come with a price to pay. Due to their large file sizes, they are bulky to download and result in slow page load times. If I'm a user with a low bandwidth connection, it can be a pretty poor experience.
Browser support for the picture specification is landing and as Marcos Cáceres said, it is time to “go forth andall the things!” Except you shouldn’t. You shouldn’tall the things.
I'm probably a bit rare in that I rather enjoyed trying to keep up on the responsive images thing. It's an interesting problem that bred lots of interesting solutions. The whole thing is starting to wrap up now though, now that the official solutions are:and friends with srcset and sizes The problem is: I don't really get it. I thought the original picturefill was pretty simple. List a bunch of sources with media queries. First one to match, that's the one that gets used. That made sense to me. This new stuff is a bit different. Solvable problem! Just like everything else, I need to figure it out.
Last sunday I sat down on my couch, got comfy and started reading up on the new srcset and sizes syntax. I wanted to understand it and then starting to use it now with the awesome picture/srcset/sizes polyfill picturefill 2.
Something that has really struck me this past year is how little we as a web industry know about the ways in which people (yep, real people, not other web developers) access the Internet, and tangentially, how antiquated our methods of delivering content to users really are.
On Twitter last week, Bruce Lawson asked people to write up their performance optimisations. I’ve had some bits of time to make some improvements to traintimes.org.uk, and so here is a short essay/notes (I don’t get much free time at present for various small-person-shaped reasons) on how this site is currently seven times quicker than the official site on a mobile:
This article demonstrates a technique to get content in front of visitors as quickly as possible by asynchronously downloading stylesheets to prevent them from blocking page render.
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.
Serving a website seems pretty simple: Send some HTML, the browser figures out what resources to load next. Then we wait patiently for the page to be ready.
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
I started this post two weeks ago as a simple "How to use SSR to boost performance" article. After hours of profiling and consulting people smarter than me, I know one thing. Server-side Rendering is more nuanced than you would like.
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.
I’m at Shop.org this week, having really interesting conversations with online retailers. What I love about talking with this crowd is that – like me – they're super focused on user-perceived performance. Not surprisingly, we have a lot to talk about.
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.
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'.
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.
Five Techniques to Lazy Load Images for Website Performance — SitePoint
Introducing a faster BBC News front page | Wildly Inaccurate
SpeedTracker
Optimize CSS Delivery | PageSpeed Insights | Google Developers
Service Workers: Dynamic Responsive Images using WebP Images | Dean Hume
Don’t use
#133: Figuring Out Responsive Images | CSS-Tricks
The new srcset and sizes explained | Martin Wolf — Frontend Web Developer
filamentgroup/criticalCSS: Finds the Above the Fold CSS for your page, and outputs it into a file
Performance Tooling Today
Beyond the Bubble: Real world performance – Building Calibre
traintimes.org.uk performance notes
Loading CSS without blocking render by Keith Clark
The State of Online Retail Performance
Optimising the front end for the browser
The Critical Request | CSS-Tricks
Progressive Image Rendering
Why its tricky to measure server side rendering performance
The State of the Web – Karolina Szczur – Medium
SpeedCurve | A retailer's guide to web performance
image-trace-loader
How to use SVG as a Placeholder, and Other Image Loading Techniques
The Cost Of JavaScript – Dev Channel – Medium
AddyOsmani.com - JavaScript Loading Priorities in Chrome
Web Perf Links
WPT-Compare - WebPageTest comparison URL generator
jsPerf: JavaScript performance playground