Fronteers Spring Conference: Web performance matters
Friday April 1st I attended the first ever Fronteers Sprint Conference in EYE Amsterdam. The main theme was web performance and as front-end developer I am always curious about this (actually is my favorite topic), so I could not miss it. The conference was separated in three parts: Visual, Accessibility and Technical performance and each part contained three talks and discussion panel.
Visual Performance
The very first talk of the day was by Tobias Ahlin who worked for Spotify and GitHub. The talk was all about animations and transitions. Achieving a good animation in the browser is really difficult, especially at60 fps on mid-range mobile device. To do that we have to use only several CSS properties: transform, opacity and filter. Those three are GPU optimised and don’t trigger layout and paint on change, only composition (which is not so expensive).
Another important point was when we cannot animate some property we always can extract and compose animation in separate elements. For example animation of border is just another element with transform:scale. Another example for heavy animation that is very popular nowadays is box-shadow of element, we should use two separate elements and just change the opacity of the second to achieve the best performance.
A relatively new property will-change can give a hint to the browser what we are going to change it later (in animation), so the browser will optimize the transition through the GPU, but that doesn’t mean we can set will-change on the whole page.
The second talk was given by Paul Bakaus, the creator of jQuery UI, who currently works for Google. The talk really blew my mind. He explained how the human brain works and perceives information. Actually time is just an illusion, so the term performance is abstract and always depends on the context. Nobody cares about how fast your site is, just how fast it feels.
The subject of the third talk was web fonts. Five years ago it was almost impossible to use web fonts and the typography of all pages looked almost the same, but nowadays we have thousands of fonts and designers usually use several in their creations. Some pages even load 400kb of fonts, which I think is ridiculous. We have to use fonts carefully and choose the right formats (for example woff and woff2 have really good compression) and subsets. Another good practice is to use fallback fonts and eventually the new prefetch API, which can prioritize fonts to decrease page load time significantly. Also don’t forget that web fonts are an enhancement, so they must not block our page while it loads (a flash of unstyled content).
Accessibility performance
The accessibility panel was relatively unknown for me. This is the kind of topic everybody talks about but actually almost nobody does it the right way. Marcy Sutton from the Angular team (ngAria module) gave a very helpful talk about common mistakes developers and designers make.
Some takeaways:
- Don’t block the UI thread
- Don’t depend on JS for everything
- Don’t wait for JS to build the DOM
- Use thwbrowser’s default elements as much as possible (buttons, HTML5 input, focus style)
- Create universal (isomorphic) JavaScript apps
- Enable core functions of your site even without JS
- Do tests, the easiest way is VoiceOver, also there is a new accessibility panel in the Chrome devtools
Karl Groves talked about the same problems. I just want to show you the below videos. The one one the left does a accessibility test on CNN.com using VoiceOver, and the right video compares native browser dropdown widget and a custom dropdown, in this case jQuery UI.
Technical performance
The main topic of the technical performance panel was HTTP2, almost every one of the three speakers talked about it.
As we know, HTTP1 was designed about twenty years ago and at that time a usual web page was just HTML and a few images. Nowadays a regular page has dozens of images, videos, ads served by publishers and 3rd party content, so HTTP1 just doesn’t work optimal anymore.
HTTP2 can bring huge performance benefits with techniques like multiplexing. Some even argue that all the best practices (CSS/JS minification, concatenating, image sprites and domain sharding) we do for HTTP1 are useless or even harmful using HTTP2. This would mean we can also remove or simplify some of our build tools (like browserify or webpack).
Browser support is pretty good, all evergreen browsers have already implemented it.
Closing thoughts
Web performance is user experience, and we as developers owe the best UX to our customers and users. It is really worth the effort.
Web performance is important because: Speed Sells
— Kristian Sköld
Originally published at www.elements.nl on April 4, 2016.
