Blog post related to this talk, but not about the whole talk: http://www.filamentgroup.com/lab/weight-wait.html Makes it a bit more visual though 🙂
Responding. That sounds passive, but that’s hardly the case if you build across devices. It’s actually a quite active task. The more we anticipate our users, the better services we can deliver. Our interfaces need to respond to viewport sizes. Fluid images, videos, media queries.
Along that we need to go qualifying the features that are needed to not break the interfaces.
Don’t make presumptions about things in a user interface being available.
We need to deliver first. How to render a page progressive.
Performance priorities. The web broadens our reach. It’s common to see sites that are build very exclusively for one platform.
We are an exception between our users. More users on Facebook use 2g than 4g.
The average webpage is 2mb. Not website. Optimize, minify, and gzip. Optimize everything you can. Don’t optimize images, offer different versions for different resolutions. Use things like srcset or picturefill.
Reduce framework bloat.
Reduce dependencies, make custom builds. Sometimes we don’t need them at all.
Optimizing only gets us so far. We need to update how the interface feels too.
“The problem is latency, not bandwidth”. Latency depends on type of connection WiFi/3g and time since last contacting a tower. Can differ between 150ms and 2 seconds. Also geographically based on where the server is located.
Prioritize for progressive rendering.
Avoid making render blocking request.
We have some nice tools to help us, like WebPagetest. “Start render” is the time until something is shown to the user. Timeline tool to see how it progresses.
Cram your initial view into the first 14kb of your HTML. Lets prioritize what we can fit into it and render something useful right away.
Google PageSpeed Insights.
Prioritize on the top part of the page.
How do we detect this? Bookmarklet by Google. Using tools like Grunt to extract the critical CSS and putting it into files.
Load the rest in a non-blocking manner
You could also use async or defer attributes that you can apply to a script tag.
Avoiding the FOIT (Flash of Invisible Text).
Can happen if we use custom fonts. Browsers hide the text in a page while a custom font is being loaded, showing the users an empty page. Standard groups are trying to come up with alternatives. Safari on iOS doesn’t support this though. Listening for when fonts have loaded.
New feature in WG (working group?): font-rendering: swap 3s;
Case study: Wired.
Wired recently had a redesign. If you check the site in WebPagetest, the content starts loading after 12 seconds on a 3g connection.
Can this be optimized? I put a copy of the site on a test server with a really similar timing to the original. Adding the optimizations – also for the ads, which was pretty hard – critical CSS, asynchronous, fallback fonts.
Managed to get it down to 4.6 seconds.
Weight doesn’t need to increase wait.
How we load stuff matters more than how much stuff we load.
I showed a lot of workarounds today. HTTP2 makes a lot of what we do today unnecessary. server push is what we do with inlining resources now.
The number of active requests which we try to increase with CDNs aren’t necessary anymore as are spriting, or concatenating. Besides that we are moving to SVG for icons now. HTTP2 will never load in older browsers, like IE10. We have to figure out ways to support the forward features and keep backward compatibility.
It won’t happen overnight. something we need to think of ahead of time.
We can build beautiful, complex interfaces without excluding people. It’s our job. The interesting part of it, if you ask me.