Ilya Grigorik | performance.now().reject(reasons) | performance.now() 2019

Ilya Grigorik | performance.now().reject(reasons) | performance.now() 2019


(audience applauding) – [Ilya] All right. – [Tim] Thanks, buddy. – Thanks Tim, I’m glad to be here. And at what points during the year, I’m sure all of you guys
have this experience, we all work for businesses
and at a certain point, you know, the next year rolls up, and the planning emails start
landing in your mailbox. And you’re like, you gotta
think about the next year. And this year it really took me aback, because for me, 2020 has
this magical property. Maybe it’s all the sci-fi novels that I’ve read growing up or
the movies that I watched, but 2020 is really the event
horizon for many things. 2020 is where we have flying cars, and when we have flying
cars, web performance is no longer a problem because we figured out flying cars. And really here at this event, we’re here to celebrate the end of our journey of web performance because we’ve solved it all.
(audience laughs) And, you know, as I was
preparing this talk, I was looking at this picture and it dawned on me that flying cars are probably a terrible idea. I mean, what could go wrong? You have four high-performance
blenders attached in front of a projectile.
(audience laughing) Anyway, so I’m still
holding out a ray of hope that tomorrow all the
speakers will tell us all the secrets for how
we solve web performance. But really, I end up oscillating
between these two states. On the one hand, I am often appalled at the user experience on the web, but then in the same breath, when I take a step back and look at some of the things that we’ve been able to
achieve over the last decade, and to some extent, I’ve
worked on web performance for the last decade
more or less full-time, it is actually quite astounding, of all the things that
we’ve been able to deliver, just an incomplete list, mobile-friendly. Like 10 years ago, we
didn’t even think about, like we had a desktop web, and all of a sudden we
have a mobile-friendly web. And that’s an amazing transformation. We have HTTPS effectively
on by default everywhere. Over 90% of navigations are now secure. That used to be less than five or 10%, you know, 10 years ago. We have things like HTTP/2 and HTTP/3. Like we literally swapped out the delivery protocols on the entire web. And to some extent, or to most extent, no one even noticed. And that’s a good thing. I mean some things got faster. Then we have things like Wasm. Like, now we have this
low-level bytecode format delivering amazing things, as you guys heard this morning. So this is all amazing, this is all great, but then you get moments like this. I opened my dev tools and I do the audit and I’m like, “Dude, what is going on? “We have WebP, we have the case, “I told you what to do to optimize images. “And in fact, if you read Steve’s book, “it told you to optimize
images 10 years ago.” And I had a good laugh
because I put this text with the marketing before
I came to the event but we had, you know, some
shout-outs to the marketing team at the event a few times now already. So, like, what is going on? Because clearly, we’ve made
huge progress in some areas but we have not been able to move things at scale in some other areas. So why is that? Why is it that we’re rejecting some of these performance best practices? And just to put a finer point on this, here’s a headline from earlier this week. So Google launches a new Stadia service that you can try out now and it delivers 4K resolution, 60 frames per second
gaming in your browser. Low latency gaming in your browser, right? This is effectively taking your console and running it in the cloud. And it is running in your browser. So we’re able to deliver this high-resolution imagery at 60 hertz. At the same time, why
is it that we can’t ship a single damn frame in under one second (audience laughs) on most of the web? And while we’re at it, let’s actually apply
gzip to all the resources ’cause that’s still a
huge unsolved problem. And yes, let’s optimize
images as well, right? There’s some discrepancy
in these two things that we need to figure out. So let’s dive in into
the images in particular. This is an area that
I’ve been thinking about and I want to welcome you
guys on this journey with me. So what are the potential
problems and pitfalls that prevent us from fixing this problem? It could be that there’s
just lack of knowledge, or maybe lack of tools
or lack of automation. And I think the answer is we have all these things, right? We have books written
on image optimizations, we have tons of articles, we have talks, even at
this event last year we had an amazing talk
on image optimization. So it’s not like the
knowledge is not there. If you want to seek it, you will find it, and find lots of it. We even have lots of tools. People have invested
years and decades of time into building better libraries and things that will make your life easy to solve this problem, if you want to. We have dedicated CDNs that will gladly take that
problem off your hands. And yet, for some reason,
we’re still, for the most part have not have not solved this problem. So there’s something else missing. And here’s an example of this problem. So Web Almanac is a new
community-driven resource that has been put together
and announced last week. And there’s a media chapter
in it that looks at, if we crawl the web, so this
is using an HTTP archive data, and run the Lighthouse audits on it, one of the things that Lighthouse does is it actually it takes the image, tries to optimize it and sees how much could you save if
you actually optimized it. And basically what this graph shows you is that at p75, so that 75th percentile, if the sites actually optimize the images, it would save an estimated 1 1/2 seconds for that for that site,
in terms of load time. And at p90 you would be over five seconds. So clearly there’s some
room for improvement here and we’re not really making
a dent in this problem. So then the question is really, it’s not about the tools, it’s not like we don’t know
how to optimize images, it’s the lack of incentives. Why is it that sites are not adopting this best practice by default? Is it lack of awareness? Maybe. Maybe it’s lack of case studies, right? Perhaps. Is it user empathy,
because we’re just ignoring the user and we actually don’t care? Is it the privilege of developing on a desktop computer
and having a fast network that we lack that pain of
having to wait so long? Or maybe it’s just too hard. There’s so many reasons for
this particular problem. But I think the key observation here is, it’s a question about behavior. It’s not a question of technology. So we are asking a question, whose behavior do we need
to change and in what way? And I think it’s really important for us to consider who
are we trying to change and actually break this problem apart for different segments of the web. And this is a big leap. So these two questions, I think, are often used interchangeably. In fact, we often have conversations where we mentally swap
these two formulations of the problem. But they’re actually
completely different problems, because if you focus on one, how do we improve image
optimization on the web? We can geek out for hours, we can have an entire conference
on image optimization, what is the best encoder, what is the best level of
settings for each encoder, what is the best format? Is it progressive or should
it be something else? Should you do some other optimization? And that’s all great. There is definitely room for improvement in the existing tools. But the problem’s actually not improving the existing optimizations, it’s actually getting the
optimizations employed at all. And that’s the second question, which is that question of behavior. Why is it that we can’t get people to pay attention to the
stuff to begin with? And on a second, or third
actually, formulation here that I want us to consider is use optimization across the entire web. So not just in your particular context, but what can we as a
community do to drive adoption of these best practices
across the entire web? That, of course, begs the question, is what is the entire web and how do you actually break that apart? One useful way to look at this, this is some interesting data that was shared at BlinkOn last week. Rick Byers works on Chrome and he shared this really interesting analysis which effectively breaks down to, if you look at the origins
that our users visit in Chrome, about 30% of the page loads are coming from the top 100 sites. So that’s the head, there’s a few sites, small number of sites, that
drive a lot of traffic, which intuitively makes sense. About another third comes
from the next 10k sites, so that’s the torso of the web. But the remaining 30% comes
from a very long tail, millions of sites. Don’t over-index on the
actually number of millions, whether there’s three million
or five million or 10 million, the point here is that we
have this wide distribution. And each one of these
segments intuitively, I think, it makes sense that they have
different business models, they have different engagements. You can bet that if you’re in the top 100 you probably have a
dedicated engineering team, maybe even a performance team, hopefully a performance team or somebody thinking about performance. The economics of the
torso are very different, and the tail is actually
dramatically different. And driving the adoption of best practices at scale requires that we actually have a distinct strategy
for all three segments. So really it boils down to this, if we try to decompose this problem, how do we drive adoption
of image optimization in the top 100 sites, which is a different question
from the top 10k sites, and finally the three million sites? And I wanna focus on the tail, because I think it neatly demonstrates how different we need
to think about the web and how do we optimize,
beyond images as well. So this room is not the tail. You don’t just randomly
walk by an event and decide to walk in and learn
about image optimization because you happen to have a website. You guys self-opted in
into this community, which tells me that you are likely in the top or the torso of the web. You care about the web. Most creators, most people
creating sites and pages on the web are not performance
experts, they will never be. They shouldn’t be. They just have a simple
job to get done, right? They wanna get a small site online that describes their business or maybe they want to document something. And none of the discussions that we have here will ever reach them. So we need to think differently about how to enable that
particular audience. Of course, one observation here is, well, much of the tail actually relies on some common infrastructure, right? Like those same users don’t
just buy a dedicated server and set up PHP and then
install their own WordPress. Some do, sure. You’re probably a developer. Most turn to turnkey solutions, they’ll go to GoDaddy or
some other hosting provider that makes it simple to get
a site up and running online. So one point of leverage we have on the tail is these hosting providers. So let’s write a nice letter and sign it and send it to the
hosting providers saying, “Look, it’s really good for the web “if you were to optimize images. “That would be just grand “if you could just enable
images optimization.” And in some shape, way, or
form I’ve had this discussion at least a dozen times with
different hosting providers in slightly different context, but even this particular discussion. Turns out, it doesn’t
actually work that way. It resonates with some
of the performance people at that hosting provider,
but you have to remember, you have to think and acknowledge how the business actually operates. And the business of the
long tail is actually very, it’s a thin margin business. It effectively boils down
to how many users can I put on a single server because
I wanna lower my OpEx. It’s the fewest numbers of CPU cycles with fewest number of spindles and the least memory footprints that I can allocate to that user. So whenever I come and ask them, “Hey, could you please
spend some CPU cycles “to create more variance of the image because it’d be responsive. “That’s like awesome. “And yes, it’s gonna take a bunch of RAM “to optimize the images.” What they’re translating
to in their head is, “Okay, this is gonna be a
disaster on my bottom line. “So I feel good about
making the web faster, but it doesn’t actually
align with my business.” And for that reason, that message actually just doesn’t stick. So then we come to the next thing, which is the next
obvious rebuttal to this, we have free CDNs, we have free services, why doesn’t the web just adopt it? Well, that’s a different problem. That’s an awareness problem, right? Most people that are
trying to get on the web, just get a website online, are not technical. They don’t understand what
a CDN is, nor should they, to be honest. And they just wanna get an
image up on their damn webpage. And most of them struggle to
get an image on the webpage. That’s a whole different problem, but they’re not thinking about CDNs. So we’re constantly losing at this game, because new people are
creating content on the web and they are just opting
in to this bad behavior, which is not using CDNs, not using any image optimization services. And their hosting providers
frankly are not set up to handle that cost. So here’s an interesting
question to ponder, how many of you are image
optimization experts for Facebook or Instagram? How many do you know? There are many content creators that go to these services
and publish regularly, but there’s no web performance industry around Instagram and Facebook. Like, this problem is not a
problem on those platforms. Why is that? Well, their economics are different. They have a giant advertising flywheel which is able to underwrite
image optimization, optimize delivery, and
deployment of new formats. They take that entire problem and solve it because they have another different way to fund the entire user experience. And they compete on user experience. They know that by delivering
better image optimization, they have faster load
times, better retention, better engagement, which
translates into more visits, and then just continues
to turn that flywheel of advertising in their favor. That’s not how the tail of the web works. So we need a different solution. The open web tail lives and
dies by the OpEx margin. So we need, we can’t compete with that, we can’t change those economics. The torso, interestingly enough, thrives on integration and upsells. So you can turn to hosting providers which will gladly offer
you additional services for additional fees, and they will deliver on
the optimized experience, whether you’re trying
to host a WordPress site or your own site or your
own stack or something else. So these things exist and that’s great. But money matters, right? And I think we often ignore that problem. We think of it as a technical
problem and lack of tools but the finance and the business part of the ecosystem is a huge factor. So my claim is that if we actually want to solve this problem, if we want to get to 2029
and stand on stage and say, “What have we accomplished
in the last decade?” I’d love to be in a
place where we could say, “You remember back in the
day when we had to hand roll WebP optimizers and that like that? “Yeah, those were the days. “Nowadays we don’t have
image optimization problems.” What would it take to get there? My claim is, it needs to be free. The number of choices for
the user should be zero. You should never have to educate anyone on why image optimization matters. Most people that put images online, whether that’s your marketing department or someone just setting up a site, should never have to make that choice. So as platform builders
for your own brands, I think that’s something
that you should focus on, which is prevent people from making the bad
choice in the first place. If you’re trying to police
them after the fact, you will never win that game. And finally, the tools must
do the work for you, right? So this gets me to the last point, which is I think we actually need to have a different strategy, it’s knowledge, tools, automation, incentives are prerequisites, those are all necessary components. But we need to have a conversation about different strategies for deploying each one of these things in the torso, in the head and the tail. It’s a different playbook, if you will. And that means understanding
the actually stakeholders. Who are the users that live in that particular segment of the market? What are their needs? What are the business models of the stakeholders that support them, whether that’s a hosting
provider or somebody else? And what are the differences in the tools? Maybe the folks in the head are willing to spend more time tweaking the knobs and shifting quality settings, but the folks in the tail
don’t know, don’t care, and never will touch that functionality. So the question is how do we
actually activate the tail? Like, if we stick with the image example, what would it take for us to change the dynamics of this industry? And one of my hypothesis currently is that we actually need
to put the agent back into the user agent. And what I mean by
agent is put the smarts, make the user agent smart, helpful, and something that has your back, something that helps you along the way. This is an interesting insight
for me in particular because, and I think many people here
will be familiar with this, so the Extensible Web Manifesto came out maybe five or six years
ago, maybe even longer, and the observation here was, as browser vendors, as browser engineers, generally when we try to tackle
a very high-level feature, we fail, because the behaviors
are really complicated, we can’t provide all the
configuration options. So really what we should do
is offer low-level primitives to the web platform that allow you, the developers and
folks building websites, to compose your own variants
and prototype rapidly. And then maybe once we find
the definite cow paths, we just kind of pave
them in that direction. So the gist of the
Extensible Web Manifesto is we should focus on low-level primitives. We should try to explain
existing features. So if you see some high-level
thing, for example, the video tag, a video tag
is a baked-in web component. So web components are
basically trying to explain some of these form elements
and other things that are just shipped
by default in a browser. And I think that’s generally good, I mean, there’s a lot of
really good insights into that. In fact, we should prioritize
all this work above all else. We should not try to prioritize building high-level features,
we should try to explain it. And I drank that Kool-Aid,
and I believed it, and I still believe it, but I think there is some consequences that we missed out along the way. Implicit in this is that
we’re actually leaning on developers to drive adoption. There’s nothing that the
browser can really do to force adoption, it really
is about activating each site on it’s own, which means
that the existing web cannot just get those features for free. And oftentimes we lean on users to make the informed choice. So as someone that’s
composing on your website, I need to make an informed choice on which framework I should use, what are the attributes
that I like about it, and then somehow navigate
through that forest of 1,000 choices to end
up with the right outcome. Does it have the right
image optimization built in? Does it have the right bundling? Does it enforce all of these other things? It’s a very tough matrix
to get yourself through. So no wonder people are struggling. And a very concrete example of this that I was reflecting on currently, is back in 2015, there was a proposal for, on WICG for, “Hey,
let’s add a standard way “to lazy load images. “And in fact, why don’t we put that “into the browser by default. “Like, why shouldn’t the browser “just by default lazy load all images?” On the surface that makes a lot of sense. That would actually help not only, that’ll help the entire web, I think is the actually observation. The web as it is today. And (laughs) I wrote a long essay on why I think that’s a terrible idea. I clipped the relevant parts, but effectively it boils down to, this is a very complicated problem, lazy loading is very complicated. Like, you have different behaviors across different websites,
how much you preload, what conditions trigger preload, this is just a very gnarly thing that we as a browser
probably will get wrong and upset people. So instead we should focus
on low-level primitives, like we should have
Intersection Observer API that tells you how far the element is away from the viewport, or
if it’s in the viewport. We should have resource hints and preload so you can preload stuff. If you want to trigger on
whether the user is trying to save data, we should
add a hint for that, and we should have net info, and it’s, like, lots and
lots of these components. Good news is, we actually
shipped all of these things. They exist. So you can in fact build
very powerful lazy loading capabilities today on the web. The bad part is, how many websites do you go to actually use
lazy loading effectively? Very few. So something went not right there. Like, this is necessary, but
this is not sufficient I think. So this is probably a very
clear statement of denial. (audience laughing) so I was, (laughs) to defend myself, (audience laughing) I don’t think I was
wrong in that we needed to have low-level primitives, I think that is actually correct. What I was wrong about is saying we shouldn’t do the high-level thing, because what I focused on was the segment of the market where developers
were actually smart enough, motivated enough, and aware enough to build a solution that makes sense for their particular use case. And the general observation here is, I think we’ve actually
kind of over-indexed on low-level primitives. I think we need to put the agent back into user agent to provide
services by default that help most web users
to move this thing forward. And we should do that with equal urgency, so in that particular example
on the previous slide, we should have ran both
things in parallel. There is no reason why
we should have stopped at default behavior from
advancing at the same pace as all of the low-level primitives. So here’s my formulation, I think, of what we need to do to
fix the images problem as we move forward. The only way we’re gonna fix it, especially if you wanna
fix it in the tail, is we have to fix the
problem before it happens. We have to optimize the image
before it leaves the device, and get it to the storage system
in somewhat optimized form, not optimal form, but
somewhat optimized form. What I’m thinking about
is, hey, you just uploaded a 20 megapixel image into a thing that needs a
400 x 400 pixel preview, very common on the web. And that’s what we need to fix. Now, when I shopped this idea around, I got horror in the
eyes of many engineers, and I think it’s because I actually went to folks that work on images. So their first reaction is like, “Oh my God, this is such
a complicated space, “you’re gonna tell me that
you’re gonna do magic? Well, what does that mean? “Because I have 15 settings
that I need to tweak “for my particular configuration “to get the optimal
performance out of my images, “and I don’t believe in this
magic that you’re gonna do.” And I think that they have a point, and we need to provide a path for both. And here’s a very good example. If you’re an iOS user,
you may have seen this if you tried the developer previews. So iOS recently shipped the new intent on their platform where if
you go and do the file upload and you pick an image, they
actually bring up a selector box that says, “What image size
do you wanna upload this in?” This is not a site implementation, this is just a native UI implementation, and they offer you four options, actual size, small, medium, and large. I think this is actually amazing. My first impression actually was like, “Well, what does small and medium mean?” it doesn’t actually tell
you what it’s about to do. But of course that’s a
question I ask as an engineer who thinks about image optimization. But on the other hand, I think this may actually
be the most impactful thing that we may have done, and I’m gonna take credit for
the work that iOS did here. This may be the most impactful thing that we as an industry have
done moving forward so far, to fix the problem of unoptimized images. Now, I think this is a huge step forward, but it’s not sufficient either. I think we can actually do better. So myself and a few others
have been thinking about how we wanna approach this problem and we have a proposal out. No code has been written,
but the observation is, we actually have an input type file and we actually allow you to specify what image types you’re willing to accept. So you can say, “I only
accept JPEG images.” Let’s build on that. That’s an actually low-level primitive that exists today and we
could probably extend. And what would that look like? We could provide a native
UI, kind of intent UI, similar to iOS that allows the user to select some sort of options, but we need to give sites control, because what does small mean? I’m not sure. It would be nice if the site was able to express some sort of preferences. So if I’m building a
photo storage service, I could have one set of settings that is different from, I’m just looking for a 400
x 400 pixel profile mugshot for my social network. So hypothetically, what
could that look like? Well, we know that one of
the use cases is translating into different output formats. There’s, in theory, nothing
that stops the browser from accepting a certain file type and then outputting another file type. That is actually a very common operation that is done the moment you
upload an image on the server, because you want to standardize what format you store images in. That can actually be done by the browser. So you can specify, perhaps,
even a preference order, so if some browser does not support WebP it can put it in as a JPEG. Hypothetically maybe, may be interesting. Another one could be, well, we know that there are
requirements around file sizes. We’ve all had that experience
of coming to a website and it says, “Please upload an image here, “but make sure it’s no
more than 800 kilobytes “and 400 x 400 pixels,” at which point you start to
tear out the hair on your head, ’cause, like, what do I do? Install GIMP? (audience laughs) Actually, the next thing that you do is you start Googling for web
service to resize image, and you end up on some shady website. That’s actually what happens. This is a terrible user experience. So let’s try and fix that. Why can’t we actually say
that, ideally actually, I want an image that is
at most 800 kilobytes. Maybe they allow some
very high-level settings for the quality that you’re looking for, so in that trade-off optimization of when the browser is making, should I spend more CPU
cycles versus less CPU cycles, we can allow you some
very high-level behaviors. But by default, we would default to auto and just say let the user agents figure out the best approach. What about output dimensions? We could ask, or we could
allow you to specify what is the actually output
that you’re requesting? If it’s 400 x 400 pixels,
is that what you need? Great, let’s give you that. Of course there’s some
really tricky cases here, which is what if you have
a different aspect ratio? So you’re looking at a 1:1 aspect ratio? Well, the horror of like, what if the browser actually provided some native modal UI that
allows you to crop things? It’s not crazy, other
platforms have done it. This is normal, users have, they know how to use these tools. And we have this magical
machine learning thing that I keep hearing about, right? So maybe the user agent could actually just even position the box
on the most salient element and just allow the user to
say, “Okay,” and proceed. Or maybe you can just
automate it entirely. I’m not sure what the right
design space for this thing, but I think that’s the direction that we need to be thinking about. It turns out that while we were focusing, well, I’ve been approaching this problem from the viewpoint of the tail, the torso and the head
of the web actually wants this problem too, or wants
this problem to be solved too. So for example, there
was a recent case study from Twitter where they
implemented a native downsampling, or they polyfilled a native downsampling in a browser for image uploads when you use their web client, and it had double-digit improvement in the rate of successive
uploads on their service. Meaning if you don’t
upload massive images, more images make it to your servers. That’s kinda nice, right? Users are happier because their images are actually making it there. And if they’re experiencing their problem and they have to go out of their way and build this entire pipeline, chances are most other
people are not doing it. So this will help that,
this will help everyone, but tail in particular. What about video? That’s a really interesting
question to think about, because on one hand, it’s
actually very similar to images, a teensy bit harder, the
economics of transcoding video are even more complicated
and much more costly. But good news, there’s
some actual proposals being worked on. Some folks at Microsoft have been working with a couple of services. And there’s an API being designed for very simple manipulation of video, so things like slicing, concatenating and doing other things. So if you imagine building a client where you need 10 seconds of video because you’re trying to
build a story interface, similar to, let’s say,
Instagram or Snapchat, today there’s no way to easily
clip 10 seconds of video. You have to upload a two minute version of 4k resolution video to the server, which then has to cut those
10 seconds, that’s crazy. So here, we should have an API to actually load the video
and allow you to slice it. I think a really interesting space to explore is, how could that look like in a declarative form? And not just a JavaScript API, but also extending file inputs to say, “You know what, what I really
want is to upload a video, “but it needs to be, at most, 10 seconds.” So if you ever used Instagram
and try to create the story, they have a really nice UI flow where you pick a video and
it immediately drops you into an editor which already
clips the 10 second timeline. And you can just move the timeline. Why can’t the web offer that? That’s a very simple operation. Coming back to native image lazy loading, this is something that I’ve
rallied against before, and in retrospect, I think I was wrong. So I think it should be a thing. I’d like to try to make it a thing. Hopefully some of you agree as well. It is a thing, actually, in Chrome for Chrome Data Saver users. So if you enable save data
option in your settings, Chrome will implement this for you and then try to lazy load images. But what about just
making it on by default? There’s definitely some
tricky edge cases there, because it will affect
some of the telemetry, some of the implementations. So this wouldn’t be an
easy thing to pull off, but I think we should try. So with that, I wanna put this
question out to this group, and I’d love to engage with you guys throughout the rest of this conference, what does it mean for us to put the agent back into user agent? We talked about images, but what are the other problems that we’re not thinking about that perhaps you’re fighting with that the user agent could solve better, both as a low-level primitive but also as a high-level primitive, that it can be applied
across the industry? So with that, thank you. (audience applauding) – That’s, I really like the
head, tail, torso breakdown. It’s really interesting, ’cause I think it’s very
tempting for us, and I think, scratch that, it’s not tempting, I think you’re absolutely right. Like, when we are in a room like this where we’re surrounded
by people like ourselves, we tend to have this sort of perspective that we’re all talking to
other developers like us. And it tends to be, Henri
mentioned a little bit, like the comment this morning
he made was that he talked, somebody after the
conference was talking about how they felt like a lot
of performance talks, they felt like they were being
judged or talked down to. And I think that’s, a lot of that is that communication barrier. Like, that perspective of head versus tail
versus torso is helpful. So for this, this conversation, and one of the things
that struck me I guess, is do you, we need to kinda be okay with good enough solutions to some extent for some of this, right? – Yep. – Have you started talking to
developers already about this? Are you finding that we
are having a hard time accepting some of the
proposals because of that? – Yep, so as I said, some of the, I found it interesting that
some of the early reactions for the proposal, so you post a proposal in a developer setting, and the first people that
see it are the developers that have been thinking
about this problem. ‘Cause it’s like, “Oh, wow, there’s a new
image related thing, “I’ve been thinking about
images for 10 years. “Let me look at it, what? “You’re gonna auto-optimize everything? “Crazy talk!” That was the first feedback, and it’s been interesting to react to it and just kind of absorb it and understand, so why is it we have that kind
of knee-jerk reaction to it? And it took me I guess a decade almost to come to this conclusion. ‘Cause I went through all these stages. It’s like, to optimize images,
it’s lack of knowledge. I’m gonna go write a 10
page web fundamentals guide on image optimization, which by the way, many people at Google
make fun of me about. It’s like, “Really, you’re gonna talk “about byte compression?” Anyway, so, wrote that
and did lots of talks. And I can repeat these talks at every conference and
there are good case studies, it helps, but it’s kind of like, you try to stop the bleeding but you never solve the
actual root problem. So you can’t win at that game. So then you move
upstream, and you’re like, “Okay, really it’s about tools. “What we need is better automation. “Let’s go figure out how to
get servers to adopt this, “and CDNs to adopt it.” You have some success there. But then you cross that
rubicon and you’re like, “So why haven’t we still
solved the problems?” You keep looking at the HTTP archive data and the damn needle doesn’t move. And you’re like, “Ugh!” And then you start getting into, “Okay, well let me talk
to hosting providers.” And then you start to
appreciate the differences in business models. So it took me a long time
to go through this journey and appreciate it, and I think I’m just, maybe I’m not the only one
that actually understands this problem, but I think
it’s socializing that and understanding it and appreciating it. It’s like looking at it from the lens of, okay, this feature is being designed for this group of people. It’ll likely be adopted
by this group of people, and maybe that is the shelf life of it. But what about, how do you
solve that same problem in this segment of the market, that will never need to
learn about performance? – So the other thing that
struck me, particularly on, like when you give the iOS example, like the image upload stuff,
iOS has the benefit of, in that particular scenario, owning the entire system, the platform. They don’t have to care about, is Android going to implement some sort of an image process thing. Make sure that we’re matching up our signals and stuff like that. That doesn’t work on the web, right? Like, the web we want, we expect now some sort of consistency at least with any sort
of standardized thing, we expect some consistency
in behavior across browsers. Now, there’s always a little
bit of different, maybe, in some of the UI elements to some extent. But I’m wondering about
is something like this, this image thing. Like there’s a high-level of user testing that has to happen for us to make sure that what is projected by
the browser is something that the tail is going to
be comfortable with and use. Do you have any plans, like
how is that going to look balancing, being able to test what the actually outcome looks like, versus the fact that Safari
and Firefox and Chrome might all disagree and
they’re all gonna implement at different times. – Yeah, that’s a good question. First of all, the iOS example that we showed is a native intent. So it’s the same intent that you would get outside of the web browser as well. So they have that benefit of, they enforce that effectively
across the entire platform, which I think is actually a
neat solution across the board, ’cause they’re actually acknowledging that this is not just
a problem on the web, it’s also a problem in apps, in many apps. The good news is, that is a problem that browsers like Chrome are solving. We run on all platforms. So we can’t rely on native infrastructure. Like Safari relies on their network stack, Chrome ships their own network stack because we need to work across
all these different things. So there are browsers that are able to deploy that across all platforms. To your point of differences in the UIs, that’s a really good question. Good news is that we have smart UX teams that know how to optimize these things and do the appropriate user testing and derive the right solutions. I think it’s actually a good opportunity for different browsers
to try and experiment with different things,
like what makes most sense. One could imagine that there’s
a browser that, crazy talk, provide some set of filters and more than just basic
photo manipulation, or like, resizing, right? – Sure. – I actually would love to see that. Like, what would a browser for
content creators look like? An integrated media library with some basic editing capabilities. We need to empower more
people to publish on the web. So I think that’s an amazing space for us to explore and
innovate and alongside that, we’ll get more primitives baked-in that allow us to do the
optimization in place. – I think that’s, I mean, I’m all for the empowering folks, more people to get on
the web and to be able to be content creators, ’cause I think that’s one of the big challenges
that we have right now. Like, if anybody’s paid attention to the Indie Web kind of
conversation, everybody, I think, fundamentally, is like, “That’s great! We love the fact “that you own your own content “and everybody’s empowered to do it,” and that may be the
right way to do it for, from certain perspectives. However, the complexity
that’s involved is something that we absolutely need
to solve if we want to actually make that work at scale. One of the questions that somebody posed from the audience was when
you were talking about, particularly, incentives
and stuff like that, it was inevitable it was
probably going to pop up, but the Google signaling slow sites, the article that came out recently where they were talking
about the slow loading site is presenting some way to show the user that this is a slow site. Just trying to get your
perspective on that, you can pretend that you
don’t work for Google. We are recording, but we just won’t let any Googlers watch it, I don’t know, we’ll ban some IP addresses, but also in which part of
the segment do you think that that helps, if it does help? I mean, is this a torso thing,
did I say that right, torso? – Mm-hmm.
– Okay, it felt like I misspoke for a second. – That’s a good question, I
need to think about the segment. So first of all, if you
haven’t seen the article, this is something, so last week we had the
Chrome Developers Summit, and in there we demoed
some very, very, very early UX explorations around, what would it mean for a browser to provide
some incentives around speed? And a good example here is HTTPS. We’ve been on this march
over the last five years to migrate from by default
having the gray bar to be HTTP, but what we want everyone to get to is the gray bar being HTTPS. They should be assumed by
default that you are secure. And along the way we
had this trajectory of, well in 2017 we’re going
to start marking pages that have a form as red in the bar because it’s not secure. So that’s a really compelling example of where it actually worked. People clearly paid attention
to those incentives. Those were not the only
incentives, but I think browsers, Firefox did the same, Chrome did the same, I think those incentives had a huge impact on moving the industry forward. And by the way, the industry
was kicking and screaming along the way. It’s like they did not want to change. But I think at the end of the
day, we made the right call, we made the right trade-offs, and we’re in a better place now. So what we’re doing here is applying that frame and saying,
“Could we do the same thing “to web performance? “What would it mean for our browser “to highlight good performing sites?” and we’re very, very
early on that exploration. So please don’t over-index
on those particular mocks that we have there, but the basic idea is somewhere in the UI, if you’re
visiting a site that is fast, we want to in a way reward it, like highlight this is a good experience. Or maybe if it’s taking a very long time, it can give people some context on like, yeah, the sites usually takes slow, ha. – (laughs) Yeah little subtle shade there. You know, the one thing that
sends out as a little bit of a difference between
the security signals and the performance signals there is that with the performance signals, as a user, I’m probably aware that
it’s loading slow right now. Like in the moment, I’d probably get it. Whereas like in security,
one of the things that I thought was so fascinating about the security movement, that whole TLS everywhere thing, was that we had to attack
the sites and the developers alongside informing the
users and educating them and then building up that knowledge through the information there. Do we need to worry
about educating the users about the performance of this stuff or is that not less of an issue? Is this more purely, like on
incentivizing the actually site owners to do something?
– I think that’s an experiment that I’d love to see run. we do know that users learn
behaviors kind of ambiently. So if you interact with a fast site, you interact with it more. Or actually, to put it differently, we’ve run experiments where we’ve intentionally
slowed down the site and then removed that, and we observed that the users who were
exposed to that control group actually interacted less, because over time they’ve
learned that they expect that the sites gonna be slow. So they just do, for example,
fewer Google searches. So what would it mean for us to expose more digital cues about speed? Would it change that behavior? I don’t know. But I think that’s a really interesting, very interesting to explore.
– Yes, it’s interesting. – Like if you have an
actually green indicator when you browse a site
that tells you that, yeah, the site is like, “It’s secure it’s fast it’s
good,” would you use it more? I don’t know. – You could see there’s part of me that, like the performance nut in me is greedily rubbing my hands together
at the idea of the fact that this could make those
studies even more impactful, like the correlation even stronger in a scenario like that, when it’s overtly signaled like that. All right, well, thank
you Ilya, that was great. – Thank you.

Leave a Reply

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