Do This to Improve Image Loading on Your Website

(upbeat music) – I want to show you
something that you can do if you make a website, if
you’re a web developer, to improve the way that
images load on webpages and create a much better
experience for your users. Let me first show you how
things have been working. I’ll show you what the problem is, and I’ll show you a
new thing that’s coming that’s going to solve this problem for us if we just make sure that we set things up a certain kind of way. So let’s go back in time to like 1995 or 2005 when we had websites that kind
of looked like this, right? So here I’ve got an h1
headline, I’ve got a paragraph, an image, and a second paragraph. And I actually, for all
of these, I put a border around the image, itself,
just so we can see the image and sort of see how big the browser is trying to make the image
at any given moment. So let’s go over to this
tab, and we’ll look at this by itself, and we’ll look at
how it loads if I hit refresh. And if you look carefully,
you can kind of see that the image- Well, it’s actually really hard to see, so let’s open up Developer
Tools for a second here. And we’re going to come over
here to the Network tab, which could be anywhere,
but I’ve put it here. And I’m in Firefox, by the way. I happen to be in Firefox 69
because it’s October of 2019. Uh… and I’m going to say disable cache, which is going to make sure that the — it reloads the image every single time, which is what we want right
now to show you this demo. And I’m going to slow down the
network speed to 2g speeds. And then let’s load this. So what you can see as this is loading, is that, that first paragraph is coming in and then the second
paragraph is being painted immediately, right after it on the page. And the browser sort of, it knows that it’s going
to put an image there, but it doesn’t really
know how big the image is, so it just sort of
makes a zero pixel tall, zero pixel wide space for it, which would normally be invisible. But because we have this
little border around it, you can kind of see this little border. This little black box shows up where the image is going to be. And it creates this
kind of weird jankiness, this thing that people
have been calling jank. So the solution to this
back in 2005 and 1995 was to put the width
and height information on the image itself, so that the browser doesn’t
have to download the image in order to know what this information is. It can just read it
straight out of the HTML. And the syntax from
this, which goes way back so the early days of HTML is to say width=”750″ height=”500″. There’s no, there’s no pixel here. There’s no em or rem. There’s no unit. It’s just 750, 500. Those are the actual numbers of pixels in the image itself. This, of course, was back in the day before we had retina screens and stuff, so it wasn’t that complicated. It was just, “Hey, this
image is 750 x 500.” And that basically tells the
browser how big it’s going to be. So if I save this and then I refresh, you can see that it’s drawing a space that’s the correct size
space for the image, even though the image isn’t
really downloaded yet. It puts the paragraph, that
second paragraph, lower down where it’s going to be later in the page. And then as the image loads, it goes ahead and loads the image into that space. That’s really cool! This is why back in the
’90s and in the early 2000s, we would tell each other, “Hey, we should always include the width
and height attributes on any HTML image because
it improves performance, especially on super slow
network connections.” Ever since responsive
web design came along and we stated resizing images with CSS, that solution no longer worked. You can see here I’ve got width and height on my image attribute,
but I also have here in my CSS, a width of
100% and height of auto. And if we look at what
this does in Firefox 69, you can see that in fact when
the image size is calculated for the first paint, it’s being calculated as zero pixels tall. It knows how wide to make it, 100%, whatever that containing block size is, but it doesn’t know how tall
to make it, so it sort of makes it zero pixels tall to start with. And this is creating
that jank problem again. Now there is a solution for this. and if you go into
Firefox Nightly right now, you can see it working in action. Here we are, the exact same example and I hit refresh, and
the browser knows how big to make the image, even if
the image hasn’t loaded yet; it figures that out from the HTML here. It takes the width, it takes the height, and now even though that
width, actual pixel number and that height actual pixel number are no longer going to be true, because CSS is making the
image be a different size, the browser takes those two numbers, it turns them into an aspect ratio, and then it uses that aspect ratio on the very first time
it calculates the page. It works today in Firefox
71, in Firefox Nightly, and it probably is going
to ship in Firefox release when 71 releases on December 3rd, 2019. This is a thing that folks
at Mozilla, we at Mozilla, we’ve been working on an aspect ratio property for CSS that will be super handy for
doing things like resizing iFrames and videos that
come in through iFrames and then we no longer
have to use JavaScript to handle that kind of stuff. We’d be able to say, maybe
even make any sort of a div! Give a div or any element
an aspect ratio and say I want this particular
element to be a square, or to be a square if it can be. If there’s more content then go ahead and make
it be taller than that. That aspect ratio CSS property is going to be pretty cool in the process of coming up with that. The CSS property — talking
to browser engineers, as I was working on the spec and the Elika Etemad was working spec and we were talking to Emilio [Cobos Álvarez] and a bunch of other people at Mozilla who work at CSS Working Group. It occurred to us that we could use those
ideas that we were discussing to change the way that the browser interprets the width and the height attribute and uses them in painting the page. So we just went ahead and shipped that. We’re doing that first. So basically, the moral of the story is hey — if you’ve been taking the width and the height attributes off of your CMS, off of your HTML, not publishing them — put them back or if you’ve never had
them, put them on there. Lots of times the robots go ahead and generate this content anyways, these attributes for the HTML. And we don’t necessarily have to write them manually, you just set up your your
content management system and your build system
or your whatever… app. So that it prints them out. And it will then have a huge performance
enhancement with Firefox 71 starting in December of 2019. The Chrome team is also working on it. I think they might be
shipping it just after us, also in December of 2019. You
can send it out today though. Early ahead of time and make sure — you know, test it, make sure it’s going to work. A couple of details to
know about one of them is that you’re going to want
to make sure that you have `height: auto` in play here or perhaps `width: auto`, depending how you have things set up but, for instance if you have
`width: 100%` on something. If you didn’t have a
width and height attribute then you wouldn’t need to
say anything about the height you could just go ahead
and get away with that. But, if we only have that and we do have a width and
height attribute involved then what the browser is going to do is it’s going to use the height attribute to set the height of this image. So, right now this image is
set to be 500 pixels high and then width is being resized as 100%. Which is making the image get all squished and constrained and we don’t want that so we want to make sure we
have `height: auto` on the image so that when we resize the image the height is —
it’s like auto height. It’s changing based on
the width of the image and that the aspect ratio, the inherent shape of that
image is always obeyed. It’s always respected and the height will get changed by CSS just like the width does. So make sure you have
`height: auto` and things, or like I said if you are putting — maybe you’re doing `height: 100%` or `height: 50%` in which case
you want to do `width: auto`. What if you’re using responsive images? What if you got multiple different flies and those are being swapped out based on different conditions
like the screen whether, its retina screen or super-retina screen or super-duper-high or
whatever-its-called-these-days retina screen. Or you
have a bigger window or smaller window,
different types of viewport different there’s all these new techniques for using multiple image files, right? So, what do we do in that case? Well if your using image
with sourceset like this you don’t need to worry so
much about the fact that perhaps the image is going
to switch from an image that is 375 by 250, to an image that’s 750 by 500, to an image
that is 1500 by a 1000 because the aspect ratio for all three
of these images is identical. its always the same shape, the same kind of rectangle, not like you have a wide rectangle, some times it a square other
times in a tall rectangle sometimes its always the
exact same its always, I think this is if you do the math this is 1.5 to 1 aspect ratio
for this particular image and so saying width of 750 and height of 500 also calculates
out to 1.5 aspect ratio. And it’s fine, it doesn’t
really matter that the number of pixels is not the number of pixels. What matters is that the aspect ratio from this width and height is the aspect ratio for all of the images and your good to go. so image source set totally fine uh and I believe it will work. I think it will create a performance enhancement just like this although go ahead and test it and see you can try it out like I just did and see weather or not it’s helping. The harder thing and the
more complicated thing is what if you are using responsive images to switch out different images so they have different aspect
ratios of different sizes of screen or different kinds of contents some people call that the
“art directions use case” where maybe on a mobile screen you want to have a square photo and on a big wide screen you
want to have a big wide photo. Um, yep that’s not
going to do anything yet we don’t yet have a
performance enhancement for that use case uh
we’re debating right now and this specification
world discussing specks and options on what we should do. I’m hoping that what we’ll do is we’ll just have it be we put width and height on our
sources on each source elements and then we can have those height and width attributes swap out as things are as the image file swapping out cause that’s basically
what’s happening right now, is that this particular
source gets swapped out for this particular source right here So I think it’ll be
pretty cool if these width and height attributes go ahead and get swapped out for these width and height attributes right here but. I want to tell you this right away, let you know if you especially, are working on open source
content management system or if you have a bunch of websites with a whole bunch of
different kinds of images and a lot of different
robots running around posting images for people. You probably want to take look at that and see what would if mean how could you put the width and height attributes back in. Do you need to adjust your CSS at all and put in height auto
for example, in situations and go ahead and do that
over the next couple months so that you get this performance benefit the moment it ships in Firefox (up beat music)

Add a Comment

Your email address will not be published. Required fields are marked *