April 3 @ 10:15am
An Event Apart Seattle 2018
Ultimately what he’s talking about today is design.
In most cases we want to help someone solve a task, so we work to reduce friction between the user accomplishing a task. We want to enable someone to do what they need to do online with as little pain or annoyance as possible.
Some of the great hallmarks of UX are:
- Streamlined flow
- clear, concise copy
- low cognitive load
- faster performance
Now A Story…
Back in March of 2012, Apple unrelieved their iPad 3 (the one with high res retina display). At the time this was announced he was there for a conference and decided to go to apple.com using the hotel wi-fi to check out this new product. It took him 30 minutes to load the iPad page over the hotel wi-fi. The delay wasn’t do to the hotel internet – the culprit was Apple’s developers. They had put retina size images in the markup as the image tags and served that to everyone, even if someone was on a mobile device which at that time was probably an 800px wide screen or so.
This is basically a tax on the users. People were having to ‘pay’ for this high res images that many of them weren’t benefiting from. It created a poor performance = friction.
We should be concerned about performance because poor performance is friction. People want speedy access to websites – it matters.
The Harris Poll found that speed was the 2nd most desired attribute to a website, BEFORE RELIABILITY. People would rather a website be fast than work all the time.
A 1s delay can reduce conversions by 7%. For an online shop that earns $100,000 a day, that’s about $2.5million in lost sales.
A 1s time delay for Amazon cost them $1.6billion in sales.
Slow mobile load times was the greatest source of frustration or mobile users.
Google found 53% of people will abandon websites that take more than 3s to load.
Let’s get positive:
By shaving 7s off load, Edmunds increased page views by 17% and ad revenue by 3%.
Mozilla reduced page load time by 2.2s and sa a 15.4% increase in downloads.
PERFORMANCE MATTERS.
That’s one of the reasons they revisited the 10k Apart contest in 2016.
What they looked for:
- Usable pages are delivered in 10kb or less
- Pages are accessible via screen readers, the keyboard, etc.
- Entries follow the philosophy of progressive enhancement (be a layering up experience)
- Users can do what they need to without Javascript
When building the 10k Apart website, they wanted to follow the same rules!
He’s going to discuss some of the performance optimizations they made that are low hanging fruit so we can use these in our own optimizations.
But first let’s talk about PAGE LOAD:
It’s important to note that CSS and JavaScript can delay loading.
DOM Parsing:
This affects layout performance.
Example: Starting at the root element it begins to parse through and then it hits a <script> tag so then it stops and goes to fetch that resource since it can affect that page. Then it says ‘hey, there’s a <css> file here so I need to pause and fetch that file before I proceed.
Then it seem an image so it puts that to the site and keeps loading because it can pull it in later and moves on but then pauses again because it sees another script.
Steps for better performance:
- Use native features whenever possible
- Only include assets you actually need
- Optimize everything
- Thank about WHEN you load assets
- Consider how you load assets
- Only load assets when they actually add value
1. USE NATIVE FEATURES WHENEVER POSSIBLE
Do this whenever you can because they’re basically ‘free.’
Example: Use <header> </header> instead of <div id=“header”></div>
It has meaning to it (and it’s shorter). It’s semantic. Depending on its location in the document, it could also provide a landmark for navigation!
Another Example: For a form to collect someone’s name, just use an <input> field and attributes to do all sorts of cool things that are native! See screenshot:
Another example: For a form to collect an email, you can use <input type=“email”> and most browsers will auto validate the the value is a valid email address!
Flexbox is another great example that requires so much less code than floats!
You can also use CSS slelector-based DOM traversal without a JS library!
Another vastly underused thing is making use of system fonts! You can create really elaborate font stacks with system fonts!
If you DO need to use a custom font, subset it as much as you can (remove characters from the font files that you don’t need. FontSquirrel does this for example, along with other tools. But do this with caution because if you come across a character you weren’t expecting, your shit will look weird.
2. ONLY INCLUDE TOOLS/ASSETS YOU ACTUALLY NEED
Every tool has a cost. You can quickly end up in a situation where you have over 3MB in frameworks being loaded on a site! (He had an example of this actually happening to a friend of his with a client because every time they wanted to do something that required a framework they just added it like it was free).
Chances are, your library of choice is on a CDN, and that’s great because if we all reference something from the same CDN, as we move from site to site it’s cached so it doesn’t need to be redownloaded. However, it still creates some networking issues like on a high latency network
For each CDN domain, we have to go through the entire connection process (the whole process of asking where the can is, finding it, making the handshake, requesting it, loading it).
Thankfully, we can optimize this a little bit. We can optimize the DNS lookup by using a <link> element in our document (in the <head>).
With this, the browser will make the prefetch request and kick off that process so when it’s at the point where it’s going to load an asset, it already has that taken care of.
You can also do this with individual assets with
<link rel=“reload” href=“asseturl” as=“script”>
These are called ‘Resource Hints’ which can speed up things quite a bit.
But download isn’t everything we need to worry about…
Even once you have the library preloaded, they still pale in comparison to native JavaScript (Vanilla JS) in terms of performance.
When they were building out the 10k Apart site, they decided to do it 100% library free, do everything from scratch. They used resource hints to make pre-connections to Google Analytics and Cloudflare.
3 OPTIMIZE EVERYTHING
They used Gulp to help with a lot of the optimization work but you don’t necessarily need it. There’s Grunt, Make, bundling tools like WebPack and parcel and things like that. You need to figure out what works best for your team if anything, but the important point here is that we use these tools in order to make optimizations that help the overall performance of the site.
Their approach to CSS:
- They started writing their CSS modularly in SASS, and then used an add-on called breakup (breakpoint management).
- They complied the CSS with a precision of 4 decimal places (gulp-sass)
- They used Autoprefixer to create fallbacks for the last 2 browser versions (gulp-autoprefixer)
- Used CSS shorthand declarations if possible (gulp-shorthand)
- Used UnCSS to remove any unused declarations/rule sets (gulp-uncss)
- They optimized the files using CSS Optimizer (gulp-css)
- Minified them using Clean CSS (gulp-clean-css)
- They Gzipped (gulp-zopfli)
- And used Brotli (gulp-brotli)
- So the server didn’t need to compress those assets! Took a lot of processing time out of the server end of things.
They ended up with 6 versions of each file. Browsers that supported the Brotli compression would get the 2kb file, then browsers that supported the Gzip file would get the 3kb file, and then everyone else would get the regular file.
Their approach to JS (screenshot):
They also minified and pre-compressed their HTML.
They wanted to take as much load off the server as possible. They did have a backend, it was node-based, but they wanted to reduce the resource needs.
4. THINK ABOUT THWNE YOU LOAD ASSETS
They had 10 JavaScript files
2 Global
1 Service Worker
7 page specific files
They’d put their global JS file at the top but then added their additional JavaScript files for each page with an attribute to DEFER the loading of it. (defer)
Then there’s also an (async) attribute that says ‘run it whenever it becomes available but don’t delay pageload.’
You have to also consider dependencies when using async (you can’t use it on everything even though it sounds great). For example, you could end up where your home JavaScript file has a dependency on your main JavaScript file, and so if yoru home JS file is asynchronously loaded but the main JS file hasn’t loaded yet you’d be in trouble.
With HTTP2, you make 1 request and then your resources stream in as they become available.
Stefan Baumgartner wrote ‘The Best Request is No Request, Revisited’ for A List Apart. Worth a read.
5. CONSIDER HOW YOU LOAD ASSETS
In order to deliver the slimmest possible experience to older devices, they decided to make the default experience on that way mobile (single column view)
So they have 2 CSS files: 1 that has everything for every browser like colors, typography, etc), and a second advanced stylesheet that gets loaded into more modern browsers by adding a media query (screen) to the link element!
They also used conditional comments which isn’t supported anymore to deliver specific script to IE8 and below become nobody else supports it!
You can also use a conditional comment as a way to hide particular resources.
And because the site was built to work WITHOUT JavaScript, this works!
They took a similar approach to loading imagery. For the footer, they had the text credits for Microsoft and An Event Apart, but then they lazy loaded the logo image files after a certain point (after a certain screen size).
Conditional animation: they had an SVG animation on the homepage.
They did an INTERFACE EXPERIENCE MAP to help them wrap their mind around different user experiences.
6 ONLY LOAD ASSETS WHEN THEY ACTUALLY ADD VALUE
Images can be really useful for drawing eyes across a screen when they’re competing for attention. They become less useful on a small screen when the competition is low. So, it’s important to evaluate each image individually:
We need to justify each and every one of them that we put in our pages. The take up the lion’s share of our page load AND sometimes they don’t actually fit! Sometimes the images make the experience WORSE (ex: blog rolls with images on the left and headings squished on the right with lots of line breaks).
Evaluate images case-by-case:
- Does the image reiterate information found in the surrounding text?
- Is the image necessary to understand the surrounding content?
- Does the image contain text?
- Is the image a graph, chart, or table?
- Could the content of the image be presented in a different format that would not require an image?
- Is the image purely presentational?
If you can avoid using an image, DON’T USE AN IMAGE. They’re expensive.
If you DO use an image, make sure you choose the right format. Here’s a quick refresher on which image formats are good for different scenarios:
GIF
- for images with large swaths of solid colors
- Binary transparency
JPG
- For photographs and images with gradations of color
- Can be compressed (introduces artifacts)
PNG (8-Bit)
- Alternative to GIF
- Can support alpha transparency (with the right creation software)
PNG (24-bit)
- Alternative to JPG
- Usually larger than JPGs
- Supports alpha tranparency
WebP
- Newer format, not universally supported
- Smaller than JPGs and 24-bit PNGs
- Support alpha transparency
- and so much more…
Also there are SVGs which are great if you have an image that needs to be scaled.
* * *
For the judges section they had 6 images but decided that the default experience should be without images.
Here’s how they did this:
The JS creates a div and hides it and adds it to the document
Then there are rules in CSS that defines and sizes the font family
It’s hidden, it doesn’t really matter, it’s just a way of passing information back and forth
Then on the JS end there’s a function called getActiveMQ that allows it to get the current media query and then lazy load
A good way to not have to hardcode sizes into your JS or hardcode media queries into your JS.
Now there’s a data attribute an the img attribute and then dynamically add in the image location.
How they optimized images:
Changed to black & white
Cropped and reduced size
Blurred everything but the subject
Then also converted to WebP to further reduce the size!
You can use the <picture> element and let the browser decide which image to use.
Put your smallest file size first because the first match wins. The same thing goes for audio and visual elements. Always put the smallest one first unless there’s a reason not to.
Every choice we make affects our users’ experiences. We need to use only what we truly need. Make sure every resource has to FIGHT for its place in our sites, and justify its existence. There ARE tradeoffs between design and performance. We should always strive to make our decisions in our user’s favor instead of in our own convenience.
We should invest our time so we can save it for our users.
0 Comments
Trackbacks/Pingbacks