OK, so we have one more speaker in this section on forms and accessibility-- again, I think leading on quite nicely from what we've seen so far.

So Estelle, while you may know from various books and various writings about HTML and CSS over the years, currently working as an open web evangelist-- have I got that title correct? Yes-- at Instart Logic a company who help with performance and optimization of sites.

So kicking straight along with how responsive web design is not necessarily a panacea, Estelle Weyl.

Thank you.

[APPLAUSE] OK, so my name is Estelle Weyl.

And the reason that I speak at conferences is because I'm a Twitter whore, and I want followers.

So please follow me at any of those.

And you can also follow my blogs at Standardista or Instart Logic, and that early release, coming out next week.

So to go with Toby's talk with today, it's on transitions and animations.

So I'm not here to talk about myself.

I'm here to talk about responsive web design, and what we're doing right now and whether it's the right thing to be doing.

So Dawn wrote, just because no one uses your mobile site doesn't mean you don't need to improve it.

Maybe no one uses it because the experience is shit.

She was more polite.

And some random person on the web who I don't know, but she's always right, says, "Nothing pisses me off faster than a slow website.

By the time the page loads, my patience is gone and I don't want to buy it anymore."

And these are things we know.

So two years ago, when the BBC released their mobile design, they saw a slight decrease in their desktop because their tablet and their mobile devices went up by so much.

So we've seen in the past that going mobile can be helpful.

But the problem is we have over 10,000 Android devices.

But the thing is, it's not that much of a problem because they actually all have the same aspect ratios, or similar aspect ratios.

So you design for one aspect ratio, and you're good.

But notice that these plots go up and to the right, but they're not all 320, 480, 640, 960.

There's not even a cluster of them there, except for around 600, I guess.

So when you do your design development, break where it makes sense to break.

If your header looks good up to 600 pixels, then break your header at 600 pixels.

Whereas if your form looks good only up to 420 pixels, break your form there.

You don't have to break everything at the exact same spot.

Break it where it makes sense.

So when Tim Berners-Lee invented the internet-- or did he invent the web? His official title is web developer, because that's what he developed.

I love that.

So he wrote, when he first created the web, that the principles-- basically, that you should make your web applications work everywhere, no matter what the hardware is or software that the person is using, whether they have a good network or a crappy network, no matter where they are in the world-- which means a crappy network for a lot of people-- and whether they have physical or mental impairments.

The web should work for everyone.

So when I was looking for a crappy site, I actually got a 404 error.

And this is it.

And this right now, with the screen shrunk down to almost nothing, is not legible to me.

I wear granny glasses when I'm reading, and I don't have them on right now.

So this is what it looks like on the desktop.

But when you put it on mobile, it looks tiny.

It's going to go down again, but I'm not going wait for it.

Or maybe I will.

[FAKE SNORING] OK, can anyone read it? Can the people in the back row read that? No.

So to solve that-- this is an accessibility issue-- takes one line that for some reason they don't put in their header, which is metaName = viewport content = deviceWidth.

And that would take care of it.

You can add userScale = yes.

You should never add userScale = no.

Viewport metatag will be in the CSS.

And it should be supported soon if it isn't already.

It basically takes that and puts it in the CSS.

But it basically allows you to control the viewport size, the zoom factor, and the orientation.

Simply adding that one line makes it go like this when you go on a mobile device.

It's not perfect.

It's not responsive.

But at least it's usable and it's accessible.

Don't do what Google does.

Google-- I called him a jerk, yeah? I want to call them a word that starts with "A" but I decided not to.

So what do they do? They did maximum scale 1 minimum scale 1 user scalable no.

I cannot read Gmail on my phone without pulling up my glasses.

That means if I'm wearing my sunglasses, which are not granny glasses, I can't read my mail.

Initial scale 1 is fine.

Width equals device width is fine.

Put those two in, and you'll make your site accessible.

So this is the solution if you need to come back and look at it.

So let's talk about responsive design.

Responsive design-- I don't know if you guys know Zoe Gillenwater.

She works at Booking here in Amsterdam, and she wrote the book called "A Flexible Web Design."

And this is the original book on responsive web design.

She just did not key the term.

So I give her credit for actually coming up with what is using a fluid grids, flexible images, and media queries.

And that's what we have been doing.

The problem is-- I'll just read this.

"I remember when 3G was primary mobile speed.

It was slow, but the sites basically still worked.

So why now, when my phone says 3G, it's become completely useless?" I bet this person is blaming their network.

It's not their network.

It's Disney's fault.

This is Disney's web page-- because of this.

So if anyone else is using the internet, I cannot download their site because on the desktop, they have three megs coming down.

On mobile, they have three megs coming down.

123 requests-- I don't know if you have metered internet access here on your mobile device? That's not accessible, and super expensive.

So it's actually a really pretty site, but is it accessible or usable? The primary thing with accessibility is getting the site in the first place, right? You don't have accessibility if you don't have any content.

So responsive web design-- this is Google's definition.

And you can read it if you want, but this is what I think most people interpret it as.

Let's just give you a squishy design.

Websites have gone up by 339% since 2010.

These stats are from the HTTP Archive.

The numbers below are actually when it had gone up to 290-something percent, so the numbers are a little bit off on the slide.

But basically, people have been making sites responsive by making them squishy.

So here, this was done by SpeedCurve.

And it took a look at 100 sites, and then it plotted what the bytes were based on the breakpoint.

So we have 320 over there, and like 1,400-- I don't remember what the high number was.

But you'll see, that's 38% of people did absolutely nothing for their web pages.

And "Newsweek" went in the wrong direction.

And people are using the internet here, so I can't actually load my beautiful sites.

But what did "Newsweek" do? Actually, on their beautiful responsive website, they decided that 400 kilobytes more was a good idea.

And they decided that 30 extra DNS lookups and HTTP requests was a good idea, and they brought the loading time to 34 seconds.

So let me tell you a story about what Google did.

You might have heard this story already, but several years back one person, on their 20% time, created Google feathers-- or YouTube feathers, which was they decided to give themselves a budget of 100 kilobytes and as few requests as possible.

And so they created the Chrome basically of the YouTube page-- so not including the video, but everything else, and they had it at 100 kilobytes and 14 requests.

And when they launched it a few weeks later, they looked at the stats and it was taking about two minutes longer for the download time.

So they thought to themselves, what the heck is happening? Our site is so tiny, and yet the time is going up.

And what happened is that they got into new markets.

In Siberia, they were now able to access the web.

In the middle of Africa, they were now able to access their kitten videos, which is very important.

So basically, speed is more than just a feature.

It is the most important feature.

And I think we all know this quote, or we wouldn't be here today.

So the point being is, reduce the size of your requests, reduce the number of requests, and reduce the number of DNS lookups.

And we already know this.

This is from YSlow 2005, 2006 this came out? This came out before we had smartphones.

Most important things for mobile is make fewer HTTP requests, reduce DNS lookups, and don't scale images.

So I'm going to talk about scaling images and responsive images.

Responsive images is more than making him squishy.

One thing is to compress them.

If you reduce the size of your JPGs down to where they start not looking good and then adding 1%, you're good.

You can reduce about 70% of the size.

GZIP everything.

Binary files, GZIP doesn't do that much good.

SVG is an image format.

Please GZIP your SVG files.

You can lazy load.

You can put Display None on the parent element of an element that has a background image.

The browser will not download that image.

And then, only load the size of the image that you need.

We now have the picture element, and we have the image source set.

Apparently, in Europe I am known for the clown car technique, which I created about four years ago, which I didn't actually think anyone used until I came here a few days ago and people are like, oh! And I'm like, wow.

So anyway, I'm covering the clown car technique, mostly just to show you the image squishing.

So this is one way to swish an image, which is there's four images here.

There's small, medium, big, and huge, because I'm really good at naming things.

And it's 100% of the image size.

So no matter what, when you're scaling your thing, if you say your image should be 50%, your foreground image should be 50% of the width of the page, that image will be 50% of the page.

Then, there's a different way of serving images, which is serving an image of a few different sizes and leaving it as size auto.

And while most people don't choose to do it this way-- you see how it's jumping, like when you scroll it and it gets to a certain point it will get bigger? It's actually much more performant.

So I just want to leave the code up here to show you.

Now you can use picture and source set for mobile devices-- for most of the newer ones, not for older Android and not for older iPhones.

But who is using those anymore anyway? A lot of people, just so you know.

There's a picture element.

You put a source with the source set, which is the image.

Then you put the media.

And then, when you picture, always include the default image because that is where you include the alt attribute.

Do not forget to include the alt attribute.

If you forget to include the alt attribute, they get the file name.

And that's usually high resolution.

It does not help me know what that image is about.

But another reason I want to talk about images is because when you right-size an image, you don't have to decode it twice.

When you actually resize an image, you have to decode it.

So this is from IE's test.

And they show that it took three times longer to decode an image that was the wrong size.

So I asked them to do this test again for me in Edge, but I haven't gotten the results yet.

I assume this is not as much of an issue.

But there's another big issue when you don't right-size the image.

So in this case here, I just use the clowns because I hate using image editing programs, so I reuse my images over and over and over again in my decks.

When you serve a small image that's the wrong size, you do get a few extra bytes.

In this case, the 240 by 240, we're serving a 240 by 240 image when we only needed 200 by 200.

And we had 17,600 extra bytes.

That's actually a lot, but it's not the end of the world.

When we get to 640 by 640 and we only really needed 600 by 600, we were serving an extra 49,000 bytes.

And when I went up to 840 when I only needed an 800 pix image, it was in the 60,000's.

So right there, by serving the right size image, you're saving a lot of bytes.

Right here up here is a link to Cloud Four's image breakpoints article.

It's a really good article.

What it says is when you get to larger files, make more breakpoints, because the extra bytes add up really quickly there.

So responsive images-- make fewer HTTP requests, because we have this issue.

When you're not in the conference hall with a bunch of people who are stealing your internet, when you're at home or at the office, you go from your computer to the router and you're good.

It goes directly.

You have access.

When you're on your mobile device, it goes from your browser to the cell tower to the phone company to the DNS server, back to the phone company, back to the cell tower, back to your phone-- I'm speaking really fast, just for you over there.

And then it goes from the mobile browser, now that it knows the IP address, it goes back to the cell tower, back to the phone company, back to the server where the actual site is, and then all the way back.

Where you get the most latency is in the air.

Air does not conduct very well.

So the solution is to make fewer requests.

And with HTTP 2, this is going to be less of an issue.

But we are not at HTTP 2 yet.

We're at about 8% of sites or something like that right now are supporting HTTP 2.

Modern browsers are supporting HTTP 2, but we are not all on modern browsers yet.

So what you want to do-- you want to set breakpoints based on the design, not the phone size.

You want to reduce HTTP requests.

You want to reduce the page wait.

I had a talk on CSS scotches, and Toby completely clarified that everything I had said several years ago was true and now resolved.

You'll want to use the right input methods.

And we had Marcy, and that was covered in the last two talks.

And what we also have is-- so we have covered bandwidth and latency, but I also want to cover memory, battery, and responsiveness.

So when I showed you this image, I did tell you that it took three times longer, if you remember correctly.

What I didn't point out was the blue.

And that's the CPU of decoding this huge image.

So decoding images uses up CPU.

JavaScript uses up CPU.

CPU, when you have your fan going on your computer, imagine what it's doing to your mobile device.

So Scott made a joke a while back-- actually, two years ago now-- is your battery draining too fast? Turn off everything that makes your smartphone smart.

That'll fix it.

So let's talk about resolving that.

Every line of JavaScript needs to be downloaded, parsed, and executed.

Once you've downloaded, you can cache it.

But still, when you change a page, it needs to be parsed and executed.

That uses up CPU.

So don't just use 412 frameworks.

I look at frameworks this way.

When you're building a bridge, you'll have scaffolding.

Right? But you don't let people ride on the scaffolding.

You actually build the bridge.

When you're building the website, your framework should be your scaffolding.

You should be getting rid of your framework.

The last company I worked for had 41 dependencies, 55,000 lines of JavaScript.

I recoded the site in 1,000 lines of JavaScript.

It was just basically what I call RDD, resume-driven development.

So back to the tall-- don't abuse your user's battery.

They won't know that it's your site destroying their battery life time.

They might not know.

But you know, and don't be a jerk.

So fluid reflows and repaints.

Minimize the JavaScript size and activity.

Use RequestAnimationFrame, or preferrably, CSS animation.

Based on Toby's talk, use certain things to animate.

Don't animate other things.

Manage memory and avoid waking up the battery.

That is, other than the light, the biggest use of battery is the radio.

So you don't want to keep waking up the radio.

And remember that your users don't all have your laptop's CPU.

My new Mac, which is bottom-line, has 16 gigs.

My first iPhone had 128 megs.

And the phones that they're selling for $35 each has 128.

So yes, the Samsung Galaxy Note has three gigs, because they want to be better than all the other devices.

But the average smartphone that we probably have in this room-- I'd say the median, not the average-- is one gig, because I'd say 90% of you probably have exactly one gig.

One of you might have the Samsung Galaxy, and a lot of you probably have less.

So remember to think about your mobile users.

They have the most modern browsers, but they're on the crappiest devices.

Minimize the DOM.

Ensure responsiveness.

So user interaction, you should aim for-- we've already talked about this, so I don't have to go in-depth.

And we know that we need to aim for 16.67 milliseconds,

or 60 frames per second.

So I do want to talk a little bit about responsiveness, which is the touch event.

When the user touches the device, because I've told you now that you can't use zoom not scalable.

If you do use not scalable, the click event actually happens right away.

But you're not allowed to use it unless you are developing a game.

And who here is a game developer? OK, so who here is not a developer-- that's everyone but those two people.

So two people are allowed to not allow zooming.

Everyone else has to allow zooming, which means there's a 300 millisecond delay waiting for that second tap.

What you need to also realize is that in terms of accessibility-- oh, first, so I don't think that you should usurp native interactions.

But in this case, because of the 300 millisecond delay, which is longer than the 100 milliseconds that I said makes it responsive, you can add a click event or a touch end event.

And in terms of accessibility-- I learned this from Karl Groves today, or confirmed it rather-- which is when the screen reader's using voiceover and they tap it, the usurpation of click or touch end event will not actually work.

And it shouldn't work, because they tap and they're told what's underneath their finger.

They have to do a double tap to actually activate a link.

So by using the click or touch end event, you're not destroying accessibility.

So when you're developing a site, give yourself a performance budget.

Your PM is going to force you to go over it, but at least you'll be able to argue and say, you know what? We want to stay under half a meg, and you're going to make this go above.

So at least it gives you a starting point.

So just to close out, good design is not about making something pretty.

It's about making something usable and intuitive.

The beauty of the product will be the result of these things.

If you want to see the slides, the slides are up at this link.

Just remember where I work, which is called Instart Logic, and go to that GitHub page.

And all my talks from 2016 on, because now I have a job, are there.

If you want the ones from 2015 and before, my name's Estelle and I have estelle.github.io,

because I'm the only engineer named Estelle.

So all my other talks are there.

And thank you very much.

[APPLAUSE] Thank you, Estelle.

Come and take a seat.