WARM-UP VIDEO FOR COMPARATIVE ADJECTIVES.

Instructions. Listen and type comparative adjectives.

------------------------------------

Exercise. Complete each gap with suitable words and expressions you hear from the video.

And when I look at the overall size of the page, first of all, an average page is about 700 kilobytes. So it's actually a little bit (1) ………….. than a desktop version, which is good news. But then, this number actually shocked me. types, images are basically 70% of the data on the wire. STEPHEN KONIG: That's pretty typical. It's actually a little bit (2) ………….. on mobile than what we see on desktop, but the fact that it's the single largest component of the page size is very consistent with what we don't look so good. And so it's putting a lot of pressure on publishers to update their sites and their images to look (3) …………..on these hiDPI devices. ILYA GRIGORIK: And that's a really hard one, right? Because to your point (4) ………….. , my bandwidth is not going to up magically by four, or latency decrease by four, but all of a sudden, the images are getting four times (5) ………….. . STEPHEN KONIG: Exactly. ILYA GRIGORIK: And I think, actually, the four is worth So if you're using a lossy format like JPEG, in addition to that, what you're probably going to see is a demand for (6) ………….. quality images with your compression artifacts. So that in itself will also play a part in increasing the size. ILYA GRIGORIK: Right. So there's probably no magic bullet to say we can have both hiDPI and a (7) ………….. file size, but perhaps there's a middle road somewhere in between. STEPHEN KONIG: Exactly. format is actually a challenge. STEPHEN KONIG: It is. ILYA GRIGORIK: So as I mentioned (8) ………….. , when I talked to a lot of web developers and designers, they say, great, I took my image, I optimized it. formats in the background. And then we figure out that, hey, this image file is actually much (9) ………….. compressed if we use JPEG, for example. So we don't assume anything about your decisions. animation and metadata. So that will replace the GIF use case. (10) ………….. term, we're looking at ways of improving performance on the encode and decode side, so we're always looking at optimizations we can do there. to talk about that. STEPHEN KONIG: We're going to talk a little bit about that. (11) ………….. support for RN mobile. So those platforms are supported today, but there's work we know we can do to make them even faster. ILYA GRIGORIK: So at least in theory in the long term, as a person who's authoring this content, as a designer, for example, it actually it makes my job a lot (12) ………….. . STEPHEN KONIG: Correct. ILYA GRIGORIK: I just save it as-- And obviously, what you see there is that for almost all images, the WebP is significantly (13) ………….. than PNG. There are a handful of cases, (14) ………….. than 2%, where it's slightly (15) ………….. than one. ILYA GRIGORIK: So that's this peak right here? STEPHEN KONIG: That's that little peak right there. But overall, across, in this case, 1,000 images, 98% of them were (16) ………….. , and in most cases by a significant degree, than PNG. ILYA GRIGORIK: So it seems like, especially for lossy with alpha, if I look at, half of the distribution here, it's significantly (17) ………….. , like 80%, 90%. STEPHEN KONIG: You're looking at between 70% and 80% (18) ………….. . ILYA GRIGORIK: Which is actually representative of kind of the (19) ………….. number that we saw, which is for certain images, with alpha channel and PNGs, we can get on average, 70% to 80% improvement in byte size. So the red is JPEG. But what you see there is that again, consistently, WebP is (20) ………….. for each quality level. But what you notice on the right hand tail of that graph, JPEG spikes up once you get above quality about 75, whereas WebP has a much more static increase in file size. So what that really tells you is that as you get (21) ………….. quality images-- which hearkens back to what we were discussing ILYA GRIGORIK: So if nothing else, going from a JPEG or WebP from quality 100 to 90 is going to give you more benefit than going (22) ………….. . You should consider going (23) ………….. , but you're not going to get as much. STEPHEN KONIG: Yeah, you get diminishing returns as you go (24) …………..quickly. ILYA GRIGORIK: So I think that's a point worth pointing out. So coming back to these tails, right before the show we were talking about-- so one of the cases where this could happen, because if you're curious, why would WebP ever be (25) ………….. -- is actually for very small images where the actual container of WebP file is (26) ………….. than the image itself. We're talking about one by one pixels and silly things like that. ILYA GRIGORIK: So another topic that comes up frequently is, great, WebP is (27) ………….. , but I hear that it takes a lot more time to compress and decompress. STEPHEN KONIG: Yep, it does. STEPHEN KONIG: That's a good question. So you're absolutely right. The reason we get (28) ………….. file sizes from WebP is because we spend more time doing the encoding work. And so what we typically see on average is that on the And so far, it looks like it's they're competitive, both WebP and JPEG. But you scroll a little bit (29) ………….., like 200 milliseconds (30) ………….., and you can see that a whole bunch of WebP images have fully loaded, more getting pulled in, et cetera. That's what this graph here is showing you. Yes, you spent more CPU time, but the actual time to glass, if you will, pixels visible on the screen for WebP is (31) ………….. because we're transferring fewer bytes. STEPHEN KONIG: Exactly. And that's where WebP clearly, in this example, shines. Even though we're spending a little more time on one part of the process, we're spending far (32) ………….. in another and the net effect is definitely positive. ILYA GRIGORIK: So hopefully by shipping fewer bytes and adding support for WebP. I think they're receptive to it. They're sort of waiting for indications of (33) ………….. adoption on the community, which we're making great progress on. And following that, I'm hoping that we'll actually invest into more of the infrastructure, the tooling, and everything to make authoring WebP (34) ………….., employing it (35) ………….. . STEPHEN KONIG: Exactly. ILYA GRIGORIK: So we have, I guess, a couple of points to We'll talk about tooling in a second. But Android and iOS, ready to go. In fact, it's actually probably (36) ………….. to deploy WebP today on native platforms, on Android and iOS, than it is on the web to some degree, although it's still definitely be in IE 11. And so for some long period of time, you're going to have all these (37) ………….. IE versions that don't. And so even when we get to native support across all these different browsers, as a web developer, you still have to be conscious of the fact there are going to be users on (38) ………….. browsers that can't support WebP, and so you do need a fallback option. ILYA GRIGORIK: And maybe the last point to make here is everything's going to work well, but we're working very well with that team, and I think you'll see that rolling out (39) ………….. this year. ILYA GRIGORIK: So it sounds like in a year's time, if we were to have a 2014 episode of this, looking back, I think STEPHEN KONIG: Definitely. Well, it's one of the things you want to look at because obviously, with (40) ………….. quality, you get (41) ………….. file sizes. So as you're trying to improve speed, that's a knob you can tweak that will definitely have an impact. But you're right. As you (42) ………….. the quality, you're going to get more compression artifacts. And the kinds of artifacts you see between JPEG and WebP are different, especially as you get into (43) ………….. quality levels. So you do need to do visual comparison at that level to understand, am I comfortable with the kinds of artifacts about Android and iOS. We're not going to go into too much detail. As I said, I'm going to share the slides (44) ………….. . So this is more as a reference. I just wanted to show that it's actually very simple if One thing that's worth mentioning is we ship native support in 4.0 plus, but there's a great project on GitHub where somebody did a back port, so for the (45) ………….. versions of Android. So you can pull that in if you need to. And there's a lot (46) ………….. Android devices out there, unfortunately, so that's a handy thing to have. And then for iOS, same thing. So that's the native side. I'm going to claim that that one is actually (47) ………….. . STEPHEN KONIG: It is today. You're right. But we find, at least in all of our case studies at Google, that this is definitely a worthwhile investment because it gives such a (48) ………….. experience to the user. STEPHEN KONIG: Correct. And I think the thing I'd point out on that is it's a question of who should be paying the cost and where is that best paid for? And I would argue that it's (49) ………….. paid for on the part of the web developer and the site author. It's (50) ………….. for them to pay for a little bit more storage and some more memory for the cache than it is to ask every single user who hits your page to spend more time they're on mobile. ILYA GRIGORIK: Exactly. And of course, as the adoption grows, this also becomes (51) ………….. of a problem. So for example, for client side detection, Modernizer And then alongside that, we're going to continue to focus on optimization and trying to bring that encode and decode time down even (52) ………….. . But you know, we're at a point today, we're ready to really push the gas pedal and make some great progress with WebP. So we have to sort of work this in a stepwise manner. And so getting WebP adopted across the web will make it a lot (53) ………….. for us to go to consumer electronic device manufacturers-- camera makers, phones, et cetera-- ILYA GRIGORIK: So yeah, if the camera saved it directly as WebP, that would be great. STEPHEN KONIG: Even (54) ………….. . ILYA GRIGORIK: But it'll probably take some time before we get there. Thou shalt use a GIF, a PNG, and a JPEG, and there's no reason for it. We could optimize things much (55) ………….. . STEPHEN KONIG: Exactly. And we see this sometimes when we go out and talk to folks We don't view it as an exclusion to other options. ILYA GRIGORIK: So is there any way to use WebP in Android (56) ………….. than 4x? Yes. So there's that backport, and I'll share the slides (57) ………….. so you can find the link to it. Wouldn't just using a PNG file be faster than converting WebP Potentially. I think again, you have to measure that in terms of what is the bandwidth savings from the (58) ………….. file size. Obviously, plug-ins aren't perfect either because they introduce a little bit of user friction into the experience, everybody's considering just because the mobile web is shooting through the roof. Pages are getting (59) ………….. . You saw the number of bytes on the wire. So they're all looking at this in some way or another. And that's not to say that user agent is the only way to do it. I think there are (60) ………….. ways. In fact, we've been talking with the Chrome team about fixing some of the accept headers and making this (61) ………….. such that you don't have to write these crazy user agent detection functions. alternative formats, but if you find JPEG Mini is a good choice, then that's fine. We think WebP offers a much (62) ………….. alternative for the vast majority of use cases that are out there today. ILYA GRIGORIK: At the end the day, make the web fast. download those plug-ins. And I hope, as we said, we're going to make the tooling (63) ………….. in 2013. All right, I think that's it.

Key: Look at the key and say aloud the script from the video to improve your English.

And when I look at the overall size of the page, first of all, an average page is about 700 kilobytes. So it's actually a little bit (1) (less) than a desktop version, which is good news. But then, this number actually shocked me. types, images are basically 70% of the data on the wire. STEPHEN KONIG: That's pretty typical. It's actually a little bit (2) (higher) on mobile than what we see on desktop, but the fact that it's the single largest component of the page size is very consistent with what we don't look so good. And so it's putting a lot of pressure on publishers to update their sites and their images to look (3) (better) on these hiDPI devices. ILYA GRIGORIK: And that's a really hard one, right? Because to your point (4) (earlier) , my bandwidth is not going to up magically by four, or latency decrease by four, but all of a sudden, the images are getting four times (5) (bigger) . STEPHEN KONIG: Exactly. ILYA GRIGORIK: And I think, actually, the four is worth So if you're using a lossy format like JPEG, in addition to that, what you're probably going to see is a demand for (6) (higher) quality images with your compression artifacts. So that in itself will also play a part in increasing the size. ILYA GRIGORIK: Right. So there's probably no magic bullet to say we can have both hiDPI and a (7) (lower) file size, but perhaps there's a middle road somewhere in between. STEPHEN KONIG: Exactly. format is actually a challenge. STEPHEN KONIG: It is. ILYA GRIGORIK: So as I mentioned (8) (earlier) , when I talked to a lot of web developers and designers, they say, great, I took my image, I optimized it. formats in the background. And then we figure out that, hey, this image file is actually much (9) (better) compressed if we use JPEG, for example. So we don't assume anything about your decisions. animation and metadata. So that will replace the GIF use case. (10) (Longer) term, we're looking at ways of improving performance on the encode and decode side, so we're always looking at optimizations we can do there. to talk about that. STEPHEN KONIG: We're going to talk a little bit about that. (11) (Better) support for RN mobile. So those platforms are supported today, but there's work we know we can do to make them even faster. ILYA GRIGORIK: So at least in theory in the long term, as a person who's authoring this content, as a designer, for example, it actually it makes my job a lot (12) (simpler) . STEPHEN KONIG: Correct. ILYA GRIGORIK: I just save it as-- And obviously, what you see there is that for almost all images, the WebP is significantly (13) (smaller) than PNG. There are a handful of cases, (14) (less) than 2%, where it's slightly (15) (higher) than one. ILYA GRIGORIK: So that's this peak right here? STEPHEN KONIG: That's that little peak right there. But overall, across, in this case, 1,000 images, 98% of them were (16) (smaller) , and in most cases by a significant degree, than PNG. ILYA GRIGORIK: So it seems like, especially for lossy with alpha, if I look at, half of the distribution here, it's significantly (17) (less) , like 80%, 90%. STEPHEN KONIG: You're looking at between 70% and 80% (18) (smaller) . ILYA GRIGORIK: Which is actually representative of kind of the (19) (larger) number that we saw, which is for certain images, with alpha channel and PNGs, we can get on average, 70% to 80% improvement in byte size. So the red is JPEG. But what you see there is that again, consistently, WebP is (20) (smaller) for each quality level. But what you notice on the right hand tail of that graph, JPEG spikes up once you get above quality about 75, whereas WebP has a much more static increase in file size. So what that really tells you is that as you get (21) (higher) quality images-- which hearkens back to what we were discussing ILYA GRIGORIK: So if nothing else, going from a JPEG or WebP from quality 100 to 90 is going to give you more benefit than going (22) (lower) . You should consider going (23) (lower) , but you're not going to get as much. STEPHEN KONIG: Yeah, you get diminishing returns as you go (24) (lower) quickly. ILYA GRIGORIK: So I think that's a point worth pointing out. So coming back to these tails, right before the show we were talking about-- so one of the cases where this could happen, because if you're curious, why would WebP ever be (25) (bigger) -- is actually for very small images where the actual container of WebP file is (26) (larger) than the image itself. We're talking about one by one pixels and silly things like that. ILYA GRIGORIK: So another topic that comes up frequently is, great, WebP is (27) (smaller) , but I hear that it takes a lot more time to compress and decompress. STEPHEN KONIG: Yep, it does. STEPHEN KONIG: That's a good question. So you're absolutely right. The reason we get (28) (smaller) file sizes from WebP is because we spend more time doing the encoding work. And so what we typically see on average is that on the And so far, it looks like it's they're competitive, both WebP and JPEG. But you scroll a little bit (29) (further) , like 200 milliseconds (30) (later) , and you can see that a whole bunch of WebP images have fully loaded, more getting pulled in, et cetera. That's what this graph here is showing you. Yes, you spent more CPU time, but the actual time to glass, if you will, pixels visible on the screen for WebP is (31) (better) because we're transferring fewer bytes. STEPHEN KONIG: Exactly. And that's where WebP clearly, in this example, shines. Even though we're spending a little more time on one part of the process, we're spending far (32) (less) in another and the net effect is definitely positive. ILYA GRIGORIK: So hopefully by shipping fewer bytes and adding support for WebP. I think they're receptive to it. They're sort of waiting for indications of (33) (further) adoption on the community, which we're making great progress on. And following that, I'm hoping that we'll actually invest into more of the infrastructure, the tooling, and everything to make authoring WebP (34) (easier) , employing it (35) (easier) . STEPHEN KONIG: Exactly. ILYA GRIGORIK: So we have, I guess, a couple of points to We'll talk about tooling in a second. But Android and iOS, ready to go. In fact, it's actually probably (36) (easier) to deploy WebP today on native platforms, on Android and iOS, than it is on the web to some degree, although it's still definitely be in IE 11. And so for some long period of time, you're going to have all these (37) (older) IE versions that don't. And so even when we get to native support across all these different browsers, as a web developer, you still have to be conscious of the fact there are going to be users on (38) (older) browsers that can't support WebP, and so you do need a fallback option. ILYA GRIGORIK: And maybe the last point to make here is everything's going to work well, but we're working very well with that team, and I think you'll see that rolling out (39) (later) this year. ILYA GRIGORIK: So it sounds like in a year's time, if we were to have a 2014 episode of this, looking back, I think STEPHEN KONIG: Definitely. Well, it's one of the things you want to look at because obviously, with (40) (lower) quality, you get (41) (smaller) file sizes. So as you're trying to improve speed, that's a knob you can tweak that will definitely have an impact. But you're right. As you (42) (lower) the quality, you're going to get more compression artifacts. And the kinds of artifacts you see between JPEG and WebP are different, especially as you get into (43) (lower) quality levels. So you do need to do visual comparison at that level to understand, am I comfortable with the kinds of artifacts about Android and iOS. We're not going to go into too much detail. As I said, I'm going to share the slides (44) (later) . So this is more as a reference. I just wanted to show that it's actually very simple if One thing that's worth mentioning is we ship native support in 4.0 plus, but there's a great project on GitHub where somebody did a back port, so for the (45) (older) versions of Android. So you can pull that in if you need to. And there's a lot (46) (older) Android devices out there, unfortunately, so that's a handy thing to have. And then for iOS, same thing. So that's the native side. I'm going to claim that that one is actually (47) (easier) . STEPHEN KONIG: It is today. You're right. But we find, at least in all of our case studies at Google, that this is definitely a worthwhile investment because it gives such a (48) (better) experience to the user. STEPHEN KONIG: Correct. And I think the thing I'd point out on that is it's a question of who should be paying the cost and where is that best paid for? And I would argue that it's (49) (better) paid for on the part of the web developer and the site author. It's (50) (better) for them to pay for a little bit more storage and some more memory for the cache than it is to ask every single user who hits your page to spend more time they're on mobile. ILYA GRIGORIK: Exactly. And of course, as the adoption grows, this also becomes (51) (less) of a problem. So for example, for client side detection, Modernizer And then alongside that, we're going to continue to focus on optimization and trying to bring that encode and decode time down even (52) (further) . But you know, we're at a point today, we're ready to really push the gas pedal and make some great progress with WebP. So we have to sort of work this in a stepwise manner. And so getting WebP adopted across the web will make it a lot (53) (easier) for us to go to consumer electronic device manufacturers-- camera makers, phones, et cetera-- ILYA GRIGORIK: So yeah, if the camera saved it directly as WebP, that would be great. STEPHEN KONIG: Even (54) (better) . ILYA GRIGORIK: But it'll probably take some time before we get there. Thou shalt use a GIF, a PNG, and a JPEG, and there's no reason for it. We could optimize things much (55) (better) . STEPHEN KONIG: Exactly. And we see this sometimes when we go out and talk to folks We don't view it as an exclusion to other options. ILYA GRIGORIK: So is there any way to use WebP in Android (56) (less) than 4x? Yes. So there's that backport, and I'll share the slides (57) (later) so you can find the link to it. Wouldn't just using a PNG file be faster than converting WebP Potentially. I think again, you have to measure that in terms of what is the bandwidth savings from the (58) (smaller) file size. Obviously, plug-ins aren't perfect either because they introduce a little bit of user friction into the experience, everybody's considering just because the mobile web is shooting through the roof. Pages are getting (59) (bigger) . You saw the number of bytes on the wire. So they're all looking at this in some way or another. And that's not to say that user agent is the only way to do it. I think there are (60) (better) ways. In fact, we've been talking with the Chrome team about fixing some of the accept headers and making this (61) (easier) such that you don't have to write these crazy user agent detection functions. alternative formats, but if you find JPEG Mini is a good choice, then that's fine. We think WebP offers a much (62) (better) alternative for the vast majority of use cases that are out there today. ILYA GRIGORIK: At the end the day, make the web fast. download those plug-ins. And I hope, as we said, we're going to make the tooling (63) (better) in 2013. All right, I think that's it. Awesome.

Sources: 

Channel: Google Developers. Faster, smaller and more beautiful web with WebP: https://www.youtube.com/watch?v=4tu2SJfSalA&t=1989s

---------------------------------------------

Compiled by Top Grade Edu