Good morning.
I am so excited to be here in Orlando.
This is the first time I've spoken here.
So thank you for your warm welcome.
I'm going to do a deep dive today for designers, front end
developers, content editors, everybody who works on websites
with site speed in mind, right?
Images, fonts, markup.
And at the end we're going to do Q&A,
so start thinking about your questions now.
So as Eric, mentioned I wrote a book with the same title
here, Designing for Performance.
I also work at Etsy where I work with teams of developers
to help make all of the front ends of this website load
more quickly, be more accessible,
have a lot of design patterns that work with our apps
as well, too.
Now, what we've learned, and what many of us in the room
have learned over the years, is that performance
is absolutely part of the user experience, right?
It's being factored into the search engine results,
and its effects on user behavior are
being studied by major sites.
And what those studies have found
is that users expect our sites to load in two seconds or less.
Worse, after three seconds, up to 40% of your users
are going to abandon your site.
So think about how you search for things on the web, right?
How quickly are you going to close a tab
and move on to something next if a site is
taking too long to load?
And we at Etsy absolutely have found this.
We ran an experiment specifically
to determine what the effect on our users
would be if we slowed down the mobile website.
We added 160 kilobytes of hidden images to the page.
Meaning nothing else was affected, no layout, nothing
looked visually different, except it took longer to load.
And we triggered a 12% increase in bounce rate on mobile web.
Ugh, just the worst.
But conversely, when we eliminate
jank-- and jank is that stuttering when you're
scrolling through a website, when we eliminated jank,
people favorited things more often,
and favorited more of them in general.
Double-Click ran an experiment and found this, too.
They removed a redirect, and they
found that they increased click-through rate by 12%
on mobile devices.
This is great, right?
We can start to focus on these things and make the case.
But really, historically, our industry
has not designed for performance.
We're designing sites with increasingly rich content, lots
of dynamic elements, larger JavaScript
files, beautiful animations, complex graphics, et cetera.
We may optimize design and layout for mobile,
but we don't always optimize for page speed on mobile.
And some responsively designed sites
are irresponsible with the amount of page weight
that we need to load the page.
But fast page load time does a whole bunch
of really great things for you and your visitors, right?
It builds trust in your site.
It will increase the number of visitors
who return to your site.
It will increase the number of people who
choose you over a competitor.
More people will be trusting your brand.
This good user experience yields a ton
of good things for you and your site,
and optimized page speed is a huge part of it.
So what I want to talk about today
is performance and aesthetics.
I'm not going to stand up here and say,
make the fastest site humanly possible, because it's probably
going to be really ugly, and overall be,
eh, an iffy user experience.
But what I want to do is remove this antagonistic feeling
that we have.
It's not performance versus aesthetics, right?
We want to talk about the entire user experience,
and performance is a part of it.
So I'm going to talk a lot about mobile.
And I want to just give us all a foundation
of why mobile is really important in this context.
So before a device can transmit or receive data,
it has to establish a radio channel with the network.
And I'm going to visualize this with
a little hand-wavy diagram.
This process of connecting to the radio tower
and then our host which returns these files to the tower
and then again to our user can take several seconds.
And the best part is, if there is no data transmitted
or received after a timeout, that channel
is going to go idle, which requires a new channel
to be established.
This can obviously wreak havoc on our web page load times.
And then our typical US desktop using
Wi-Fi, a request's average round trip
takes about 50 milliseconds.
But on a mobile network it's more than 300 milliseconds.
This is as slow as old dial-up connections, if any of you
remember those.
And this process has to repeat over and over
and over again in order to get all that data back
to your user's browser.
And most of the time, that browser
has to acknowledge each chunk of data that gets back.
Not each file, each chunk of each file.
So you can see how this stuff adds up.
So I'm going to talk a lot about how
we're going to be optimizing for this network.
Who in here has used WebPagetest before?
Yeah, great.
OK, for those of you who haven't, this
is my number one go-to tool for assessing
how fast a site is taking to load
and what some of the problems are with it.
It's free.
Please go run your site through it right now.
I will wait.
You'll be bummed out, but then I'll show you how to fix it.
So the perception of how fast your site loads
is way more important than how long it actually takes to load.
User's perception of speed will be
based on how quickly they start to see content,
how quickly it becomes interactive,
and how smoothly the site scrolls.
Let's use another hand-wavy diagram for this.
First we're going to go and fetch the HTML.
That HTML is going to tell us that we use CSS and JavaScript.
And any JavaScript that's loaded in the head
is going to block the render of all the other stuff.
So it's going to take a while for us
to be able to go and get all those body images.
So it's important to know also that body images are
non-blocking.
They'll start to download for your user
once they're being called.
The second thing that we're going to talk about today
is the number of requests.
This is a waterfall diagram from WebPagetest.
And what you'll see is each row represents
a different asset that's being loaded on your page.
So a CSS file, a JavaScript file, et cetera.
And you'll see on your waterfall you
may have lots and lots of rows.
This is just a fraction of the things that
are loaded on Etsy's home page.
It's embarrassing how long this waterfall goes for.
And then each of these rows goes across the page
to show how long it takes for that thing to download.
Obviously the shorter, the better.
We'll get to that in a second.
So the more the files, the more waiting we
have to do to get things back.
In this case, our HTML file, which is usually pretty small,
comes back quickly.
So what do we do if we have got 15 CSS files?
Sometimes they might be downloaded in parallel,
but this maxes out at a certain point based on browsers.
And during this process, again, the browser's
acknowledging that it's getting these things back.
We get to wait until it's done.
Eventually.
You can feel how long that takes to load, right?
So the fewer files, the better.
And now let's talk about those sizes.
So this is, again, just a handful of things
that we load on Etsy.com.
And you can see that they range from eight kilobytes
to more than 70 kilobytes for an image.
The smaller, the better.
So we want to be talking a lot today
about how fonts and images and other things that we're
going to load on the page should be
as small as humanly possible.
So how does this affect our page load?
The larger the files, the longer the wait
is to get things back and process them.
So if we have a CSS file that's 30 kilobytes,
it's going to take a little bit longer
to get it back and process it.
In this scenario with a huge image,
it's probably going to take more than one round trip
to go and get all that data and return it
to our user's browser.
So we want, again, smallest files as possible.
So hold on to your butts, we're going
to talk about image formatting, sizing and spriting.
We're going to talk about cutting down font weights.
We're going to discuss semantic markup and repurposability.
And also it's going to be important to talk
about changing the culture of your organization,
your company, or your clients' minds
to get them to care about this stuff.
All right, I didn't make up this pie chart.
This is actual, this is real.
This looks at the Alexa top sites,
and it says on the average website,
what percentage of the page weight pie
is made up of images.
So as you can see, the average site, most of what
we're loading is image files in different formats.
This section of the talk I like to call Images, The Nerdy
Parts because we're going to go into the history as to why we
have so many different image formats,
and how that each works so you can optimize each of them.
We'll start with everybody's favorite, JPEGs.
JPEG stands for Joint Photographic Experts Group.
The group began in '86, and they released their first standard
in '92.
And they are best for photos.
We all know this, right?
We use JPEGs, they come out of our cameras.
It's pretty obvious, right?
They're best for photos that have many, many colors in them.
Why?
Well, JPEGs are lossy, right?
Their algorithm is loosely based on how humans see and process
information.
So they're really, really good for images
that have lots of smooth gradients in them,
and areas that have low contrast.
And they're really, really bad at edges, right?
High contrast areas.
They're really bad at understanding
how to process and discard information
over areas of high contrast.
So what are our options?
Well, we can reduce noise and other complexity, right?
Again, aiming for smooth gradients,
aiming for less contrast.
We can decrease the export quality.
We've all played with that slider.
And we can start to blur unimportant areas.
So for the quality slider, I want
to talk about finding a happy medium of quality
and file size.
For most JPEGs, between 50 and 75 is probably perfectly fine.
It's going to be important for you to be testing these things
as we go.
Everything that I'm talking about
is worth testing for you and your site.
What may work for one image or one site
may not work for other images, so I'm
going to give you lots of options.
So that export quality thing, right?
For these two images of lavender,
from where you're sitting, even from where
I'm standing with my screen, there's
no way I can tell the difference between these two qualities.
On the left is quality 25.
It's a very small file size at 40 kilobytes.
On the right is a quality of 100, substantially larger.
Let's zoom in.
So lower qualities have more artifacting
around the edges of high contrast.
You can see it's kind of pixelated,
a little bit weirdly blurry.
So the higher quality, the larger file size, right?
Because there's so much more information
that the JPEG contains that we can render this image.
Obviously the artifacting isn't that noticeable
when the image was smaller and not zoomed in.
So you need to find the right balance of export
quality and visual quality.
Next I want to talk about what Jeffrey was
mentioning earlier in his talk.
So he mentioned blurring unimportant areas of images.
This is from a study that Justin Avery wrote up.
I've got the link on the website and also on this slide deck.
This is Ethan Marcotte who will be speaking.
So you can tell that there's a background that's
pretty unimportant, and a very different An Event Apart
You can tell because of the blue backdrop.
So before the blur, the image was about 200 kilobytes.
And then Justin went and blurred all the background areas.
And after the blur, he reduced it to 150 kilobytes.
Pretty amazing.
But I took it one step further.
I went and cropped it.
So as you can tell, the number of colors
and general complexity will absolutely
have an impact on your exported file size.
So this is great for any different file format.
On the left here we've got that gorgeous blue gradient.
On the right crop, you can see there's a lot more detail.
And so you can tell that the amount of information contained
in this image really differs.
Unfortunately, the left crop, which is the smallest one,
is also the worst photo, [LAUGHS] right?
We definitely don't want to just say, OK, the smallest one wins.
What we want to say is, maybe the center crop
could be a good balance between performance and aesthetics.
GIFs.
So CompuServe introduced the GIF format in '87
to provide a color image format for their file downloading
areas.
I'm going to talk a little bit about GIFs,
but I'm going to say that they should only
be used for animations that can't be replaced with CSS.
Please don't use them in any other ways.
You'll see all my slides will say,
please don't use them on here.
OK, they contain up to 256 colors per frame.
They are lossless.
And again, please don't use them.
But if you must use a GIF, your slider
here is going to have to do with dithering.
So dithering examines adjacent pixels,
and chooses a new color somewhere in between them
to give an appearance of a smoother blend.
So dithering set to zero, you can
tell that there is banding in between each
of these colors on the rainbow.
And on the right when dithering is set all the way up to 100,
it's a little bit of a smoother blend.
And you can tell this has a huge effect on file size, right?
It more than doubles.
But look at this bonkers thing.
This is the reason why I'm asking you not to use GIFs.
If that same image rainbow horizontally
is 9.7 kilobytes, but vertically when we just
rotate it 90 degrees, you'll see that with the vertical pattern,
it again more than doubles in file size.
So GIFs are really, really good at removing horizontal
redundancy, at understanding and compressing
horizontal redundancy.
But the more details or noise overall,
the larger the file size will be.
Especially vertical noise.
So seriously, please do not use these.
Replace any GIF animations that you're using with CSS.
Replace any non-animated GIFs with PNGs,
which we'll get to in a second, and replace any movie GIFs
with asynchronously loading videos.
There will always be edge cases here,
but for the vast majority of times, test
it and you'll find you should be use a replacement to GIFs.
So some sites like Gfycat will optimize GIFs for you,
and then show you them in much smaller HTML5 video formats
to save you tons on bandwidth.
Look at this, this is the reason why you should
be replacing GIFs with PNGs.
So GIF's compression algorithm was patented by Unisys.
This patent expired in 2003 or 2004.
And PNGs came around.
Look at that, that's ridiculous, the file
size savings with PNGs.
So PNG stands for Portable Network Graphics,
and they were created as an improved, non-patented
replacement for GIFs in '96.
So PNG-8s are best for images with very few colors
because just like GIFs, they are lossless.
They've got that 256 color palette.
You could affect the dithering like GIFs.
But they recognize horizontal and vertical patterns.
It's also important to note that PNG-8s and PNG-24s are
totally different, but have the same name for some reason.
So PNG-24s have no restriction on the color palette,
and they handle transparencies super differently than PNG-8s.
So people started to grow sick of the limitation of the 256
color palette when computers that
could display more than that started
growing more and more common.
So PNG-24s, you can guess this, right, decreased the noise,
and decreased the number of colors for a smaller file size.
So let's compare them.
In the PNG-8 file, Photoshop was working with a matte color
to blend that dropshadow, right?
There's no partial transparency.
There's only fully transparent pixels beyond that drop shadow.
Let's compare it with the PNG-24.
So we can start to see partial transparency here.
Believe it or not, there is a slight drop shadow
around those letters.
It's important to note if you want to really geek out
about this, this is actually PNG-32.
It's 24 bits of color and 8 bits of alpha transparency.
This naturally results in a much larger file size.
But if you don't need transparency,
just use JPEGs because they're lossy
and they create much smaller complex images.
If you want to get really fancy, level up your game with WebP.
So Google announced WebP, Web Picture, in 2010.
And it's both lossless and lossy,
and it supports transparency and animation.
It's pretty bananas.
Google did this intentionally to help
reduce file sizes on the web.
So WebP employs a methodology from a video codec
to compress key frames in videos.
It predicts a value from neighboring blocks of pixels,
and then it encodes only the difference
between the prediction and the actual value.
You could create it with Photoshop.
There's a plug-in.
There's also online conversion tools.
Currently it's only supported in Chrome, Opera, and Android
browser.
But you can still try it today.
So we want to talk a little bit about saving
even more bytes in requests, right,
when we think about that waterfall chart.
So I've asked this question many times over the years.
Who in here has implemented SVG on their website?
Yes.
When I first started giving this presentation,
maybe 10 people in the audience had done this.
I'm so excited to see that the times have changed.
So Macromedia and Microsoft introduced
the standard called VML, whereas Adobe Systems and Sun
Microsystems submitted a competing format known as PGML.
And the W3C recommendation came out in 2001 with SVG.
It's XML based vector image format.
So SVGs are rad for so many reasons, right?
They scale up beautifully for retina devices.
And if they're inline, they eliminate one of those requests
to go and fetch content.
They're supported on-- who here is still supporting IE8?
Ah, this is making my day.
I'm sorry for the few people who are not making my day,
but for the rest of you, you're making my day with this.
We're going to talk a little bit about IE8 in a minute, too.
And they do export with a lot of cruft.
So if you've ever exported an SVG file from Illustrator,
you'll see that there is all of this stuff at the top
that you can just completely remove.
And at the end you'll have something very simple--
an SVG tag, maybe a polygon tag, maybe a couple of other tags.
But it's really wonderful and super flexible.
There will be another talk on SVG in a bit.
You can apply as a background, right, using CSS.
Or you can inline the SVG into your HTML.
This is the thing that eliminates an HTTP request.
But it's important to remember that if you inline it,
it removes the cacheability, meaning the second time
that a visitor comes to your site,
their browser is going to have to do some work.
So as with everything else, be testing it.
Sprites.
A couple of years ago when HTTP/2 was announced,
I heard a lot of talk in the industry
about how I wasn't going to have to talk about sprites anymore
in my presentations.
We still are talking about sprites in presentations
because it's still super relevant.
I promise someday we will get to ignore this stuff,
but for now sprites are still super helpful.
So what a sprite does is, it eliminates
all of these individual requests to go and get images
by combining them into one.
So the user's browser is going to go
fetch that one image, and then just display parts of it
throughout a page.
I worked on this website years and years ago
in which we had 10 thumbnail slots
and about 26 images rotating in and out of those slots.
And we were calling them individually.
I decided to say, hey, what if I just combine them
all into one sprite, which is a super weird looking sprite,
just a bunch of faces squished together,
and load them dynamically and see what
happened with the performance?
I knew, I had a gut sense that even though the page would
blow in terms of the total file size,
as well as some extra CSS for JavaScript to make this happen,
it was worth testing.
And in fact, even though it added 60 kilobytes
to the total page weight, it cut our page load time
by 35% because of the impact that it
had on the number of requests.
So please go forth and test this stuff.
So we also want to talk about serving just the right amount
of bytes, right?
We don't want to serve more than is
useful to the user at a given time.
And your best bet for displaying a correctly sized picture
in modern browsers is to take advantage of that responsive
images specification.
So this new spec provides lots of different ways
to tell the browser which image file to download and when.
And you can include a fallback for those browsers that
don't support the new stuff.
This is for you, IE8 supporters.
And you can use this today.
So this is a very simple example of the source setAttribute that
helps the browser determine which image file to download
and when.
The browser is going to use the sizes information to understand
the size of the image in the page based on the viewport,
and then it will choose whatever it thinks
is the best image source.
So again, the sizes.
The browser is going to look at the matching media query which
tells us what percent of the viewport width
this image will make up.
And it makes the browser do some math.
srcset plus sizes gives the browser choice,
and the browser is in a much better position
to pick the best source based on things like the device's
pixel density, and whether or not the user
has opted into Google's fast browser setting.
I know that we want control as developers.
We want to know which image size is going to be displayed.
But guess what?
In this case, it's much better to let the browser handle this.
And one additional super power of the responsive images spec
is the type attribute.
So we can tell our user's browser
to ignore an image source unless it recognizes the contents
of the type attribute.
So in this example, the browsers with that will recognize SVG,
will download the SVG file, and the rest
will download the fallback PNG.
So again, we're able to save our user from unnecessary page
weight overhead.
All right, let's compress this stuff.
I love using ImageOptim, though there are plenty of tools
out there.
All you have to do is drag your image files
or use a command line interface to put your image files
through additional compression.
It's perceptually lossless.
Nothing will visually change in your images,
but it will save you a ton of file size.
We recently ran all of the PNGs in Etsy's templates
through lossless compression.
On average, it saved just under 20% per file.
But for the whole file folder, of all the things
that it takes to render the outside of Etsy,
we saved 44% of our file size.
Just bananas.
But don't do this by hand.
Automate it.
There's so many tools.
There's CLIs, there's WordPress plugins,
there's SVG scrubbers, et cetera.
And one more important thing to note
here is that when you're optimizing images,
you're not just optimizing the perceived performance
of the website that's loading.
You are affecting the entire user experience,
including battery life.
So there was a study that was done that took all of JPEGs
on Amazon's site, and it recreated them as JPEGs
at 90% quality.
And it found that it saves 30% of the energy needed
to load Amazon on a phone, that's Joules
that we're talking about.
On Facebook it saved 30%.
It's amazing.
So affect the entire user experience, not battery life.
Or sorry, not just performance.
Contrats, you just made it through the bulk
of the performance work.
So now the images are done.
We can take a deep breath just like Buttercup,
and start talking about--
aw, look at her, fonts.
The bane of my existence as a performance nerd.
I work with some incredibly talented designers at Etsy
who take our branding extremely seriously,
and the user experience, right?
They're super good at what they do.
I will give you some examples of times when fonts have not
always been our friend at Etsy.
And this is really important, right?
Because IE6 through IE8 downloads
all font face files that are referenced in a CSS document
even if they're not used.
Meaning if you just list them at the top,
even if you're not using them on the actual website,
IE8 and less will download all these images.
And more recent versions of IE with compatibility mode turned
on will also download them.
So this is a terrible user experience.
So please, only import the font weights you absolutely need.
This has everything to do with optimizing the size
and the number of requests.
The more font weights you use, the longer the page
will take to load because font files can be very heavy.
The average font served by Google Fonts
is about 35 kilobytes, but can be upwards of 200
depending upon language and character support.
One additional consideration you can make in your responsive
design is to load your custom font files only
on larger screens.
This is something that we do at Etsy, as we would rather
save our user from downloading the extra font files overhead
if they're on a mobile device.
So this media query will download and apply
the font file only if the user's device matches it.
Pretty rad.
And you can make optimizations to them using tools
like Font Squirrel's font file generator
to remove unnecessary characters, which is also
called character subsetting.
So let's zoom in here.
Font Squirrel will give you a ton
of options in what characters are going to be
included in your font file.
And at the bottom, you can get a sneak preview of it,
which is even cooler because you can start
typing in single characters that you want to include,
and you can see they dynamically update to just include
those characters.
This will help you save a ton of file size in your fonts.
But my word of warning here is, you
need to document which characters are included,
especially if there are multiple people editing your font files.
I'm going to tell you a story.
Vernon, who was a product manager at Etsy
sent an email internally at Etsy.
That's subject line was Horse Related Issues.
And he said, hey everyone, we've been asking around,
but it looks like there are some horse related issues affecting
reviews on some pages.
In Etsy forums, users started mentioning
a strange occurrence, a horse showing up
in their star rating.
[LAUGHTER]
So as you can see from this user-submitted screenshot,
a horse head was overlaid on top of a gray star.
This user had four and a horse stars.
[LAUGHTER]
So it turns out we'd accidentally dropped
the half star glyph from our icon font
because we hadn't added--
honestly, I hadn't adequately documented the process
for updating the character subsetting to add new icons.
That meant that instead of a half star,
IOS was finding what it thought was
the next closest thing, which in this case was a horse head.
So it started a really epic thread
at work full of horse puns because we all
found this hilarious.
And in general, we're a pun-focused organization.
[LAUGHTER]
Yeah, needless to say if we had fixed the subsetting,
we wouldn't have lost this many hours
to replying to an email thread one-upping each other on horse
puns.
So please, don't make the same mistake.
Document your subsetting.
All right, semantics and repurposability.
And Jeffrey talked a lot about this this morning.
So we want to save development time and page load time, right?
This stuff is not just helping our users,
it's helping us as we're developing websites.
I once did a cleanup of a template.
It wasn't a redesign, just a clean up.
And I found that I was able to save
a ton of files savings on our HTML, CSS, and all the style
sheet images that were involved in the cleanup.
I did this first by creating repurposable code, right?
So as you're designing and developing, ask yourself,
can someone else use this pattern?
Assets that get reused can get cached, which
is a huge performance win.
Also, name elements by function or content, not design, right?
Jeffrey talked about this.
This is, as we know, debated in our industry.
But it's my main recommendation for a small or medium sized
site.
A site as big as Facebook should be using a naming pattern
that's object-oriented because of its scale,
and because of how many developers
are touching the code.
But for your average site, being semantic with your element
names can be hugely beneficial for repurposability
and eliminating unnecessary elements.
Remove all those inefficient selectors, right?
So why have a class of wide, and an ID of sidebar,
and a link called search rather than just sidebar
search, or just search?
This is our canary in a coal mine.
If we start to see in inefficient selectors,
that means we're being probably unnecessarily specific.
And it will point you to all the places
where a pattern should probably be created.
Also, start to remove unnecessary elements, right?
Our divitis problems.
Firefox used to include this really awesome tool
called 3D Viewer built in to their browser.
Now you can install it as an add-on called Tilt 3D.
And I loved this when I was cleaning up websites
because often when you're doing cleanup,
it's really hard to say, yeah, I did work today.
Because all you're doing is making things
a little bit tidier.
But Firefox's 3D Viewer helped me with this.
I could see the nested depth of the elements
that I was affecting and start to feel like I
was making lots of progress.
So this is before and after cleanup.
You can see that my nested depth got a lot cleaner.
And I did this by creating patterns.
So we're going to talk about lots
of different kinds of patterns.
In this case, colors and fonts.
But any kinds of patterns will be
helpful to the performance and the overall user experience.
So this is my visual of what code sprawl looks like.
This is every color that we have defined in Etsy's CSS code base
sized by the number of times it appears in our code base.
So the rainbow at the top are all colors
that only appear once.
Meanwhile, these black and gray bars
extend another few thousand pixels off offscreen.
This is terrible and terrifying.
And we had something similar happen with our fonts.
We were using all these different font weights
and styles across Etsy.com and our apps.
This caused major performance issues.
Font file sizes added up, and it took multiple requests
to load them, sometimes upwards of 8 per page.
We use the different types of fonts
differently on our apps and our website, which
was a total mess for branding and product alignment.
There was no visual consistency or clear hierarchy.
And it was really hard to figure out
how to design something new with the font stack.
It was important to create less cognitive overhead
by implementing patterns.
So two desires at Etsy was that we
used way, way too many fonts across our features.
I thanked them.
They counted the usage across the site,
and there was one clear outlier for headlines.
These two women decided to come up
with a font pattern proposal that used these findings.
So they drafted the proposal and started doing research
on what would change in the desktop version and our apps.
And they got feedback from other designers
about the legibility and flexibility of this new font
stack.
Then they went and tested the changes across pages,
and posted a link to their development environments
so that people could poke around and really experience
the difference.
They started with the listing page
because it's our most popular and important page,
and was using far too many weights.
So it felt the most important to test there first.
The designers came up with a proposed new scale
for consistency across our platforms
too for even better clarity as people
were designing and developing.
And then to verify that fewer fonts are better for our users,
they ran an experiment with just Guardian Medium as the headline
copy, and they update the font scale
for all the rest of the copy.
It worked.
We were able to prove that this was a better user experience.
So these designers then partnered one on one
with iOS engineers and Android engineers
to remove extra weights from the apps.
And they've been teaming up with the rest of the design team
to make these changes across our site.
They saved 270 kilobytes of font weight and 5 requests
from our pages.
This is huge.
And even better, when people are designing new features,
new improvements to our user experience,
they're able to use these font patterns,
and there is no cognitive overhead for our designers
or developers.
And we're going to do the same thing with colors, too.
It's in progress.
And hopefully next year we'll be publishing our style guide,
which I'm really excited about.
So as we've been talking, I've been
talking a lot about designers and developers,
and what we can do as a one-off manually,
but I want to talk also about making
this part of our workflow.
If you start your design or development workflow
by thinking about the project from a mobile perspective
first, you may be able to avoid many of the problems
that bloated desktop sites faced.
So designing mobile first can force big questions early,
right?
Like what the core purpose of your page is,
and trimming all the other cruft.
Create a performance budget.
Say, here is our goal, here is our benchmark
for what we're aiming for based on users, industry standards,
or what your competitors are choosing to do,
or just what you want to aim for overall.
Know in your project documentations
how you're going to measure it.
WebPagetest, or what set of users?
What are the specs that you want to align this to?
This has been really helpful internally in Etsy.
We started doing a cap and trade program.
Oh, you want to add that new font that goes over
our budget by 30 kilobytes?
Find an image to save those 30 kilobytes elsewhere.
It allows us to have that flexibility while still
remaining in our budget.
And as you implement responsive web designs,
you're going to make choices about your content's size
as it's displayed to the user.
It may be fluid, it may be fixed and changed
at certain breakpoints, or you may choose to simply not load
certain pieces of the content, which
is why it's really important to make
sure you're only loading the assets you truly
need as a user.
This is an example of a third party button, the Google +
button.
Look at that jerk, just loading a ton
of nested elements on our web page.
This was as they were transitioning
from the old Google + button the new Google + button.
It's a third party site, right?
We don't get to control the stuff that they're loading.
And then from left to right here,
this was Twitter, the old Facebook Like, Google +
and Facebook Share buttons.
There's no reason why this amount of cruft
should be loading synchronously on your site.
Always load content that's outside of your control
asynchronously on your page.
And if a third party doesn't provide
an asynchronous version, demand it from them.
Or consider replacing them with simple buttons, right?
You don't always have to have this extra overhead.
Definitely consider performance as part of your overall user
experience here.
And I'm going to walk you through some pretend choices
you may be confronted with in which you have to weigh
site speed and aesthetics.
We're going to walk through what a compromise might look like.
So this is a question I have got,
and I'm going to assume everybody in this room
has received.
Can I put a large hero image at the top of the page?
The pro here, right, is that it represents the brand well,
but the con here is that it could be a really large file.
Hero images are usually very big, often very complex images.
And we want to focus on minimizing page weight.
So the compromise is, yeah, OK, hero is cool.
But let's be super vigilant about making sure
that the compression is correct, and we're
using as few colors as possible.
Here's another one.
Should I @font-face in three display weights and a text
weight?
The pro is that we've got lots of flexibility in typography.
The con is that this is obviously more requests,
and therefore more page weight.
So make a compromise.
Use some display weights, but also use
a system font for the body content,
or whatever ends up working out well for you.
Definitely test a bunch and find a happy medium between the two.
How will I demonstrate how this product works?
I get a lot of questions about, well,
but we want people to feel this, we
want people to see it and experience it.
A video or an animated GIF will clearly
convey this kind of information, but we
know that these file formats are very heavy.
So self-host a video, right?
Asynchronously load the video.
As you're doing this stuff, make these concessions.
But make it clear we're being vigilant about this.
We're going to measure it.
We're going to understand the impact
that this has on our users.
My favorite thing to do in these cases is to run an A/B test.
If you want to make some aesthetic changes that
negatively impact performance, test
them to see which one actually improves engagement metrics.
Continue to benchmark and iterate on performance
as you go.
It's also really cool, by the way,
to run performance experiments where
it's your A/B testing making things better or worse
from a performance perspective.
Huge, goes over really well with your very important people
crowd like your boss.
We have done these things at Etsy.
So we'll be able to say, hey, yeah,
we're going to make a change to the site that negatively
impacts performance, and we're just
going to gut check and verify that it's still
the right move for us.
This also helps us defend our performance benchmarks.
It helps us defend our performance budgets.
And by working really well with product designers and product
managers, we're able to make these kinds of concessions.
Make it easy for non-developers to do performance, right?
This can't just rest on the shoulders of the people who
are in this room.
Automate compression, utilize style guides.
Automate everything in your workflow-- tests,
image resizing, et cetera.
We shouldn't be doing any of these things by hand
because then no one's going to do them
after the first time you make the site faster.
We have a Seller Handbook at Etsy.
This is something that content editors provide for people who
use Etsy to sell their goods.
And there's a ton of really gorgeous graphics
that are included in Seller Handbook.
So we wanted the site to stay fast
as these content editors were creating
this content for our users.
So the group of people who are responsible for this
are not designers or developers, so performance
isn't a part of their workflow.
How do we make it easy for them?
So another development team was working on their content
management system, and they decided
that SourceSet would work the best, right,
delivering appropriately sized images to devices.
So as they built out the CMS, they
made it so that anytime any content editor uploads
an image, it's going to be really easy.
We're going to, on the back end, just process it
into all the different sizes that we're going to want
to use at our SourceSet.
The content editor will just be going
through the process of uploading an image just normally,
and they won't even know that behind the scenes
SourceSet is providing all of this stuff on the front end.
There it is.
Makes it so much easier for people.
We measured the performance impacts over office Wi-Fi.
Huge, huge, huge, 14x savings on users of small screens.
Imagine the savings over cell networks.
At this point in the presentation,
usually people are asking themselves, ugh, OK,
so if I do this once it's going be cool,
it's going to make it faster.
But how do I make this last forever, right?
Who's going to be responsible for doing this stuff at my job?
Maybe it's engineers, maybe it's designers, maybe management.
There's somebody in your brain, probably, who you're
worried about when you're making the case for implementing
these techniques.
Being a performance cop or a performance janitor
at your organization is not sustainable.
Performance is truly everyone's responsibility,
otherwise you'll be endlessly fighting an uphill battle.
You need to create a culture of performance,
but this is probably the most difficult thing
when it comes to optimizing your site for performance.
We at Etsy even still struggle with it.
And we've had top down management
buy-in and a metrics-focused development cycle for years.
Again, remember, perceived performance
is the most important.
I wrote an article on A List Apart about this
on how helping everybody around you
feel the effects that your users are actually experiencing
on the website is going to be truly helpful in helping you
get that culture performance.
Because we sit at our really fancy office
desks with fast connections and probably pretty shiny hardware.
We forget what the user experience is
like for the rest of our users.
I go around to a bunch of companies giving this talk
because, frankly, I want all their websites to be
fast so that when I'm browsing the web,
I have a better user experience.
But earlier this year I got to speak
at Hillary Clinton's campaign office,
and I showed this video.
I was highlighting for them how the impact
of how fast their site loads has a huge impact on how
people feel about it, right?
So you can do this with anything.
You can do this with your site before and after performance
improvement.
Start to highlight how much faster you made
the site feel for your users.
Start comparing your desktop experience
to your mobile experience.
Start comparing your domestic experience
to your international experience.
Or compare you and your competitor.
It is mind-blowing how much more effective
it is on what I call VIPs, right, the Very Important
People-- your bosses, their bosses, et cetera,
to get them to care about performance work
just by showing them what your competitor is doing versus what
you're doing.
I asked on Twitter if other people are doing this as well,
and from across the world, people
are finding showing videos to their coworkers extremely
valuable, and clients.
Additionally, I recommend publishing this stuff.
So back in 2011, the person who was running the performance
team at Etsy, Seth, he wrote our first ever performance report.
This is public.
We just talked about our numbers.
How fast was Etsy loading, and what were we
going to do about it for different pages?
It was so sneaky what he did, right,
because it forced everybody at Etsy who
works there to care about it.
Whereas there was just a performance team
caring about it before, he was kind of embarrassing
the rest of the people that he worked with if their pages were
loading too slowly.
And it forced those people to iterate and improve
on our most important pages.
This act of publishing a performance report
also reminded us that these page load times are not secret.
There's nothing secret about these numbers.
I love it when companies are like,
no, we can't publish that.
It's too sensitive.
But anybody can visit your website,
anybody can run your site through WebPagetest, right?
Your competitors are probably already doing this.
So we immediately started seeing buy-in
from development teams across the company,
and it's continued to be a focus for us.
In fact, the next time we publish a performance report,
you can see that our home page originally
in August of that year took an embarrassingly long time
to load.
But by the next time that we published it in November,
those developers had seen a problem, they were aware of it,
and they worked really hard to fix it,
making it one of our fast pages on the site.
And the side effect of all this is uncovering performance bugs
that we wouldn't have otherwise seen, which we actively
celebrate internally.
This is a dashboard that we create
and we update routinely whenever someone
who's not on the performance team
makes a huge win that improves the speed of our site.
We love to-- [CHUCKLES] we've got a little cross stitch
embroidery thing that has little hearts in the word
performance on it.
We force them to hold it and we take a picture with them.
And we put up a bunch of graphs, and we talk
about, we surface this stuff.
We announce this internally.
We make a huge deal out of whenever
somebody else around the site makes
an improvement that improves our overall user experience.
We even put up bunting, right?
We really do celebrate this on all of our walls
inside the company.
And I have started to use that monitor for other purposes,
like again, getting people to feel our real user experience.
WebPagetest will create these videos for you,
and you can have them use any kind of mobile connection,
like a simulated 3G connection, which is the one on the right.
And you can start to feel how users in crowded areas,
in areas with poor internet infrastructure,
especially lower socioeconomic areas, people
who are forced to only use mobile devices,
this is their real user experience of our website.
I want people who are walking around our office who, again,
use shiny devices and really fast networks
to see what this really feels like.
I call this dashboard Sorry, Australia.
[LAUGHTER]
Right?
We're based in New York.
Our closest data center is in New Jersey.
We don't feel this pain.
We don't know what our users around the globe
are really feeling until we force it on you, right?
I need to put up these dashboards inside the office
to get people to feel what this stuff really
is like for our users.
We need to have empathy.
Not just with our users though, but with our fellow designers,
our developers, our upper management.
We need to help them care for our users and their experience,
too.
As Brad Frost says, good performance is good design.
There is a ton of other improvements
that you can make on the back end, but 80% to 90%
of the end user response time is spent on the front end.
And on mobile, it can be upwards of 97%.
So optimize for good performance,
and you'll have a huge leg-up on creating excellent user
experience.
For all of this information and more, it's available for free
on DesigningForPerformance.com.
I made the book publicly available.
I'm so excited for you to go and check it out.
I will point out though that you should go and buy 12.
Or have your company buy 12 copies of it
because all the proceeds of the book
go to charities focused on helping
under-represented people in tech become more involved
and learn more stuff.
So please pick that up.
And with that, we're going to go to Q&A. Also,
follow all your performance dreams.
The other thing I wanted to mention before I go
is that just today A Book Apart announced this other new book
that I'm pretty proud of that's coming out.
[APPLAUSE]
Yeah, so if-- thanks.
So if you want to do what I'm doing, go and check it out.
Thank you so much, everybody.
Enjoy your lunch.
[APPLAUSE]
For more infomation >> Howard Kurtz on bad month for Avenatti, new Cohen plea deal - Duration: 3:18. 
For more infomation >> Prohibition for the Paws (Part 2) - Duration: 3:30. 
For more infomation >> Reward increased to $15k for KPD attacker - Duration: 0:25. 
For more infomation >> NASA's plans for a return to the moon - Duration: 5:48. 
For more infomation >> Do Baking Soda Work For Heartburn - Duration: 2:14. 
For more infomation >> SE Michigan weather forecast for Nov. 29, 2018 -- afternoon update - Duration: 2:20. 
For more infomation >> Greer family making rolling pins for Magnolia Market - Duration: 1:58. 
For more infomation >> Tour an open concept home in Webster Groves decorated for the holidays - Duration: 2:35. 
Không có nhận xét nào:
Đăng nhận xét