Pragmatic Web Performance

A presentation at GitLab Virtual Contribute by Denys Mishunov

PRAGUEMATIC WEB PERFORMANCE DENYS MISHUNOV Senior Frontend Engineer, Create::Editor

How long is forever? Sometimes, just one second

E S N O P S E R R O ” “ O E P T P I E S N R B E F T E O F W R O O M “ N T A O H N E E C M R I E W T T … O I S ” O E L A ” G W R E O A T L S T S U J S ’ T I “ GitLab, UX research by Jeff Crow and Farnoosh Seifoddini

E S N O P S E R R O ” “ O E P T P I E S N R B E F T E O F W R O O M “ N T A O H N E E C M R I E W T T … O I S ” O E L A ” G W R E O A T L S 18.5% Dedicated the time to say how not impressed they are with performance T S U J S ’ T I “ GitLab, UX research by Jeff Crow and Farnoosh Seifoddini

E S N O P S E R R O ” “ O E P T P I E S N R B E F T E O F W R O O M “ N T A O H N E E C M R I E W T T … O I S ” O E L A ” G W R E O A T L S Q2 OKRs https://gitlab.com/groups/gitlab-com/-/epics/464 T S U J S ’ T I “

PRAGMATIC prag • mat • ic adj. Dealing or concerned with facts or actual occurrences; practical

WHAT TO MEASURE? • Overall page size • Number of server requests • The size of the bundled JS resources • etc.

WHAT TO MEASURE? PAGE LOADING TIME • DOMContentLoaded Event • Onload Event • First Paint • First Contentful Paint • First Meaningful Paint • Largest Contentful Paint • SpeedIndex

52 Performance (Fast 3G connection, caching disabled) First Contentful Paint 2.9 s Speed Index 3.2 s Time to Interactive 10.1 s First Meaningful Paint 7.7 s First CPU Idle 10.0 s Max Potential First Input Delay 1.160 ms

Generic First Contentful Paint 2.9 s Speed Index 3.2 s Time to Interactive 10.1 s First Meaningful Paint 7.7 s First CPU Idle 10.0 s Max Potential First Input Delay 1.160 ms Could be fragile for monitoring There are too many

First Contentful Paint 2.9 s Speed Index 3.2 s Time to Interactive 10.1 s First Meaningful Paint 7.7 s First CPU Idle 10.0 s Max Potential First Input Delay 1.160 ms HOW SOON DOES USER SEE THE SNIPPET?

WHAT TO MEASURE? PAGE LOADING TIME USER TIMING API

PERFORMANCE API https://developer.mozilla.org/en-US/docs/Web/API/Performance

PERFORMANCE API https://developer.mozilla.org/en-US/docs/Web/API/Performance Performance Timeline API

PERFORMANCE API https://developer.mozilla.org/en-US/docs/Web/API/Performance Performance Timeline API Navigation Timing
API

PERFORMANCE API https://developer.mozilla.org/en-US/docs/Web/API/Performance Performance Timeline API Navigation Timing
API Resource Timing API https://mzl.la/2Kg4oIT

performance.measure(MEASURE_NAME, START_MARK, END_MARK);

window.requestAnimationFrame(() => { performance.measure(MEASURE_NAME, START_MARK, END_MARK); })

75% waiting to bootstrap the Vue application*
most probably due to the development env

pe rf or ma nc e. m ar k( S TA RT _M AR K) ; USER TIMING API

pe pe rf rf or or ma ma nc nc e. m e. m ar ar k( E k( S ND TA _M RT AR _M K) ; K) ; AR USER TIMING API

AR _M ND k( E ar e. m nc ma or rf pe pe rf or ma nc e. m ar k( S TA RT _M AR K) ; K) ; USER TIMING API performance.measure(MEASURE_NAME, START_MARK, END_MARK);

pe rf or ma nc e. m ar k( S TA RT _M AR K) ; USER TIMING API performance.measure(MEASURE_NAME, START_MARK);

USER TIMING API performance.measure(MEASURE_NAME);

USER TIMING API CROSS-COMPONENT Marks can be placed and measured anywhere on the page NOT VUE-SPECIFIC Can be added to any JS

MEASURE • MONITOR • OPTIMISE Page Loading Time User Timing API

MONITOR ANALYTICS TOOLS Google Analytics Snowplow etc.

MONITOR PERFORMANCE TOOLS Webpagetest Pingdom sitespeed.io SpeedCurve etc.

MONITOR ANALYTICS PERFORMANCE SNOWPLOW SITESPEED.IO

MONITOR SNOWPLOW https://docs.gitlab.com/ee/telemetry/index.html • Clicking links or buttons. • Submitting forms. • Other typically interface-driven actions

MONITOR SNOWPLOW https://docs.gitlab.com/ee/telemetry/index.html • Event tracking: https://docs.gitlab.com/ee/telemetry/index.html • Snowplow tracking guide: https://docs.gitlab.com/ee/telemetry/snowplow.html#frontendtracking • Enable Snowplow tracking in Admin Area > Settings > Integrations • Add tracking to your code

MONITOR SNOWPLOW PROS: CONS: • Monitors exactly what you send to it • Monitors exactly what you send to it • Metrics won’t work with DNT setting • Requires analytics-specific code

MONITOR SITESPEED https://gitlab.com/gitlab-org/frontend/sitespeed-measurement-setup

MONITOR SITESPEED PROS: CONS: • Dedicated performance tool • No additional code required • Setting up Docker to run against localhost or local host (defined in /etc/hosts) is a nightmare

MONITOR ANALYTICS PERFORMANCE RETROSPECTIVE

context ‘Frontend Performance’ do let(:file_name) { ‘popen.rb’ } let(:content) { project.repository.blob_at(‘master’, ‘files/ruby/popen.rb’).data } before do stub_feature_flags(snippets_vue: true) visit snippet_path(snippet) # wait_for_requests sleep 5 end it ‘starts rendering snippet within 0.5 seconds +-20% percent’ do expect(page.evaluate_script(‘window.performance.getEntriesByName(“vue-start”)[0].startTime/ 1000’)).to be_within(0.125).of(0.5) end it ‘renders full snippet within 2 seconds +-20% percent’ do expect(page.evaluate_script(‘window.performance.getEntriesByName(“content-full”)[0].duration/ 1000’)).to be_within(0.5).of(2.0) end end

MEASURE • MONITOR • OPTIMISE Page Loading Time Sitespeed User Timing API Snowplow

OPTION #1 OPTION #2 1.6 SECONDS 2.0 SECONDS

PERFORMANCE BUDGET INSTANT (0.1—0.2s) IMMEDIATE (0.5—1s) USER FLOW (2—15)

THE NEED OPTIMISE TO IMPROVE BAD METRICS

OPTION #1 OPTION #2 400 milliseconds 1.6 SECONDS 2.0 SECONDS

WEBER-FECHNER LAW JUST NOTICEABLE DIFFERENCE (JND) EVENT

WEBER-FECHNER LAW JUST NOTICEABLE DIFFERENCE (JND) EVENT 20%

T O NOTICEABLE N JUST Y L I R L A U S F S G E DIFFERENCE N C E NI N EA M

CHASING THE LEADER OPTIMISE TO SURVIVE COMPETITION

CHASING THE LEADER GEOMETRIC BISECTION 3.2S

IS IT NEEDED?
PERFORMANCE BUDGET 2. THE NEED 3. CHASING THE LEADER

#thanks TIME SPENT EDUCATING ME DURING THE COFFEE-CHATS VALUABLE COMMENTS AND HELP #GitLabContribute RAMYA AUTHAPPAN · ALEX BUIJS · JEFF CROW JEROME NG · JEREMY JACKSON · GEORGI N. GEORGIEV PEDRO POMBEIRO · VIJAY HAWOLDAR · ASH MCKENZIE

Denys Mishunov
@mishunov

1 / 96

There are a lot of different values, measurements, and significant times when it comes to web performance. However, most of those do not take into consideration your project, your architecture and your project’s audience into consideration. Those are good generic starting points. However, fighting to get those values to some artificial number might take a lot of time and resources. At the end of the day, you might even find out that even lower generic numbers don’t mean better performance of your project. In this workshop/talk, I will discuss the ways to measure what really matters for a product, page, and even a separate component. We will discuss and see examples of how to use those measurements for your benefits. Also, we will talk about perceived performance as another totally valid tool to manage performance of your projects. This workshop/lecture is about technology, but also about people and psychology. Intended Audience: Developers, Engineering Managers Mostly a presentation with practical examples

Video

Buzz and feedback

Here’s what was said about this presentation on social media.

I think @mishunov might want to give us a session about drawing as well. impressive drawings!#GitLabContribute pic.twitter.com/Rgg7HJCvo0
— Ammar Alakkad (@AmmarCodes) April 23, 2020
Great talk from @mishunov at #GitLabContribute today. It's a real shame we couldn't do it in person though.
— Sam Beckham (@samdbeckham) April 23, 2020

Pragmatic Web Performance

Link for this presentation:

HTML code for embedding:

Share on social media:

Video

Buzz and feedback