1 of 19

A Different Vue into Web Performance

Abhijeet Prasad

Software Engineer at Sentry (https://sentry.io)

2 of 19

Agenda

How to identify problems

Operations
Factors that affect performance
Influencing factors

Measuring data

Assets (HTML/CSS/JS)
Web Vitals
Browser APIs

What we do at Sentry

3 of 19

How can we identify performance problems?

4 of 19

What are the operations we care about?

Render a page

Pageload
Route changes (navigation)

User Interactions

Keyboard/Mouse
Forms
Animations

5 of 19

Inputs

User Hardware

Network Conditions

Backend

Browser

Developer

App Type

Browser Cache

User

CDN/Server Cache

Frontend App Performance

6 of 19

Performance is all about people

Front-end operations are fundamentally user based
How user’s use your app affects what we care about
Response times are affected by human perception [1]

0.1 seconds -> instant reaction
1.0 seconds -> user flow of thought
10 seconds -> keeping user’s attention

[1] https://www.nngroup.com/articles/response-times-3-important-limits/

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.
1.0 second is about the limit for the user's flow 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.
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 finish, 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 not know what to expect.

0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it's selected. Ideally, this would also be the response time for sorting the column — if so, users would feel that they are sorting the table. (As opposed to feeling that they are ordering the computer to do the sorting for them.)

1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2–1.0 seconds does mean that users notice the delay and thus feel the computer is "working" on the command, as opposed to having the command be a direct effect of the users' actions. Example: If sorting a table according to the selected column can't be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of "flow" in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.

10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user's work, for example when switching tasks.

7 of 19

Get the data

8 of 19

Start measuring stuff

Quantitative is the best, but it's actually fine if it's qualitative
Gives you an indication of problem

Important to understand relative performance
Easier to understand possible solutions

Guard against regressions
Cardinality also matters here (network, hardware, user type)

9 of 19

Measuring asset size

Javascript

https://github.com/ai/size-limit
Webpack bundle analyzer

CSS
Images/Video/Audio

https://featurepolicy.info/policies/unoptimized-images

Fonts
Other stuff (JSON)

10 of 19

Web Vitals

First Paint (FP)

measures the amount of time the first pixel takes to appear in the viewport, rendering any visual change from what was previously displayed. This may be in any form from the document object model (DOM), such as background color, canvas, or image. FP helps developers understand if anything unexpected is happening to render the page.

First Contentful Paint (FCP)

measures the time for the first content to render in the viewport. This may be in any form from the document object model (DOM), such as images, SVGs, or text blocks. FCP frequently overlaps with First Paint (FP). FCP helps developers understand how long it takes before the user sees any content change on the page.

Largest Contentful Paint (LCP)

measures the render time for the largest content to appear in the viewport. This may be in any form from the document object model (DOM), such as images, SVGs, or text blocks. It is the largest pixel area in the viewport, thus most visually defining. LCP helps developers understand how long it takes before the user sees the main content on the page.

First Input Delay (FID)

measures the response time when the user tries to interact with the viewport. Actions may include clicking a button, link, or other custom Javascript controller. FID provides critical data on successful or unsuccessful interactions on an application page.

Cumulative Layout Shift (CLS)

is the sum of individual layout shift scores for every unexpected element shift during the rendering process. Imagine navigating to an article and trying to click a link before the page finishes loading. Before your cursor even gets there, the link may have shifted down due to an image rendering. Rather than using duration for this Web Vital, the CLS score represents the extent of the disruptive and visually unstable shifts.

11 of 19

Google Lighthouse

12 of 19

https://github.com/GoogleChrome/web-vitals/

13 of 19

Other metrics

Time to First Byte (TTFB)
Time to Interactive (TTI)
Total blocking time (TBT)

Long Spans API

JS Parse time

The TTI metric measures the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly.

TTI can be calculated without users. It measures how long it takes your page to be ready for interaction. It’s based on how long the main JavaScript thread is tied up, and how soon it would have the capacity to deal with user interaction.�
FID requires users to be calculated. It measures the actual amount of delay real users experience when trying to interact with your page. It’s not just when the page could respond to a user’s input, but a measurement of what actually happens when someone interacts with the page—say by clicking or touching a button.

The Total Blocking Time (TBT) metric measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness.

The main thread is considered "blocked" any time there's a Long Task—a task that runs on the main thread for more than 50 milliseconds (ms). We say the main thread is "blocked" because the browser cannot interrupt a task that's in progress. So in the event that a user does interact with the page in the middle of a long task, the browser must wait for the task to finish before it can respond.

Time To First Byte (TTFB)

measures the time that it takes for a user's browser to receive the first byte of page content. TTFB helps developers understand whether their slowness is caused by the initial response or instead due to render-blocking content.

14 of 19

Distributions matter

Use histograms and percentiles
Unimodal vs. bimodal
Averages don’t tell the whole story
Cardinality!

15 of 19

Watch out for LCP

LCP is a heuristic, might pick an element that is not important
Element Timing API
Vue lifecycles

16 of 19

Browser APIs

PerformanceEntry

Resources
Fetch/XHR calls
Marks and measures

17 of 19

What we do at Sentry

18 of 19

Thank you!

19 of 19

https://vueschool.io/courses/application-monitoring-in-vue-js-with-sentry