empathy.

Empathy's a term we commonly use to describe the ability to understand and share the feelings

of another individual or a group.

I like to think of the term "performance empathy" to be the same thing, but for the performance

concerns and issues of a particular site.

To explain why I thought it would be a good topic for a talk, I need first to describe

a bit more about myself.

I work as an advocate for the web team at Google.

Now, developer-advocates in many different companies usually act as a bridge between

a specific engineering community and a specific engineering team and a developer community.

Being an advocate for the web team means that it's my job to make sure the web gets better

and better.

I focus on speed and performance.

So a lot of advocates, we sometimes give advice that can seem a little overwhelming.

I don't know why my clicker feels weird!

There you go.

[Scattered laughter].

But in all seriousness why are so many performance advocates fascinated about what they do with

their own tool chains?

Why are we so focused whether it will improve performance or not?

Why do we care performance that much to begin with?

Is it really that much of a problem?

To help us answer this question, let's look at this example of a site.

It's an entirely client-side rendered site that ships a megabyte of JavaScript.

This means that the initial request only contains a shell of an HTML document.

Only after the JavaScript bundle finishes executing, the user gets to see any real content.

Now, in case you weren't counting, the amount of time it took for this app to finish loading

was about 19 seconds.

19 seconds isn't fast by any means.

So we know that one megabyte of JavaScript can seem like a lot to ship town to browsers.

How much are we generally shipping?

If we take a look at the HTTP archive, we can see the median amount of JavaScript we

are sending down the wire is about 350 kilobytes, and this for mobile web pages.

The reason this is such a big deal is because a lot of websites currently living in the

web that are either entirely static or they have little to no interactivity at all.

I thought it would be interesting to dive in a little deeper and see how much how much

site they use of a particular framework are shipping in terms of JavaScript.

And I did it with three frameworks to begin with: Angular, React, and Vue.

The reason I chose these three is because they are the most popular client-side frameworks

today to build our UI.

I found out after querying 250,000 origins, about 50 per cent of them ship over a megabyte

of JavaScript.

Now, each of these origins either use one or more of these frameworks.

There's a lot of reasons why this might be the case, but it does show that we are shipping

a lot of JavaScript if we are not entirely careful.

Now, what I want to do now is take a step back and talk about how I began the presentation.

You see, every single talk I've ever given before today has always followed the exact

same format: I begin with a word of caution, and talk about how performance is a pretty

big problem.

I then move on to showing some stats and some numbers to back up my claim, and I do this

to convey how much of a problem this actually is.

And then the rest of my talk usually follows the same sort of pattern where I talk about

different tips, different techniques, that you should be applying to make sure your site

stays as small as possible and as fast as possible.

For this talk, I'm going to go in a slightly different direction.

I want to talk about what we can do as advocates, and what we can do better to reach the community

better, as well as how we can all work together to try and think of different ways to to make

sure performance is a win for everybody.

Going back to that example of a site we just talked about, here I mentioned that, at the

end, I mentioned that we are running this on a mobile device and a slow 3G connection.

A lot of people when they trace performance, they talk about specific user conditions that

might not be the same as yours when you build your application.

And we do this because the fending on the user's device or network type, they can experience

your site a lot slower than you think.

And there's more.

We sometimes talk about how your users might experience your site if they're completely

offline, or if they have a flaky network connection, or maybe they have a weaker device, on mobile,

so forth, and so on.

Although it is important to talk about all these scenarios and try to capture different

conditions your user might be in, the thing I want to make sure I mention is that you

know your users better than anyone else.

You definitely know your users better than any advocate that stands on stage telling

you how well your site performs under a certain condition.

That being said, one thing I want also to mention is the fact that nobody prioritises

performance over anything.

If you think about it, when you're trying to build a site, the very first thing you're

thinking about usually isn't performance.

Most people are like this.

But if you also think about it, why should someone make it the very top thing they think

about?

Let's talk about something to try and complain what I mean here.

Say you wake up one Monday morning and you have an amazing idea.

You've thought about a product you want to sell on the website or maybe you want to provide

a specific type of service.

So you're excited, and the next thing you naturally do is try to find out how to build

it.

You spend a little time researching the tools, the tips, the tricks that you need, maybe

you're building wire frames, maybe building graphics, so forth and so on, but only after

that, you actually start building.

And at this point, throughout the initial process, nobody really thinks about performance.

The thing that you actually most likely are thinking about is the fact that you want to

build a site that loads and does exactly what you expect it to do, but build it with as

minimal effort and as fast as possible.

A second possible scenario could be the fact that you join a brand new team as a developer.

Say the newest developer on a brand new team, and, when you get assigned your first ticket,

you're most likely going to try and familiarise yourself with the code base.

You will spend a little time trying to know where your components live, where the utilities

live, how the unit tests work, and so on.

Only after that, while you're doing that, you start building and working on your first

feature.

Maybe it's a small feature you're adding on a page, maybe it's a small bug that you're

working on.

But again, also, when you're in these shoes, you're not thinking about performance.

You're not think about what I'm building doesn't degrade the performance of my site.

No, it's the first thing you're doing, most likely trying to check every single box assigned

to you.

It's highly unlikely performance is on that list.

The way I like to think about awareness and performance in general, and how people are

aware of the performance and location of the site, I try to think of it as some sort of

scale.

For example, let's say you're building something for the first time, or you're building something

for the umpteenth time which you're learning a brand new tool.

What you're going to be doing at this point is seeing how this tool works.

Does it do what you expect it to do?

You're going to learn the API, is it easy to plug into your site?

At this point, it's unlikely you're unlikely thinking how badly it's going to affect your

performance.

You're thinking how easy is it for me to use?

Let me spend some more time with that, and after a while, you end up launching your first

website.

You have an idea of how it works in development mode and how it works in production mode.

You have a better feeling whether it is really affecting performance or not, but you still

might be slightly unsure of what you need to do about it.

But the more and more you use this tool, and the more websites that you build, the more

familiar you are with how it affects the speed and reliability of your site.

That being said, nobody is more aware with the fact that they need to work on performance

than those that actually know they have issues.

If a significant per cent of your user base tells you we can't access your site because

it's too slow, you're most likely going to try and prioritise it as soon as possible.

This is what I mean by performance being an afterthought.

Maybe there are ways out there of it being not of something we only think of when it

is too late.

Throughout this talk, I sort of this this dichotomy between two different users groups,

one being performance advocates like myself, and one being a normal developer working on

a regular codebase.

Now, advocates, I think we all agree on the fact that there are way too many slow sites,

and the reason why I think this is true is because we have our job because a lot of the

sites out there aren't as fast as they should be.

If every user accesses the website and felt like it was faster than it needed to be, we

wouldn't need to be doing what we do every day.

But there's another misconception, or another thought that sometimes gets misconstrued that

seems kind of weird, and it's the idea that developers are sloppy when they ship slow

experience.

I've seen the sentiment time to time, and I can't understand it, because a developer

working on a website, and it happens too bad too slow, it is usually one of three reasons.

One, they don't know it is too slow for their users, two, they know it's too slow but they

don't know how to fix it, or they haven't prioritised that yet, and, three, they know

it's too slow and they're actively working to effectively.

Indeed again is always relative.

Having an advocate tell you that you're not focusing on something very important to them

isn't always the best approach.

Now, on the other side of the coin, when we talk about a developer, when you're building

a website, you're most likely going to agree that you have a million things you can work

on.

Performance is just one of them.

But it's also another weird thought that I see sometimes floating around and it's the

idea that advocates, or performance advocates, specifically, are out of touch.

The reason why some people might think this is because of the fact that many performance

advocates will build small sample apps and show you how to optimise and some people will

feel it's not easy to do it with a massive codebase and a massive team where code is

being checked in everywhere.

The reason why I want to squash this thought is because advocates have been in your shoes.

We are developers.

We worked with teams who understand that there are more concerns to a site than there is

just performance.

Instead of having the back-and-forth between small weird opinions and small, small thoughts,

I think it's safe to say we all agree towards one common goal: we all want the web to be

faster for everybody.

So the big question is: how can we make sure we can fix the performance problem better?

What I'm going to do is talk about a few ways we can explore that, because there are changing

sort of how we think about making things better for our developers.

The very first is making sure everybody has better defaults.

What I mean by default is the idea is that let's say you're building something with a

certain tool.

If it always gives you a better starting point, you will most likely always have more wiggle

room, and more room to play with where it will take you longer to reach a threshold

or performance and end up being slow.

And in terms of framework level, a lot of frameworks are looking into this already.

React has already been looking to try to improve React DOM and make the sites smaller.

Doing this a few different ways, one of them being simplifying its event system.

With Vue and Vue3, they are looking to reduce memory function and making things more tree-shakeable

where they can.

The Angular team is looking into building brand new rendering engine called Ivy, and

with it exploring ways to cut down the initial bundle size and also looking at ways of maybe

progressively heightening experiences when you have server render architectures.

React and Suspense is also doing the same thing.

And then there are metaframeworks, things like Next.js that allow you to do what you

want to do most of the time, write and build your component.

There are things that we tell people to do quite often.

You should be code - these frameworks take it out of the hands of the develop.

Developer.

We are already working with XJS to see if we can do things even better and even have

smaller bundle sizes and make sure users get the best experience wherever they can.