Performance is user experience… and users expect a 2 second or less load time. After 3 seconds, 40% will abandon your site.
They recently did some tests on their site relating to performance:
- On ETSY they ran a test where they added 160kb of hidden images for mobile and it increased the bounce rate by 12%!
- Scrolling jank – eliminated it for half of users. People favorited more often and favorited more items without scrolling bank.
- Removing a redirect from their ads increased click through rate by 12% on mobile.
Our industry has not designed for performance. We optimize design and layout for mobile, but not page load time.
Fast page load = more returning visitors, more brand trust, etc.
Performance + aesthetics = the user experience.
This is not performance vs aesthetics.
On a mobile network, the average round trip from a phone to a cell tower to your web host and back is roughly the same as old dial up connections! So mobile is very important to consider with regards to page load time and performance.
WebPageTest.org – use it!
You’re given a video to watch your video load. We want to judge our user’s perception of speed, how quickly it becomes visible, interactive, and how smoothly it loads.
We want to optimize for the order of requests. Example: If we have JS loaded in the head, it will block the rest of the stuff… so the order of your files and how big they are will affect how the site feels when it loads.
We also want to optimize for the number of requests.
The more files we have the longer it will take for that request to return / for those files to load. We want to keep that number as short as humanly possible.
We want to optimize for the size of requests. The larger the files the longer it’s going to take to get things back and process them. The 14kb HTML file comes back quickly. The 30kb CSS file takes a bit longer. The HERO image, which is 120kb (which is a really good size for a HERO) is going to take much longer, and will probably take more than one round trip to get the whole file loaded.
We’re going to talk about:
Images make up the vast majority of a webpage’s size / load.
JPG: used for Photos and images with many colors in them. They are lossy, meaning we can discard information.
To optimize: reduce noise and other complexity, decrease export quality, and blur unimportant areas of the image. Actually, cropping helps too! Human judgement needs to be used when doing this.
GIF: Graphic Interchange Format. Introduced by CompuServe in 1987 (patented), and they released an enhanced version which included animation in 1989. Best for: Animations that can’t be replaced with CSS… but there is really no other reason to use them.
They are really good at horizontal redundancy. The more details or noise, the larger file size. Replace non-aminated GIFs with PNG-8s. Replace animated GIFs with CSS. Replace videos with HTML5 Videos.
PNG-8: Created as an improved and non-patented alternative to GIFs. Lossless (like GIFs!), 256 color palette (like GIFs!), dither (like GIFs!) and recognize horizontal AND vertical patterns (GIFs do NOT recognize vertical patterns)
PNG-24: no restriction on the color palette. These handle transparency differently than the PNG-8s – PNG24’s allow partial transparency, which results in a larger file size than PNG-8s which don’t allow partial transparency. To optimize: Decrease noise and number of color options.
WebP: Google announced WebPicture in 2010. Lossless and lossy compression – supports transparency and animation. Created to reduce file size on the web! Predicts a value from a neighboring box of pixels and then encodes only the difference.. It’s only supported in a few different browsers.
SVG: Replace simple images with SVG. Scalable Vector Graphics. Scales up beautifully for retina devices. If inline, it eliminates an HTTP requires. Not supported in IE8 or less. SVGs export with a lot of cruft (junk). Inline SVG removes the cache ability and therefore makes your HTML file size larger, but it saves a request. So, with everything else, test it / measure it.
Sprites: You only load one asset (so you only make the round trip once) and then it’s cached, so you can display different parts of that image. She thinks everyone should be using sprites. What’s funny is I thought they were dead… They can increase the page file size, but could increase page load time by reducing requests.
Responsive images: How to use these tactics today.
srcset – allows the browser to deliver / load a different image file based on the size of the device. Then the browser can always load a backup file.
ImageOptim – lossless compression tool. MAGIC. Automate this!
http://codedread.com/scour or http://github.com/svg/svgo
Only @import the font weights you absolutely need.
Optimize the heft of these fonts. These files get very large very fast. People forget to look at how large their font files are.
One quick trick is to only load fonts on desktops. It’s kind of hacky but they do it at ETSY.
You can optimize your character subsettings.
Document substrings so other can know and if needed edit it.
Semantics & Repurposability
Save development time and page load time.
Create repurposable code. Remove inefficient selectors. If you start to see lots of inefficient selectors it means you need more specificity. Remove unnecessary elements (divitis).
Use Firefox’s 3D viewer clean up code. It shows you the nested deck of your HTML elements.
Patterns are important because not only can other developers replicate things but users will benefit in their user experience and things can get cached.
Case Study: ETSY did a lot of work cleaning up the fonts and font weights that were used on their site. They ended up picking ONE font weight for headlines and then didn’t use it for body copy. They then standardized the font sizes used. This work saved 270kb and 5 requests on the page in question. This is HUGE for user experience.
Use a mobile-first workflow. Decide what the purpose of your page is and focus on that first.
Create a performance budget. What you want to measure, what the goal is, and some notes.
Always load them a-synchronously, never synchronously.
If you can, replace them with links you can control so you aren’t relying on someone else’s (probably junky) code.
Can I put a large HERO image at the top of every single article?
Pro: Represents the brand well.
Con: This could be a really large file, and we want to minimize the page weight.
Compromise: We’ll make sure that few colors are used in the HERO and that it’s compressed correctly.
Should I @font-face three display weights and a text weight?
Pro: Lots of flexibility in typography.
Con: More requests = more page weight.
Compromise: We’ll use two display weights and a system font for the body content.
I need a video to demonstrate how this product works
Compromise: We’ll self-host a video that asynchronously loads. (only when the rest of the page is done loading will you start to call the video file).
– I asked about this one because I often recommend clients host their videos on YouTube to avoid making their page load time slower because of the big video being on their server. She said this is something I just have to test for each scenario. If hosting the video on YouTube and there’s a way to asynchronously load that video, that could be a really great solution. The benefits to self hosting is simply control. It prevents you loading content from another website, which in a sense you have no control over, which is why she recommends it.
We’re never saying NO, we’re saying let’s make a compromise to make the overall user experience good.
If you want to make some decisions that could negatively affect performance, do A/B testing.
Make it easy for non-developers to do performance.
- Automate compression
- Utilize style guides
- Automate performance tests
- Automate image resizing
The content creator then doesn’t need to worry about any of these things, how big their file size is, etc.
WHO IS RESPONSIBLE FOR PERFORMANCE?
Being a performance cop is not sustainable. You need to create a culture of performance but that’s not easy! Changing culture is hard!
Perceived performance is most important. Help people “feel” your site’s performance.
It’s really powerful to see how your website loads next to competitors.
Publish performance reports. Page load times are not a secret, plus this creates a huge motivator to iterate and improve.
While we’re designing and developing, we have shiny hardware and general a great experience, so we need to have empathy with our users! We also need to help other designers, developers and upper management care about our users.
Good performance is good design. 80-90% of user experience happens on the front end, so while there are things you can can in the backend we can control a ton on the front end.
Designing for Performance – book by Lara Callender Hogan
All she’s covered today is in that book plus more.
If you can only do one thing, run your website through webpagetest.org. This will give you all the data you could possibly need and even suggestions on what to do.
Oh, and everybody please implement HTTPS.