Chair of the responsive images community group

Fought the good fight against the W3C process

We’re here to learn, and he is hear to teach us all about… furniture.

Showed us a picture of a Queen Anne Coffee Table. We don’t care about what kind of table it is, or its origin story. We care about its purpose.

Our users don’t care about the website. They don’t care about the browser they’re using, or the framework we used to build it. They want their content and that’s the purpose of the websites we build for them.

If we present a user with a loading icon, big web fonts, or GOD FORBID tell them that they’re using the website WRONG, we are breaking the fourth wall. WE are doing it wrong.

OperaMini is a proxy browser. It’s use is increasing. This browser gets them to information quickly. It serves their purpose.

We are choosing to build sites that fit within our day to day browsing contexts, the conditions we as developers are used to. We have tons of bandwidth, wi-fi, advanced devices, stable network connections… We can be sure that any request we send out will result in something being sent back.

Chris Zacharias was tasked with reducing the size of YouTube’s Watch page from 1.2MB to 100KB. that’s ridiculous. After successfully doing this (crazy!), large numbers of people who were previously unable to use YouTube were suddenly able to.

At 100KB it took 2 minutes for the page to load in certain parts of the world. At 1.2MB, it took 20 minutes. One developer took a few hours of work and made a very real difference in the lives of many in another part of the world.

We’re building a web for us. A web that is easy to assemble but crappy to use. The web is not IKEA.

By working just a little bit harder, entire populations just setting foot in the web can access content they could not before.

We can build things for how REAL people around the world use the web.

Mobile/Tablet accounts for 35% of the use of the web around the world. In some pats of the world, desktop access of the internet is basically nonexistent.

In just the 3rd quarter of 2014, there were 110 Million new mobile subscriptions. 32 Million of these were on an Edge network.

72% of responsive sites are sending roughly the same data to mobile and desktop users.

How can we change this?

Responsive web design is still pretty new. We’re a little clumsy about a few things but we have some tools to get us started in the right direction.

———-

Average webpage transfer size is 1.9MB. Images alone count for 60% of that.

Why is the average image weight increasing? Retina screens, obviously. A true retina image can be up to 4x larger because it’s twice as big in both directions.

The vast majority of users worldwide will see no benefit.

Janocycles.com – amazing website… photography is amazing… but it is heavy. 14.4MB.

In comparison: http://wil.to/5U <- a link to download the single works of Shakespeare in a PDF. Just over 3 MB.

If you were to download this file 3x it still wouldn’t equal the resources used to look at that one page on Janocycles.com to look at some motorbikes.

max-width: 100%

Trouble with this approach is it requires us to use an asset that is AT LEAST as large as the largest place it will ever be displayed. It you could display an image anywhere from 300px to 2000px, you have to start with at least a 2000px wide image. This is wasteful.

The <img> tag used to suck… it could only do one thing well, which was fetch an image and display it. Now it sucks less.

Prefetching, or speculative pre-parsing is a huge part of what makes browsers feel fast.

They put together the AVENGERS OF SEMICOLON PLACEMENT and still they got nothin’. If HTML5 offered a way to solve this, what would that look like?

<picture>

     <source src=”large.jpg” media=”(min-width: 60em)”>

     <source src=”medium.jpg” media=”(min-width: 40em)”>

     <source src=”small.jpg”>

</picture>

They approached the W3C about this and were told that the necessary paperwork had not been done and it was not his position to bring them solutions. It is his place to bring them problems for them to solve… haha WTF.

The best thing they could come up with: Bandwidth media query… but they actually hated the idea. They couldn’t guarantee a consistent user experience. There was also a technical problem. Bandwidth is unpredictable. Media queries are designed to respond to CHANGES on the user side. When the user first lands on a page, they may qualify for a high resolution images based on their original bandwidth, then they would lose that bandwidth if they go through a tunnel… the only way to work around this would be to redefine the very nature of media queries themselves. That was not well received.

The srcset think the W3C proposed was worth looking at… It was a way to suggest to the browser what would be appropriate for them. The browser could then present options to the user like “always show me low res images.” Now the decision is being made by the user, not by us for them.

If you needed precise control over all your images you could use this in combination with <picture>… but we don’t want to work that hard. We really just want to specify a few different image sizes for different scenarios.

<img sizes =”100vw”

    srcset=”small.jpg 320w, medium.jpg 480w, large.jpg 768w”

    src=”x-small.jpg” alt=”…”>

Jason Grigsby’s talk is going to get into all the gritty details.

This allows you to generate a couple images sources and then walk away.

File type: WebP

——-

Bitmap images are only half of the story. Retina screens mean retina assets across the board, including ICONS.

Pictures shouldn’t be made of math… There are tremendous benefits to using SVG, but he is hesitant to work with it.

Where SVG’s fall short – universal support. They work in a lot of browsers but not all of them. Leaving a user without icons may very well leave them without a navigable menu. Which means we’d have to specify a bitmap fallback image for every SVG icon we had…

Something we had to destroy: SPRITE SHEETS

They are a relic. They are a hack. However, you can’t argue against their effectiveness – a single cached request for every icon on the site? Awesome.

We can do this with SVG’s! Why not put all of our icons in a single style sheet with data URI’s… When we serve this up with GZIP enabled this is even smaller than a sprite sheet!

Grunticon – a GruntJS task that helped with this process.

But some of the benefits of SVG were lost by using Grunticon, like the ability to style them in the code.

Grunticon2:

data-grunticon-embed (just like that) can be added to the img tag to embed the element into the page instead of flattening it like a jpg. Now you can style them with CSS like any other element in the page!!

By changing our strategies for images alone we are able to make smaller and faster websites.

When we talk about speeding things up on the web we are talking about speed performance. The most valuable metric for the speed of a site is the user’s perspective.

WebPageTest.org does an incredible amount of user based performance testing. It allows you to AB test performance changes you are making on your site on the fly.

——–

Request for external stylesheets can have one of the biggest impacts on perceived performance.

IDEALLY we could use the media attribute to specify and serve only the stylesheet that is appropriate for the user. This doesn’t work… and for good reason. Because if someone’s connection or device information changed, we would have to reserve a different stylesheet.

A brand new TCP/IP connection can include of to 10 TCP/IP packets. That’s around 14KB. Just the markup and any styles that we inline in the head of that markup… So what if we sneak in only the styles we need in the <head> tag and defer the rest to external stylesheets.

So we could deliver a visually complete page in the time it takes to connect to the server.

Detecting critical ‘above-the-fold” CSS is also an automated thing you can do. grunt-criticalcss

JavaScript LoadCSS

     /* This next part is about javascript breaking */

——

Unit testing for performance:

grunt-perfbudget

——