Think

, First

Empowering Performance Culture

Hi, I'm Alfredo.

You can call me Al...

@lfredolo

This is my story of attending

PerfMatters

Learnings

Attempts

Achievements

Let's rewind

Hearst is a media company with more than 360 businesses.
Its major interests include magazines, TV networks, newspapers and more.

100+ websites

1 application

* But there are a lot more... * When I started at the company, we had considerably fewer properties so it made sense for them to be separate, * but as we added more brands, it was challenging to maintain, deploy but also evolve. * We were unable to experiment new features in smaller sites, and roll it out across the platform. * So, we decided to build an application that would consolidate all of our sites. * That’s 100+ websites * Powered by 1 application * and, this is awesome because it gives us control, but at the same time we have the additional responsibility that when we break or reduce performance in a shared component, this is reflected immediately across the platform, and it hurts when that happens. * Because of that, as we were writing our goals for 2018 we knew we had to put a special focus on performance. I discovered this great conference, and convinced my boss to send me.

1. Get the Executive Buy-In

Measure
Compare to Competitors

Performance Calculator

https://www.thinkwithgoogle.com/feature/testmysite

* Additionally, Google allows you to see some of that data at thinkwithgoogle.com, where you can also find a Performance Calculator, that based on a few variables it calculates how much money you’re leaving on the table. For an ad revenue business, this is harder to figure it out because there are so many different variants. I remember that at this point in my presentation, I still had a few slides but the executives looked at those numbers, stopped me, and said go for it.

Where to start?

Before

360kb Uncompressed

MAKE IT FASTER

Does the user need
this right now?

Infer by user action

Progressive Enhancements

* You can also use Progressive Enhacements * This term is used to refer to polyfills when supporting new features in older browsers, but this can applies to features as well. * On our sites, we have a search modal that opens and some logic that deals with the typeahead logic. if you narrow down the requirements, it’s critical that the user is able to type and search, so in this scenario the typeahead becomes an enhancement. * We separated the logic that deals with opening the modal, which is minimal and we realized that we could apply an awesome Javascript technique of deleting code and doing it with CSS. * We use the hash target to show/hide the modal, it's worth mentioning that there are some accessibility concerns like the page scrolling to the top when switching to an empty hash but in mobile our search is not sticky, and on desktop we’re able to load additional Javascript to prevent this. * A bonus is that the autocomplete module was using some vendors, so we were able to tackle it later because we moved it away from the critical rendering path.

After

27kb Uncompressed

~4 seconds faster FCP

Why is it still slow?

First Party vs Third Party

First Party: 11 Requests
Tag Manager: 7th Request
Third Party: 125 Requests

Optimizing Performance
is like going to the dentist

Looking back...

Focused on delivering results
Teams felt it was a top-down decision
How fast is fast enough?

What if performance is part of
the development process?

2. Developer Awareness

BEST PRACTICES

Performance is easy

Making fast websites in 2019 isn’t difficult.
You just have to be buddies with browser makers,
get paid to make websites faster, hang out on Twitter all day
for all the hot performance tips, and prefer hacking on
performance tweaks to watching Netflix.

Malte Ubl

Divide and Conquer

Server

Application

Development

Potential Bottlenecks

What do you
intend to do?

Abstract frequent optimizations

getBoundingClientRect

      
        // module-a.js
        requestAnimationFrame(() => {
          const { right, bottom } = el.getBoundingClientRect();
        });
        // module-b.js
        requestAnimationFrame(() => {
          el.classList.add('change-size'); 😱
        });

IntersectionObserver

      
        const io = new IntersectionObserver((entries) => {
          entries.forEach(entry => {
            //   entry.boundingClientRect
            //   entry.intersectionRatio
            //   entry.intersectionRect
            //   entry.isIntersecting
            //   entry.rootBounds
            //   entry.target
            //   entry.time
          });
        });
        // observe the element
        io.observe(el);

      
        const getBoundingClientRect = el =>
          new Promise((resolve) => {
            const io = new IntersectionObserver((entries) => {
              resolve(entries.shift().boundingClientRect);
              io.disconnect();
            });
            io.observe(el);
          });

        
        const touchDevice = 'ontouchstart' in window;

        const addListener = (target, type, listener) => {
          // switch click to touchstart on touch devices
          if (type === 'click' && touchDevice) {
            type = 'touchstart';
          }

          target.addEventListener(type, listener);
        }

* For example: getBoundingClientRect.

It’s an amazing method that returns the coordinates, width and height, and the dimensions of an element, and it’s extremely precise.

But unfortunately, it’s a synchronous method and forces a layout. This means the browser has to drop whatever is doing, and paint the screen, which can translate to visual jank.

* One possible solution is to use requestAnimationFrame, but if one of those frames changes the dimensions of the element, you’ll still force a layout. * So going back to the Intersection Observer, while I was doing the infinite loop technique. I realized a couple of things: * The entries on the IO have a boundingClientRect, and the callback executes after observing an element, not only when it’s in view, so all your code needs an if statement for isIntersecting. * But this means, we can have an asynchronous getBoundingClientRect, and this will be the safest way to do it as of now, because you’re asking to be notified of the next frame. * Another optimization is to automatically switch all your click events to mouse down for improved perceived performance. This will give you on average ~100ms head start, which leads me to the question that came up often:

Is it worth it?

Is it part of the critical path?
How frequent will it run?
Is it a shared or base component?

Your one-off is someone's pattern.

Looking back...

Developers were challenged by constraints
Features took longer to finish
Education without immediate action is quickly forgotten.

* Looking back * Developers were challenges by constraints, which again is both good and bad. Some devs enjoyed the challenge of doing more with less, but others saw it as slowing them down. * which caused features taking longer to finish. * Education without immediate action is quickly forgotten. * Last year, I talked internally about performance non-stop, * and a few weeks ago I noticed a conversation about React.lazy, * where one of the developers asking if it was noticeable, * and it’s not like this person was oblivious to my presentations, but he thought codesplitting was a webpack thing. * and you can look at each one of these things, and say you can hire devs with a focus on performance, you can show the business that moving slower but safer is an acceptable tradeoff, and you can invest more on education in and outside your organization.

so, now what?

You need the cooperation of all these different groups to actually achieve your goals.

Lauren Nagel Younger

3. Product and Design

1. Idea 2. Prototype 3. Test

4. Development 5. MVP 6. Optimize

Where we think Performance should happen.

Where it should happen.

Could performance affect your hypothesis?

"We accounted for it during testing"
Features are not isolated

Performance Paths

Why are we doing this?
Align best practices with goals
Render vs Runtime
Mobile vs Desktop

We plan for today's problems.

But how can we prevent from blocking ourselves tomorrow?

Tech Debt != Bad Code

Technical Debt is not a catch-all term for bad code.

It is deliberate borrowing against future productivity. You must know when you're doing it and why.

Bad code that bites you long after you've written it can't be retrospectively labelled Technical Debt. It's just bad code.
— Richard Dalton 🇪🇺 (@richardadalton) March 28, 2019

What if it rocks?

Share the vision

Document your tradeoffs

Specify the reasons.

Is it by design?
Is it a technical limitation?

Plan your tradeoffs

Describe the scenarios
a tradeoff would block.

Prevent "Told you so" moments.

You don't have to build to enable it.

Don't go down a rabbit hole

Timebox it!

You are all caught up!

Lessons learned

A temporary manual setup is crucial to progressively refactor an application.

81kb

86kb

Customization is key

Wishlist: Performance options per bundle

      
        module.exports = {
          performance: {
            assetFilter: function(assetFilename) {
              return !legacy.includes(assetFilename);
            }
          }
        };

Performance budgets
are great, but...

It's rarely a single Pull Request

Predicting Regressions

Sptter

Spotter

- It analyzed the files modified in each open PR, and added a comment letting you know what other PRs were modifying the same files, - so that when a PR is merged, you don’t find that someone modified or removed a piece of code you were relying on, - and a piece of work that was deemed “done” is now back in development. * This approach could be used to have a bot user that can generate a branch on demand and copying open PRs that are ready to merge every day, * open a temporary PR and run performance tests. * That way, we’d be able to predict that if an n amount of PRs were all to get merged and released today, that'd be our performance change. * It’d allow us to be more proactive than reactive towards regressions and I’m happy to say that my plan is to open source these tools.

TLDR

What should we do if we care about performance?

Don't stop at tools or techniques but how they fit into a process.

How do we get
our colleagues to care about performance?

Think

FastFast

, First

Empowering Performance Culture

Hi, I'm Alfredo.

You can call me Al...

@lfredolo

This is my story of attending

PerfMatters

Learnings

Attempts

Achievements

Let's rewind

Hearst is a media company with more than 360 businesses.Its major interests include magazines, TV networks, newspapers and more.

100+ websites

1 application

1. Get the Executive Buy-In

Measure

Compare to Competitors

Performance Calculator

https://www.thinkwithgoogle.com/feature/testmysite

Where to start?

Before

360kb Uncompressed

MAKE IT FASTER

Does the user needthis right now?

Infer by user action

Progressive Enhancements

After

27kb Uncompressed

~4 seconds faster FCP

Why is it still slow?

First Party vs Third Party

Optimizing Performanceis like going to the dentist

Looking back...

What if performance is part ofthe development process?

2. Developer Awareness

BEST PRACTICES

Performance is easy

Making fast websites in 2019 isn’t difficult.You just have to be buddies with browser makers,get paid to make websites faster, hang out on Twitter all dayfor all the hot performance tips, and prefer hacking onperformance tweaks to watching Netflix.

Malte Ubl

Divide and Conquer

Server

Application

Development

Potential Bottlenecks

What do youintend to do?

Abstract frequent optimizations

getBoundingClientRect

IntersectionObserver

Is it worth it?

Your one-off is someone's pattern.

Looking back...

so, now what?

You need the cooperation of all these different groups to actually achieve your goals.

Lauren Nagel Younger

3. Product and Design

1. Idea 2. Prototype 3. Test 4. Development 5. MVP 6. Optimize

Where we think Performance should happen.

Where it should happen.

Could performance affect your hypothesis?

Performance Paths

This is a chance to sharespecific knowledge

Render -> Markup Size -> TTFB -> SEO Impact

=

We plan for today's problems.

But how can we prevent from blocking ourselves tomorrow?

Tech Debt != Bad Code

What if it rocks?

Share the vision

Document your tradeoffs

Plan your tradeoffs

You don't have to build to enable it.

Don't go down a rabbit hole

Timebox it!

You are all caught up!

Lessons learned

A temporary manual setup is crucial to progressively refactor an application.

81kb

86kb

Hearst is a media company with more than 360 businesses.
Its major interests include magazines, TV networks, newspapers and more.

Does the user need
this right now?

Optimizing Performance
is like going to the dentist

What if performance is part of
the development process?

Making fast websites in 2019 isn’t difficult.
You just have to be buddies with browser makers,
get paid to make websites faster, hang out on Twitter all day
for all the hot performance tips, and prefer hacking on
performance tweaks to watching Netflix.

What do you
intend to do?

1. Idea 2. Prototype 3. Test

4. Development 5. MVP 6. Optimize

This is a chance to share
specific knowledge

Performance budgets
are great, but...

How do we get
our colleagues to care about performance?

Performance culture
is more than code