On Friday 1 April I attended Fronteers Spring Conference at EYE in Amsterdam. The first of its kind, after 8 two day conferences in autumn. IMHO, this one day spring thing is a fantastic format worth pursuing again!
Fronteers has in recent years always taken place in Tuschinski, an old cinema with a very cool interior, an eclectic mix of styles like art deco and Jugendstil. Cinema equals comfy seats. The cool thing about the new venue, also a cinema, was that most of us had to get on a boat (for five minutes or so) to get there.
The day was all about web performance (hashtag #perfmatters): making websites faster. It was divided into three sections, each with three 20 minute talks: the first on visual performance, the second on performance and accessibility and the last technical performance. Each section ended in a panel discussion with MC, eh, host, Phil Hawksworth. The day was then concluded with a keynote talk about money and the business case for web performance.
Visual performance
Tobias Ahlin started the day off with some great tips for better performing animations (slides). He recommended to only ever animate opacity, transform and translate properties, and suggested the use of pseudo elements to resemble animating other properties. An example: you cannot transition/animate border, but you can add a pseudo element, make it look exactly like a border and transition/animate that instead.
Paul Bakaus discussed the perception of performance. How a person experiences speed, he argued, may be a more important thing than actual, measurable numbers. Long activities, he said, can be memorised as short, and short ones can be memorised as long. He also emphasised how important context is for this: where and how you experience time can also influence what you feel about an interaction taking a certain time.
Bram Stein then talked about web typography, and more in particular the timing of custom font loading (slides). Browsers (and developers) make choices about what to do when your CSS wants to use a font that is not on the user’s system, the main options being FOIT or FOUT. FOIT is the flash of invisible text: a white screen until the requested font has downloaded. FOUT is the flash of unstyled text: rendering content in a fallback font until the requested font is downloaded and available. I could not agree more with him that FOUT is the best strategy: displaying any content at all is more important than displaying it in your font of choice. Web fonts are an enhancement. Bram stressed we should optimise how browsers load fonts with code, as most browser’s defaults are not great. This can be done with prefetch headers, the Font Loading API or its polyfill, Stein’s own Font Face Observer.
Accessibility
Marcy Sutton talked about ensuring accessibility in apps that rely on JavaScript (slides). To get websites to perform well and accessibly, she encouraged us to think about how you impact users (eg those that want or have to interact with their keyboards or assistive tech). This means we should not only focus on the DOM tree, but also on the accessibility tree. In terms of performance, if your app relies on JavaScript to be usable with a keyboard or AT, she stressed, make sure this JavaScript is in the critical path and load it before the rest of your app. She also recommended to prefer native elements above custom ones, as they often come with free accessibility benefits. I feel this is especially important when thinking of Web Components.
Karl Groves said that an important reason that we optimise for performance is because our clients want it and they’ll leave our sites or refrain from buying our stuff if we don’t and our website takes too much time before it becomes accessible. He said research (on physical businesses) showed that up to 83% could indeed leave a business if they had difficulty accessing it, and that this applies to the web. The most important question he said developers should ask is: “What is this thing and what does it do?”. This makes lots of sense, because the answers to those questions will likely remain the same whatever the device/context/user. Like Marcy, Karl mentioned the benefits of using native elements, and he showed an awesome video that compares how ATs make sense of real <select> elements and their jQuery UI counterpart.
Estelle Weyl talked about how responsive web design is not (only) about making it ‘squishy’: with sites getting larger in file size, page weight really matters (slides). An example she showed is that of YouTube Feather, a super light replica of YouTube (100k instead of 1200k) that someone at Google made. She also explained how responsive images save time in both decoding and transferring, and said we should consider our user’s battery lives. Design, Estelle concluded, is not about making it pretty, it is about making it usable and intuitive (and I guess that includes fast).
Technical performance
Yan Zhu went into the speed of TLS: when it was first on the table, people said it should not be deployed as it would be too slow. This is changing, with the likes of Netflix (which accounts for a huge part of bandwidth usage, especially in the US) switching to HTTPS. She said session resumption makes TLS less expensive by saving roundtrips. HTTP2 will also have impact as it allows multiple TLS connections at ones (and all regular supporting browsers will require HTTPS for it). HTTPS has in recent months become much easier to deploy on any site, with the public launch of Let’s Encrypt, which has issued over 1.4 million certificates since its launch, which, in number, makes it one of the largest CAs out there.
Tobias Baldauf showed us some very clever tricks to get better performing images, including those ‘hero’ images that we all love. There were three parts to his proposal: use HTTP2, use progressive JPGs and optimise the ‘scan levels’ in those JPGs. Tobias showed a number of comparisons showing real speed differences between HTTP1.1 and HTTP2, and between progressive JPGs / optimised progressive JPGs and ‘regular’ JPGs. With HTTP2, progressive JPGs and optimised scan levels, he showed, you can get a recognisable image on screen after only 15% of the image has downloaded. Wow.
Fronteers veteran Mathias Bynens blew everyone’s mind by explaining a very different phenomenon related to comparing the timing of downloads: the so-called timing attack (slides). He showed a number of different ways this can be used, but the main idea comes down to making requests to a site you think your victim visited, and use differences in server response times to find out about their status on that site (e.g. that they are logged in, have an account, or even have a certain age).
Round-up
Kristian Sköld ended the day with an interesting keynote about a subject that was hardly discussed in the other talk: money. If you need your organisation’s support for spending time on web performance, you will want to make a business case and discuss money, as that is likely what the management will want to know about. Whatever you do, there should be a business case behind it, Kristian said. If you correlate pageviews/load time statistics with bounce rates, you will likely find that more people bounce if the site takes longer to load. This is a metric marketing/business people can work with and ultimately, approve the budget for. If better performance can shave money off the marketing budget, Kristian explained, making more money available to the IT/web department becomes simple math.
My takeaways:
- We should be conscious of and minimise the amount of bytes we send down the wire
- Page speed is not just numbers, perception can also be a factor
- Fast websites do not have to be insecure: TLS is getting faster (so fast that Netflix is moving to it) and HTTP2 (HTTPS-only in all major browsers) lets us benefit even more from progressive JPGs
- Fast websites do not have to be inaccessible: resources that aid accessibility should be part of the critical path and if we use native elements, we get a lot of accessibility for free
- Paying attention to the amount of bytes sent to users can also help evil companies to track them
What a fantastic day this was. We learned about keeping file sizes down and minimising bytes sent over the wire, about using the right tools for the right job and about advantages of HTTP2 and HTTPS. There were both specific and general talks about web performance issues, and as many as three accessibility talks. Lots of variety! Well done, team Spring Conference!
Comments, likes & shares
No webmentions about this post yet! (Or I've broken my implementation)