To start, open up the Edge Dev Tools and choose the “Performance” tab, which you’ll find next to the “Network” tab.
Use the circle-icon to start a recording and load up the troubled page.
You need to let the recording run long enough for everything to execute and you may need to ensure the behaviour you want to measure has been triggered if it isn’t part of the page load lifecycle (i.e. if the “calculation” feature is slow, you’ll need to interact with the page to make a calculation happen).
When you’re ready, hit the stop button to complete the recording. Now the fun happens.
The quickest way to find performance issues
When a session has been recorded, you’ll be presented with some cool charts and visualisations. Ignore or of that for a minute and hit the “Bottom-Up” tab on the lower panel. It’s right above the summary donut-chart.
As soon as you have the Bottom-Up view open, order it by “Total Time Descending” (just click on the headers to order the table) so you can see the top-level functions that are spending the most money. You can then expand the items to see what’s happening inside.
You will have two loose categories of speed killers.
- The activities that call so many things, they take a great deal of time despite nothing inside being too slow
- The activities that call something that is obviously a hot-spot of slow
Both the “Total Time” and “Self Time” ordering are useful. Total Time will reveal the entry points to slow areas of code, whereas Self Time will show low level expensive code. It is best to look through both orderings to work out where your optimisation will have the greatest impact.
Also, you’re going to need to be prepared to ditch some third-party code. If you can’t get a pull request into the project to speed it up, you might need to bin it and use something else.