The Web We Weave :: How Web Developers Think About Performance

Preview:

Citation preview

The Web We WeaveHow Web Developers think about Performance

Oliver TseOctober 29, 2015

Who Am I? Oliver Tse

Web Developer

Main Objective

Seriously… when you walk out… grok/do ● Performance is more about rendering than page load ● Use Webpagetest and Chrome’s Timeline to improve

performance ● Optimize areas where changes are large enough to be

noticeable

What we’ll talk about1. Speed!2. “Client Render Time”3. Page load. It isn’t what you think.4. Enter Patrick Meenan5. Get. Do. 6. Page load redux7. All together now8. Best practices don’t guarantee best optimizations

1Speed!

What’s Fast?

"Speed. I am speed... Faster than fast, quicker than quick." - Lightning McQueen

Speed is always about time

*Objective time

How much time* does it take to do something?

How fast can the fastest jet fly?

The SR-71 takes 64 minutes to fly from Los Angeles to Washington, DC.

1. That’s 2,300 miles.2. That’s 2,145 MPH Fast.

How long does it take to...

● Get first byte?● load a page?● Render?● Paint?● Etc.

2“Client Render Time”

what’s that big blue bar?

DefinitionFound on go/speedhelp

client_render_time: from receiving first byte of base page html data to page onload (loadEventEnd - responseStart)

From w3c

From me

3Page load. It isn’t what

you think.

Hypothesispage loaded* == Complete Page

*Page Load event fires

So, at Page Load we see the complete page. Yeah!

Nope

You actually see this

Or this

Or worse

Or even worse

Why?

Page load is all mostly about downloading stuff*

● JavaScript● Images● Fonts● HTML● CSS● etc.

*stuff == “assets”

It’s not page complete

It’s all about rendering

4Enter Patrick

Meenan

2008Patrick ( and AOL ) give us Webpagetest

Performance is how much, how fast and when a page renders

New metric!“Speed index”

Speed Index The average time at which

visible parts of the page

are displayed

5Get. Do.

Use the network to get stuffUse the main thread to do stuff

Your browser uses a single thread to ● paint● render● execute JavaScript

This is called the “Main thread of execution”

Together, the network and the thread look like this

Voyager

And Homepage

And ConnectHub

And Guest Homepage

That was a lot of stuff!

Chrome DevTools Timeline

talk about them together.But first..

6Page load redux

“window.onload is not the best metric for measuring website speed”- Steve Souders

What good is page load?

Web Developers use page load as one of three markers*

*page events

The three markers1. First paint2. DOMContentLoaded3. Page load

First Paintfirst visible rendering of the page

DOMContentLoadedCSSOM and DOM are ready and…

all synchronous JavaScript executed

Page LoadAll assets downloaded ( without aid of JavaScript )

At each marker, we ask what and how much is rendered

7All together now

Let’s look at ConnectHub( with a little help from Voyager web )

Notice plateaus

Plateaus are caused by activities in the main thread and in assets downloading

The browser is doing work,but no rendering, no painting

User sees no change

55% of the main thread displays two ads

8Best practices don’t

guarantee best optimizations

Ilya Grigorik

Steve Souders

LinkedIn site-speed experts

Follow best practices or,bad things will happen.

where you apply best practices is important

Without JavaScript, faster● First paint by 25%● DOMContentLoaded by 45%● Page load by 23%● Speed Index by 30% ( from 2.0s to 1.4s )

what do you optimize?

Optimize for the most impact

The Weber-Fechner Law

“In order for users to barely see a difference in time duration, it has to be changed by a minimum of 20%”

Thank You!Have a nice day!

Questions?

Resourceshttp://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/

http://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/

Perf Shop Talk ( go/perfshoptalk )