Now that we are aware of the different steps in the browser render pipeline, it's time to apply
this knowledge to the performance analysis process.
In this exercise you will learn the basics of black box performance auditing by using
the Performance Tab
of the Chrome Dev Tools.
Before you start, serve the application, open your browser and the dev tools.
Serve
ng serve --open
Your application should be served at
Open Dev Tools
F12
or Ctrl + Shift + I
Run a bootstrap performance analysis by either hitting Start profiling and reload page
or
Ctrl + Shift + E
.
After the report got analysed and is visible for you in the dev tools, search for the LCP
Core Web Vital in the Timings
pane.
Find out when it is happening and what the browser has identified as LCP
.
In order to identify the LCP
you might want to consider taking a look and the Screenshot
section
of the report.
To solve this task you will again need to take a look at the Screenshot
section.
[!NOTICE] REMEMBER to tick the checkbox
Screenshots
in thePerformance
tab if it's not already ticked.
Your fast task for this exercise will be to identify the point in time when the initial loading screen disappears.
If you have identified it, please go ahead and find the timing when the movie list data is visible.
Please mark the corresponding area between those two point in times and report
the values shown in the Summary
section.
Tip
You can use the screenshot section to fine-control the visible area.
To mark a section consider using Shift + Mouse1
+ dragging the mouse to select the area.
In this exercise you should use the search
functionality to search for the
time when the MovieListPageComponent
is getting bootstrapped.
Press Ctrl + F
(Mac: ⌘ CMD + F
) in order to conduct a search in the flame charts.
Find and report the point in time, when MovieListPageComponent
is getting bootstrapped.
Play around with CPU throttling.
Chrome should allow for an up to 20x CPU throttling
.
Depending on your hardware it makes sense to throttle your system while doing performance tests.
Otherwise, you'll never know how people with less powerful machines experience your app.
Keep that setting active for the next measurements. You can also always compare throttled vs. unthrottled measurements in the future.
Warning
setting throttling will constantly consume power from your machine. Chrome will simply put a ton of work on that thread. Make sure to disable throttling when not needed.
Start a performance recording for different interactions. Make sure to investigate always a single interaction at once. You want to create multiple recordings.
Start to measure the interaction time when switching the route via the sidebar.
You should be able to see the Interaction
pane, showing you the exact timings of the
pointer event.
Try to understand what's causing high interaction times here. You might find something suspicious that shouldn't happen on the click event :).
Optionally, analyze other interactions, and try to understand what you see there, such as:
- Typing in the search-bar
- Opening/closing the search-bar
- Hover in movie-card to trigger the tilt effect
- Navigating to a detail view
Go ahead and do another bootstrap recording as described in step 1 of this exercise. After the report was analysed and is visible for you, you'll notice that the dropdown menu in the top-bar of the Dev Tools is now enabled.
Switch between the recordings in order to get a feeling of how to compare multiple recordings in a single instance of the Chrome Dev Tools.
You'll most probably notice that the outcome of the measurements can be quite different at times. This is the reason why we always should do multiple recordings!
If you want to share your recording with others, the dev tools provide you with the feature to save an existing recording.
Hit the export button and save the current recording in the disk.
Great, now open your browser to a new empty tab and open a second instance of the
Chrome Dev Tools by hitting F12
or Ctrl + Shift + I
.
Now you can import your formerly saved recording in a new instance, thus having the ability to compare multiple recordings directly next to each other.
In this exercise you can now investigate the flame charts on your own and try to find suspicious tasks that potentially could be reduced, moved or erased completely.
Please note down your findings, so we can discuss them afterwards :-).