- Daniel Lopez

Hi, thank you.

Mic check.

Hello.

All right.

So the official title for this is automated performance budgeting into your pipeline with

Sitespeed.io.

It's kind of a mouthful and also I put W there for some horrible reason, apologies for that.

and I normally don't do public speaking, I'm very happy that we have the HPE track for

those who are beginners, or yeah, and I just really wanted to share this tool, because

I think it's awesome.

I think it really doesn't get enough credit, and it's been around for an extremely long

time, and I just wanted to share it with you.

So that's what I'll be doing with you here today.

So a quick overview, so we're going to talk about my own personal performance journey,

some -- I guess just like performance budgets in general, what they are, what they're for,

and we're going to talk about Sitespeed.io specifically, and performance budgets within

Sitespeed.io specifically.

We're going to talk about, there's a lot of different tools that do performance budgeting,

Sitespeed.io is one of them and there's a lot of other really amazing tools that I found

with in my journey.

So yeah, we'll be talking about other tools and things to consider, and I wanted to throw

out some stuff that I've been experimenting with, and what I see as my future for front-end

performance, what I'd like to see, and what I've experimented with.

So first: A little bit about me.

There's me behind my pizza curtains, that I sewed myself and put up in my office and

some things that I like.

I go by the name of debug xyz on the interweb and that's because I have way too many hobbies

for my own good.

I'm not good at any of them.

So this list here is all things I'm really bad at.

So I'm into growing Pequin peppers, tech minimalism, is hard.

Accessible is hard.

Skateboarding was really hard.

turntablism is insane, I'm horrible, horrible at that one, but I love learning about it.

Front-end engineering is insanely hard.

Right now I'm learning NixOS which is an operating system that is configuration as code.

I've been doing, I don't even want to say how long I've been taking front-end seriously

but I'm relearning CSS and investing a lot of time in that, as well.

So I'm going to quickly go through two of my hobbies, don't worry, I'm not going to

go through my whole list of hobbies.

One of my brothers gave me chilly Pequin seeds.

He suggested I give it a shot.

They have a 15% germination rate.

Normally birds only eat them and they kind of eat away the hull of the seed so you kind

of have to emulate that to make sure that they're happy and keep them O

Thrasher, so this is a '90s thing.

I'm see if I can resize my slide here.

There we go.

Yeah.

Here we have the pose of the year, so at this point I'd been skateboarding for a very long

time.

I had -- it was an absolute obsession of mine.

It takes tons of practice, and is -- it's difficult.

And so when I was skateboarding, I would go all around downtown, I'd grind the -- you

know, destroy the curbs at my local library, and it would get really hot and the (speaks

Spanish) when I would get really hot and exhausted from skateboarding, I would go into my local

library, and cool off, and play with a computer.

And that's where I actually learned to code.

And I would print out -- actually JavaScript, even though I gave up really quickly, and

take it home for studying, and I did that, because it was hard.

So when I knew I was going to be a programmer, I decided I'd go to boot camp.

That was hard.

So this is me at my graduation photo Parris Island and there's my father and mother supporting

me at my graduation.

It was hard.

Frontend is hard.

It was very difficult and achieving web performance can be very difficult.

It's a discipline -- like front-end web performance is a discipline within front-end and maintaining

web performance is even more difficult.

You can really work really hard, you know, getting your site to get that time to first

interactive super-low, but at the pace that we jump from job to job, and from project

to project, you're going to have a lot of people from with varying skill levels, and

everyone within front-end performance has their specialties.

There's amazing front-end developers who are super knowledgeable about accessibility, but

may not know about front-end performance, so it's important to share your skillset with

your peers and make sure that you're having front-end discipline meetings to kind of share

your expertise within the field.

So you have to do all of the things for front-end performance: Capture metrics, observe trends,

provide alerting, fixing actual issues on the website, because that's what, you know,

-- what we're talking about here is that's the kind of context that I come in from is

the web, and front-end development.

So fixing issues on the website, raising awareness with your peers.

You know, you may go through this same struggle if you're working on things like security,

maintainability, maybe you're super into testing, you've got to be sure that you're raising

awareness within your peers, as well as consulting, tools, analysis, for analysis, providing -- supporting

platforms.

One of the first things I did when I started focusing front-end performance within my organization

is I just started capturing PSI data because I thought that was really important for reasons

that I'll talk about later.

And just all of the things you have to do.

And it's -- and it's pretty intense, you know, especially if you're a smaller shop, and you

may have all of this within your organization, but you still need to provide that consulting

to your peers to make sure they're aware of the tooling and of the structure that's there.

Performance is critical on the web.

I'm not going to talk too much about this, but CPU are getting really fast.

We have blazing fast mobile devices, but you know, not everyone has that, and most of the

cell phone adoption right now is happening with like new people buying cell phones who

haven't had cell phones before, are buying low to medium-tier devices, so it's super

important going into the future.

And as the web advances, expectations are getting higher.

People want snappier experiences.

Users gret frustrated, they tend to get less likely to come back and nobody likes a slow

site.

This is us today.

I actually like I think that was funny and stuff, but I like I literally do this.

I literally, you know, do this to my salad, like it's really gross.

[laughter]

So yeah, most of you are probably concerned about profit on your websites.

This is it.

So Step 1, Step 2, performance, profit.

Check it out.

No, seriously, there's amazing resources by Google and there's this book that I read called

time is money, the business value of web performance that if you're trying to sell web performance

to your organization, you gotta read this book.

It's amazing.

It gave me tons of case studies to show to my leadership.

And, you know, you know, you could -- don't do an A/B test for it.

Look to other studies, seriously, because it's very difficult.

I don't recommend it, And you're ignoring a key part of the equation.

There's a lot to it, it's very complex, but, you know, SEO is a big factor to revenue,

so where you're, you know, with Google having tools like Lighthouse and PHP insights being

directly factored into your page rank score, this is one of the key pieces of advice that

you know, Google lets you know is a big impact.

So I forgot some things.

In that big list of all the things and that's regression.

So it's -- it's easy to accidentally, you know, you have a project where you need to

convert a timezone, so you pull in a moment and then you realized that you need moment

timezone plugin and then that pulls in literally all of the geographical latitude and longitude

information about the timezone lines that you didn't know about, and wasn't documented.

So it can be an easy mistake to make, and you need tools to support you throughout that.

And also, it's about scalability, as well, it's kind of a weird term to use in this sense,

but I think about organizational scalability.

You can't be there for everything as, you know, maybe that one or maybe there's a couple

performance experts and you have this large organization, or a large project, so I tend

to speak within the context of organizations.

But you may be working on an open source project where performance is absolutely critical.

It may be for Mobile Web.

And I'm still probably forgetting tons of things.

So what are performance budgets?

It is what it sounds like.

You define something like a budget.json, you can specify some things.

Typically you might want to failure build.

It's a bit of a touchy subject to roll out to your organization, but I'll talk about

that a little bit later.

How can performance budgets help?

First of all, it gets the conversation started.

When you introduce performance budgets into your organization or project, you're immediately

going to start talking about performance, which is immediate when?

But what's more important, and one of the keys to performance budgeting is it keeps

the conversation going, so this is, you know, when you're introducing a new feature and

then you roll it out and then it fails to build, you're like, oh, well, lesson learned,

I'm going to make sure that I bring up this conversation a little bit early, because it's

kind of pushed our project a little bit out.

You're making explicit tradeoffs.

Instead of implicitly kind of making that tradeoff, you're being direct and more -- you're

being more direct about it.

There has been a conversation, there has been a commit, maybe you even bump your budget.

That's OK.

It works like that in real life.

If you've ever tried budgeting and like going on a hard core budget, the first thing you

do is overrestrict yourself.

And you adjust, and that's OK.

But it's being explicit about it that kind of helps out with the situation and it prevents

accidents.

This is one of the biggest things for me.

So there's a lot of different things that you can budget on.

So there's score-based metrics.

If you're using something like Lighthouse you might be familiar with, it gives you an

overall performance score, so you can assert on that.

So if your SEO is critical to your organization and you need that traffic coming in to make

your revenue, you know, that score is going to be important, so your SEO team might even

demand that and then there's quantitative.

So this is about numbers.

It's about how many kilobytes of JavaScript do we think we really need?

And kind of asserting against that.

It can be how many images you have on your home page?

And maybe it will remind you that oh, I need to lazy load.

That's one of the things that, like, I do as consulting within my organization.

Lazy load.

Lazy load, lazy load.

So timings, as well.

So timings can be difficult.

In fact, this is one of the things that I really wanted to touch on, because when you

roll out performance budgets into your organization, the last thing you want is false positives,

especially at the beginning, so that's one of the key advices -- pieces of advice that

I have, is to make sure that if you're budgeting, make sure that your timings or that what you're

budgeting on doesn't have false positives and that your timings are stable.

Before I forget, you know, because this is an important part, I have some advice on keeping

your timing stable, so within the type of websites that I work on, there's lots of third

parties, and that can cause a lot of volatility in your metrics, so you don't want to include

that within the metrics that you're budgeting on.

It is important that you keep an eye on those things, but make it separate and budget for

them separately.

Accessibility budgets!

This is about performance budgeting, but it's an easy thing to do, so don't forget to check

the accessibility box within your performance budgeting tool.

A lot of them come with that so you can assert against that, and it's an easy win for accessibility.

Just a caveat here: Automated accessibility detection only catches like an extremely small

amount of actual accessibility issues.

I've seen percentages as low as like 3%.

But that doesn't mean that you can't take advantage of some of those easy wins of making

some simple mistakes.

So don't forget to check the check box and don't forget to use your label tags.

So back to performance: How do you roll out performance budgets within your organization?