Web Performance

Web Performance Steve Kinney

Hi, I’m Steve. (@stevekinney)

Prologue What is performance and why does it matter?

Let’s answer those in the opposite order, actually.

Why does performance matter?

Allow me to use some slides with too many words
and then read them too you. #thoughtleadership101

“ 0.1 second is about the limit for having the
user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result. —Jakob Nielsen

“1.0 second is about the limit for the user's ﬂow
of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data. —Jakob Nielsen

“10 seconds is about the limit for keeping the user's
attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to ﬁnish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then

If your user interface takes 10 seconds or more to
respond to an interaction, then we should talk.

And now: I’ll show you some statistics to make myself
sound smart.

Aberdeen Group found that a 1 second slow down resulted
11% fewer page views, 7% less conversion. Source.

Akamai found that two-second delay in web page load time
increase bounce rates by 103 percent. Source.

A 400 millisecond improvement in performance resulted in a 9%
increase in trafﬁc at Yahoo. Source.

Google found that a 2% slower page resulted in 2%
fewer searches, which means 2% fewer ads shown. Source.

100 millisecond improvement in performance results in 1% increase in
overall revenue at Amazon. Source.

53% of users will leave a mobile site if it
takes more than 3 secs to load. Source.

(One more thing…)

According to research, if you want user to feel like
your site is faster than your competitors, you need to be 20% faster.

At the same time…

Our applications are getting bigger.

Source: https://twitter.com/xbs/status/626781529054834688

LTE is actually getting slower.

Source: https://www.recode.net/2017/8/2/16069642/verizon-att-tmobile-sprint-mobile-customers-slow-speeds-unlimited-data-plan

Thinking About Performance

Are all of our needs the same?

There are different kinds of performance.

RAIL: Some numbers to think about.

Disclaimer: We’re not going to obsess over numbers.

It’s about getting 10% better.

“ “Strategies for Optimizing Web Performance When, Honestly, You Have
Like 5 Meetings Today and You Need to Choose the Correct Hills Upon Which to Strategically Die” — Romeeka Gayhart, @CCandUC

What matters to you? • The New York Times might
care about time to ﬁrst headline. • Twitter might care about time to ﬁrst tweet. • Chrome might care about time to inspect element. • What does your product or project care about?

Measure First

“ Measure. Don’t tune for speed until you’ve measured, and
even then don’t unless one part of the code overwhelms the rest. —Rob Pike

Do not go just blindly applying performance optimizations.

There is a cost to every abstraction —and everything has
a trade off.

I’m not a fan of premature optimization, but performance is
one of those things where if we’re not keeping an eye on it, it has a chance of getting away from us.

Some things to think about while measuring • Are we
testing performance on fancy MacBook Pros or consumer-grade hardware? • Are we simulating less-than-perfect network conditions. • What is our performance budget?

Don’t get carried away with measuring, either.

Thinking deeply about the architecture and design of your application
is a better use of your time than micro-benchmarks.

Three Tiers of Advice • Deﬁnitely do this. • Maybe
do this, but measure before and after. • Only do this if you ﬁnd a performance problem that needs solving.

And now: Steve’s Golden Rule of Performance

Doing Less Stuff Takes Less Time.

What does that even mean?

Steve’s Second Rule of Performance: If you can do it
later. Do it later.

Rough Outline • JavaScript performance: Write code that runs faster,
later, or not at all. • Rendering performance: It turns out most of our JavaScript happens in the browser, which has its own performance concerns. • Load performance: Until the user actually gets the page, there isn’t much to optimize.

Let’s get into it.

Chapter One JavaScript Performance.

Problem: You literally can’t buy faster servers to improve performance
of client-side applications.

I mean, you could buy all of your customers faster
computers, I guess.

A lot of time and energy is spent compressing assets,
removing requests, and reducing latency, but what about once the application is running?

Sometimes, parsing and compiling is the real culprit.

Okay, so how does JavaScript even work?

Fun fact: JavaScript is a compiled language.

Most browsers use something called just-in-time (JIT) compilation.

Things to know about JIT compilation • It means that
there is compilation step. • It means that it happens moments before execution. • That means it happens on our client’s machine. • That means they’re paying the cost and/or doing the hard work for us.

Let’s look at your code’s journey through V8 at a
high level.

Parsing

The source code is the true intention of the application,
but the engine needs to ﬁgure out what this means.

Parsing can be slow. As slow as 1MB/s on mobile.

One way to reduce parsing time is to have less
code to parse.

Another way is to do as much parsing as you
need and as little as you can get away with.

Parsing happens in two phases • Eager (full parse): This
is what you think of when you think about parsing. • Lazy (pre-parse): Do the bear minimum now. We’ll parse it for realsies later.

Generally speaking, this is a good thing™.

Doing less work is faster than doing work, right?

The basic rules • Scan through the top-level scope. Parse
all the code you see that’s actually doing something. • Skip things like function declarations and classes for now. We’ll parse them when we need them.

This could bite you. But, how?

// These will be eagerly-parsed. const a = 1; const
b = 2; // Take note that there a function here, // but, we'll parse the body when we need it. function add(a, b) { return x + y; } add(a, b); // Whoa. Go back and parse add()!

Do you see the problem here?

Corollary: Doing stuff twice is slower than doing it once.

const a = 1; const b = 2; // Parse
it now! (function add(a, b) { return x + y; }); add(a, b);

It’s deﬁnitely helpful to know how this works, but…

micro-optimization (noun): Thing you read about one time and you
know pester your co-works about in code reviews, even though it has an almost unnoticeable impact at scale.

“ “But, Steve! These little things add up!” — Me
(pretending to be you), just now.

And now: An exploration of why measuring is important.

Lab https://nolanlawson.github.io/ test-optimize-js/

Try to avoid nested functions function sumOfSquares(x, y) { //
This will repeatedly be parsed. function square(n) { return n * n; } return square(x) + square(y); }

Better… function square(n) { return n * n; } function
sumOfSquares(x, y) { return square(x) + square(y); }

Okay, cool—so it’s parsed. Now what?

It’s turned into an abstract syntax tree.

“ In computer science, an abstract syntax tree (AST) […]
is a tree representation of the abstract syntactic structure of source code written in a programming language. — Wikipedia

Essential, we’ve gone from a big long string of text
to an actual data structure representing our code.

With our AST, we now have everything we need to
make byte code!

The baseline compiler takes the AST and starts to execute
our code as we wrote it.

Three things the engine does to help you out •
Speculative optimization • Hidden classes for dynamic lookups • Function inlining

It turns out that JavaScript is hard.

It also turns out that JavaScript is dynamic.

But, what if we made some assumptions based on what
we’ve seen in the past?

Play Time

function add(a, b) { return x + y; }

We use a system called speculative optimization.

How does this work? • We use an interpreter because
the optimizing compiler is slow to get started. • Also: it needs some information before it knows what work it can either optimize or skip out on all together. • So, the interpreter starts gathering feedback about what it sees as the function is used.

But what if a string slips in there?

Play Time

The optimizing compiler optimizes for what it’s seen. If it
sees something new, that’s problematic.

But ﬁrst…

Play Time

Monomorphism.

Polymorphism.

Megamorphism.

This is not just for objects.

*–morphism. • Monomorphic: This is all I know and all
that I’ve seen. I can get incredibly fast at this one thing. • Polymorphic: I’ve seen a few shapes before. Let me just check to see which one and then I’ll go do the fast thing. • Megamorphic: I’ve seen things. A lot of things. I’m not particularly specialized. Sorry.

So, how does the browser ﬁgure out what type something
is?

Play Time

Dynamic lookup: This object could be anything, so let me
look at the rule book and ﬁgure this out.

Sure, computers are good at looking stuff up repeatedly, but
they’re also good at remembering things.

It turns out there is a secret type system behind
your back.

You can only move forward along the chain.

Okay, let’s look at this again with some real code.

Play Time

Takeaways • Turbofan is able to optimize your code in
substantial ways if you pass it consistent values.

Takeaways • Initialize your properties at creation. • Initialize them
in the same order. • Try not to modify them after the fact. • Maybe just use TypeScript or Flow so you don’t have to worry about these things?

Function Inlining

Play Time

Larger Takeaways • The easiest way to reduce parse, compile,
and execution times is to ship less code. • Use the User Timing API to ﬁgure out where the biggest amount of hurt is. • Consider using a type system so that you don’t have to think about all of the stuff I just talked about.

Chapter Two Rendering Quickly Now and Over Time.

How Web Pages Are Born

Render Tree

The Render Tree • The Render Tree has a one-to-one
mapping with the visible objects on the page. • So, not hidden object. • Yes, to pseudo elements (e.g. :after, :before). • There might be multiple rules that apply to a single element. We need to ﬁgure that all out here.

Style calculation: The browser ﬁgures out all of the styles
that will be applied to a given element.

This involves two things: • Figuring out which rules apply
to which elements. • Figuring out how what the end result of an element with multiple rules is.

Styling Elements: Selector Matching

This is the process of ﬁguring out what styles apply
to an element.

The more complicated you get, the longer this takes.

Class names are super simple.

.sidebar > .menu-item:nth-child(4n + 1)

Free Advice: Stick to simple class names whenever possible. Consider
using BEM.

Browsers read selectors from right to left.

The less selectors you use, this faster this is going
to be.

Takeaways • Use simple selectors whenever possible. • Consider using
BEM or some other system. • Reduce the effected elements. • This is really a way to get to the ﬁrst one. • A little bit of code—either on the server or the client— can go a long way.

Styling Elements: Calculating Render Styles

Selector matching tries to ﬁgure out what selectors apply to
an element.

When multiple selectors apply to an element. The browser needs
to ﬁgure out who wins.

The easiest way to make this faster is to not
do it.

Free Advice (again): Stick to simple class names whenever possible.
Consider using BEM.

A quick note on style invalidation: It doesn’t matter as
much in newer browsers.

Some Takeaways • Reduce the amount of unused CSS that
you’re shipping. • The less styles you have, the less there is to check. • Reduce the number of styles that effect a given element.

Layout (a.k.a Reﬂow): Look at the elements and ﬁgure out
where they go on the page.

Paint: We know what things should look like and where
they should go. Draw some pixels to the screen.

Composite Layers: You might end up painting on multiple layers,
but you’ll eventually need to combine them.

Proﬁt.

JavaScript gives you the ability to change all of this
after the initial load, which means you might have to do all of the above again.

Things JavaScript can do: An incomplete list™ • Change the
class on an object. • Change the inline styles on an object. • Add or remove elements from the page.

The Render Pipeline

Okay, so let’s say you change a class or inline
style on an element.

The computed styles could have changed—so, we better recalculate those
and rebuild the render tree.

That may or may not have changed the geometry of
the objects. We should probably re-layout the page.

Things are different. I guess we need to paint some
new images.

Send those images off to the GPU to be composited.

To be clear: You don’t need to do all of
these things every time.

And, that’s what this is about.

Reminder: Steve’s golden rule of performance.

Layouts and Reﬂows

“Reﬂows are very expensive in terms of performance, and is
one of the main causes of slow DOM scripts, especially on devices with low processing power, such as phones. In many cases, they are equivalent to laying out the entire page again. —Opera

Whenever the geometry of an element changes, the browser has
to reﬂow the page.

(Browser implementations have different ways of optimizing this, so there
is no point sweating the details in this case.)

Tasting Notes • A reﬂow is a blocking operation. Everything
else stops. • It consumes a decent amount of CPU. • It will deﬁnitely be noticeable by the user if it happens often (e.g. in a loop).

A reﬂow of an element causes a reﬂow of its
parents and children.

Okay, so what causes a reﬂow? • Resizing the window
• Changing the font • Content changes • Adding or removing a stylesheet • Adding or removing classes • Adding or removing elements • Changing orientation • Calculating size or position • Changing size or position • (Even more…)

Generally speaking, a reﬂow is followed by a repaint, which
is also expensive.

How can you avoid reﬂows? • Change classes at the
lowest levels of the DOM tree. • Avoid repeatedly modifying inline styles. • Trade smoothness for speed if you’re doing an animation in JavaScript. • Avoid table layouts. • Batch DOM manipulation. • Debounce window resize events.

Lab https://codepen.io/ stevekinney/full/eVadLB/

Layout Thrashing

Less cool names: Forced synchronous layout.

There are a set of things you can do that
cause the browser to stop what it’s doing and calculate style and layout.

“ Layout Thrashing occurs when JavaScript violently writes, then reads,
from the DOM, multiple times causing document reﬂows. —Winston Page

const height = element.offsetHeight;

const height = element.offsetHeight; The browser wants to get you
the most up to date answer, so it goes and does a style and layout check.

firstElement.classList.toggle('bigger'); const firstElementWidth = firstElement.width; secondElement.classList.toggle('bigger'); const secondElementWidth = secondElement.width;

firstElement.classList.toggle('bigger'); // Change! const firstElementWidth = firstElement.width; // Calculate secondElement.classList.toggle('bigger');
// Change! const secondElementWidth = secondElement.width; // Calculate

The browser knew it was going to have to change
stuff after that ﬁrst line.

Then you went ahead and asked it for some information
about the geometry of another object.

So, it stopped your JavaScript and reﬂowed the page in
order to get you an answer.

Solution: Separate reading from writing.

firstElement.classList.toggle('bigger'); // Change! secondElement.classList.toggle('bigger'); // Change! const firstElementWidth = firstElement.width;
// Calculate const secondElementWidth = secondElement.width; //

Play Time

It sounds like we could use a better abstraction, right?

fastdom.measure(() => { console.log('measure'); }); fastdom.mutate(() => { console.log('mutate'); });
fastdom.measure(() => { console.log('measure'); }); fastdom.mutate(() => { console.log('mutate'); });

Play Time

Lab https://codepen.io/ stevekinney/full/eVadLB/

React to the rescue?

class App extends Component { state = { widths: [50,
100, 150], } doubleSize = () => { const widths = this.state.widths.map(n => n * 2); this.setState({ widths }); }; render() { const [firstWidth, secondWidth, thirdWidth] = this.state.widths; return ( <div> <button onClick={this.doubleSize}>Double Sizes </button> <div style={{ width: firstWidth }} /> <div style={{ width: secondWidth }} /> <div style={{ width: thirdWidth }} /> </div> ); } }

Lab https:// 2z379l1pjr.codesandbox.io/

Friendly fact: Production mode is important in React!

Play Time

Er, maybe not.

Some Takeaways • Don’t mix reading layout properties and writing
them— you’ll do unnecessary work. • If you can change the visual appearance of an element by adding a CSS class. Do that, you’ll avoid accidental trashing.

Some Takeaways • Storing data in memory—as opposed to the
DOM—means we don’t have to check the DOM. • Frameworks come with a certain amount of overhead. • You don’t need to use a framework to take advantage of this. • You can do bad things even if you use a framework. • You may not know you’re layout thrashing—so, measure!

Painting, Layers, the Proﬁling Thereof

Anytime you change something other than opacity or a CSS
transform… you’re going to trigger a paint. '

When we do a paint, the browser tells every element
on the page to draw a picture of itself.

It has all of this information form when we constructed
the render tree and did the layout.

Triggering a layout will always trigger a paint.

But, if you’re just changing colors or something—then you don’t
need to do a reﬂow. Just a repaint.

Use your tools to see if you’re painting.

Play Time

Rule of Thumb: Paint as much as you need and
as little as you can get away with.

An Aside: The Compositor Thread

Nice threads • The UI thread: Chrome itself. The tab
bar, etc. • The Renderer thread: We usually call this the main thread. This is where all JavaScript, parsing HTML and CSS, style calculation, layout, and painting happens. There are one of these per tab. • The Compositor Thread: Draws bitmaps to the screen via the GPU.

The Compositor Thread • When we paint, we create bitmaps
for the elements, put them onto layers, and prepare shaders for animations if necessary. • After painting, the bitmaps are shared with a thread on the GPU to do the actual compositing. • The GPU process works with OpenGL to make magic happen on your screen.

The Main Thread is CPU- intensive.

The Compositor Thread is GPU-intensive.

It can go off and work on some super hard
JavaScript computation and the animations will still chug along.

This is cool, because it frees up the main thread
to do all of the work it’s responsible for.

Managing Layers

Again: Painting is super expensive and you should avoid it
whenever possible.

“ But, Steve—how do I avoid painting? Isn’t that just
a fact of life when it comes to getting pixels on the screen? —Your inner monologue

“ “Let the Compositor Thread handle this stuff!” — Me,
in response

Things the compositor thread is really good at: • Drawing
the same bitmaps over and over in different places. • Scaling and rotating bitmaps. • Making bitmaps transparent. • Applying ﬁlters. • Mining Bitcoin.

If you want to be fast, then ofﬂoad whatever you
can to the less-busy thread.

Disclaimer: Compositing is kind of a hack.

Layers are an optimization that the browser does for you
under the hood.

What kind of stuff gets its own layer? • The
root object of the page. • Objects that have speciﬁc CSS positions. • Objects with CSS transforms. • Objects that have overﬂow. • (Other stuff…)

http://bit.ly/paint-layers

Objects that don’t fall under one of these reasons will
be on the same element as the last one that did.

(Hint: The root object is always its own layer.)

You can give the browser hints using the will-change property.

.sidebar { will-change: transform; }

.sidebar { transform: translateZ(0); }

.sidebar { will-change: transform; }

Play Time

⚠ Using layers is a trade off.

Managing layers takes a certain amount of work on the
browser’s behalf.

Each layer needs to be kept in the shared memory
between the main and composite threads.

This is a terrible idea. * { will-change: transform; }

The browser is already trying to help you out under
the hood.

Pro Tip: will-change is for things that will change. (Not
things that are changing.)

Promoting an object to its own layer takes a non-zero
amount of time.

.sidebar.is-opening { will-change: transform; transition: transform 0.5s; transform: translate(400px); }

.sidebar { will-change: transform; transition: transform 0.5s; } .sidebar:hover {
will-change: transform; } .sidebar.open { transform: translate(400px); }

will-change is tricky because while it’s a CSS property, you’ll
typically access it using JavaScript.

element.addEventListener('mouseenter', () => { element.style.willChange = 'transform'; });

If it’s something that the user is interacting with constantly,
add it to the CSS. Otherwise, do it with JavaScript.

Clean up after yourself. Remove will- change when it’s not
going to change anymore.

element.addEventListener('mouseenter', () => { element.style.willChange = 'transform'; }); element.addEventListener('animationEnd', ()
=> { element.style.willChange = 'auto'; });

Exercise • Let’s look at the “Paint Storming” example. •
Don’t be surprised if you ﬁnd a paint storm. • Can you swap out that jQuery animation for a CSS transition? • Can you put the will-change on before the transition? • Can you remove it after?

Chapter Three Getting What You Need

Latency and Bandwidth: A Journey of Self-Discovery

“ Networks, CPUs, and disks all hate you. On the
client, you pay for what you send in ways you can't easily see. —Alex Russell

Bandwidth vs. Latency • Bandwidth is how much stuff you
can ﬁt through the tube per second. • Latency is how long it takes to get to the other end of the tube.

https://www.youtube.com/watch?v=ak4EZQB4Ylg

TCP focuses on reliability • We keep checking in with
the server to make sure that everything is going well. • Packets are delivered in the correct order. • Packets are delivered without errors. • Client acknowledges each packet. • Unreliable connections are handled well. • Will not overload the network.

TCP starts by sending a small amount of data and
then starts sending more and more as we ﬁnd out that things are being successful.

Fun fact: This is why things feel so much worse
on a slow Internet connection.

Pro tip: The initial window size is 14kb. So, if
you can get ﬁles under 14kb, then it means you can get everything through in the ﬁrst window. Very cool.

Lab http://www.cloudping.info/

Hmm… So, where is the optimal place to put our
assets?

Answer: Everywhere.

Cache Money

The year is 1997.

HTTP/1.1 added the Cache- Control response header.

Caching only affects the "safe" HTTP methods. • GET •
OPTIONS • HEAD

It doesn’t support … because how would it? • PUT
• POST • DELETE • PATCH

Cache-Control headers • no-store • no-cache • max-age • s-maxage
• immutable

Three over-simpliﬁed possibilities • Cache Missing: There is no local
copy in the cache. • Stale: Do a Conditional GET. The browser has a copy but it's old and no longer valid. Go get a new version. • Valid: We have a thing in cache and its good—so, don't even bother talking to the server.

no-store: The browser gets a new version every time.

no-cache: This means you can store a copy, but you
can't use it without checking with the server.

max-age: Tell the browser not to bother if whatever asset
it has is less than a certain number of seconds old.

Caching is great unless you mess it up.

We can say "Yo, cache this for a long time!”
But, what if we ship some bunk assets? Oh no.

How the will the user know to do a hard
refresh to get the new ones?

Another solution: Content- Addressable Storage

main.567eea7aa72b3ee48649.js

Caching for CDNs CDNs respect the max-age header just like
browsers. But this opens up a new can of worms. • We want CSS and JavaScripts to be cached by the browser. • We would like the CDN to cache the HTML that it serves up. But we don't want the browser to (because that ends us up in our earlier problem).

s-maxage is for CDNs only. Tell the CDN to keep
it forever. But don't tell the browser to do it.

To reiterate: We have no way to reach into all
of our customers browsers and tell them to purge their caches of our assets, but we can tell the CDN to.

Lazy-loading and pre-loading with React and webpack

And now: A review of Steve’s golden rules for performance.

Not doing stuff is faster than doing stuff.

Doing stuff later is a way to not do stuff
now. So, it’s faster.

Play Time

Exercise • So, I implemented lazy-loading for the Codemirror editor.
• But, it looks like the Markdown component is taking up quite a bit of space as well. • Could you lazy-load that too for me?

Takeaways • Some libraries have code you don’t need. See
if you can get that out of your build. • Get the code you need now now. • Get the code you need later later. • Your tools can help you do this.

Please allow me to hop on my soap box for
a moment.

Some Words on HTTP/2

HTTP/2: What even are you? • An upgrade to the
HTTP transport layer. • Fully multiplexed—send multiple requests in parallel. • Allows servers to proactively push responses into client caches.

HTTP/1.1: What’s wrong with you? • Websites are growing: more
images, more JavaScript • Sure, bandwidth has gotten a lot better, but roundtrip time hasn’t • It takes just as long to ping a server now as it did 20 years ago. • That’s right: one ﬁle at a time per connection • No big deal. It’s not like we are building websites that request 100 ﬁles to something.

The weird thing is that once you have this in
place some “best practices” become not-so-good.

Is concatenating all of your JS and CSS into large,
single ﬁles still useful?

What about inlining images as data URLs in our CSS?

Measure, measure, measure.

Getting HTTP/2: The easy way.

This slide is for you to locate the services mentioned
in the previous slide—because I you. • https://now.sh • https://aws.amazon.com/cloudfront/ • https://cloudﬂare.com • https://netlify.com

Chapter Four Build It Faster. Build It Smarter.

When in doubt, let your tools help you.

Lab Paying the Babel Tax™

Let’s ﬁle these under “maybe use.”

babel-preset-env is your friend.

{ "presets": ["env"] }

{ "presets": [ ["env", { "targets": { "browsers": ["last 2
versions", "safari >= 7"] } }] ] }

npm install @babel/plugin- transform-react-remove-proptypes

import React from 'react'; import PropTypes from 'prop-types'; class Announcement
extends React.Component { render() { return ( <article> <h1>Important Announcement </h1> <p>{this.props.content} </p> </article> ) } } Announcement.propTypes = { content: PropTypes.string, } export default Announcement;

import React from 'react'; import PropTypes from 'prop-types'; class Announcement
extends React.Component { render() { return <article> <h1>Important Announcement </h1> <p>{this.props.content} </p> </article>; } } export default Announcement;

{ "plugins": [ "syntax-jsx", [ "transform-react-remove-prop-types", { "removeImport": true }
] ] }

import React from 'react'; class Announcement extends React.Component { render()
{ return <article> <h1>Important Announcement </h1> <p>{this.props.content} </p> </article>; } } export default Announcement;

{ "plugins": [ "syntax-jsx", [ "transform-react-remove-prop-types", { "mode": "wrap" }
] ] }

Announcement.propTypes = process.env.NODE_ENV !== "production" ? { content: PropTypes.string }
: {};

npm install babel-plugin- transform-react-pure-class-to- function

This is another one of those plugins that does what
it says on the tin.

import React from 'react'; class Announcement extends React.Component { render()
{ return ( <article> <h1>Important Announcement </h1> <p>{this.props.content} </p> </article> ) } } export default Announcement;

import React from 'react'; function Announcement(props) { return <article> <h1>Important
Announcement </h1> <p>{props.content} </p> </article>; } export default Announcement;

What if the component has state?

class Counter extends React.Component { constructor() { super(); this.state =
0; } render() { return <p>{this.state.count} </p>; } }

Why is this cool?

npm install @babel/plugin- transform-react-inline-elements

What is this and why is it fast?

This… <div className="important">Hello World </div>

…becomes… React.createElement( "div", { className: "important" }, "Hello World" );

…becomes… { $$typeof: [object Symbol] { ... }, _owner: null,
_store: [object Object] { ... }, key: null, props: { children: "Hello World", className: "important" }, ref: null, type: "div" }

Not doing something is faster than doing it.

But, if you have to do it, then you might
as well only do it once.

Do it at build time.

Admission: what actually comes out of this plugin is a
little grosser.

npm install @babel/plugin- transform-react-constant- elements

import React from 'react'; class Article extends React.Component { render()
{ return ( <article> <h1>Important Announcement </h1> <p>{this.props.content} </p> <footer>—The Management </footer> </article> ) } } export default Announcement;

import React from 'react'; var _ref = <h1>Important Announcement </h1>;
var _ref2 = <footer>—The Management </footer>; class Announcement extends React.Component { render() { return <article> {_ref} <p>{this.props.content} </p> {_ref2} </article>; } } export default Announcement;

for (let x = 0; x < 10; x ++)
{ console.log(x); }

console.log(0); console.log(1); console.log(2); console.log(3); console.log(4); console.log(5); console.log(6); console.log(7); console.log(8); console.log(9);

(function () { function fibonacci(x) { return x <= 1
? x : fibonacci(x - 1) + fibonacci(x - 2); } global.x = fibonacci(10); })();

Prepack is not production ready, but it’s an interesting idea
and you should be thinking along these lines.

Epilogue Closing Thoughts, Recommendations, and Further Research

Free tip (repeated): Make sure you’re running in “Production Mode”.

What is production mode? • PropTypes? Nah. • “Helpful” warnings?
No, thanks. • Performance metrics? Nope. • Not having this stuff relieves React of a bunch of work and allows it to run fast.

Some super important things we didn’t talk about today. •
Server-side rendering. • Image performance. • Loading web fonts. • Progressive web applications.

Avoid Render Blocking

Render blocking is anything that keeps the browser from painting
to the screen—or, umm, rendering.

Quick Tip: Make sure your CSS <link>s are in the
<head>.

Inlining has trade offs. • Sure, it saves you a
network request. • But, you can’t cache the styles. • So, while it might work better for single-page applications, you wouldn’t want to include it every HTML page on multi- page applications. • With HTTP/2, you can actually just avoid this problem all together.

Web Performance

Web Performance

More Decks by Steve Kinney

Featured

Transcript