SummerAcademy on Debugging — 2.1.4 Browsers
In a typical app architecture these days, the browser is the most important environment for the front end. While there is a lot of effort to standardize the way browsers act, different engines react sometimes totally different. So make sure you know the operation conditions of your application (aka which browsers, versions, OSes, resolutions, memory, CPU — see 2.2.9) and test accordingly.
You should have a good idea of how browsers work internally to understand sources of performance issues and how frameworks like React or Vue work internally. We found this quite helpful. Also, check out the companion video.
Browsers these days come equipped with extremely good and helpful tools. We will take Google Chrome as our example here but expect to find similar features in other browsers, too. A special honorable mention to Mozilla and Microsoft Edge.
The Developer Tools can be found in the “More tools — Developer Tools” or by Ctrl-Shift-I (Cmd-Option-I on Mac). The functionality deserves its own book and can even be extended using plugins (for React as an example). Make sure to have the extensions covering your stack installed (see Google’s Webstore).
Side note: A very nice feature is hidden behind this icon in Chrome:
Here you can select how the website looks rendered on different devices or resolutions, reacts on turning, or throttle the data connection. This is an extremely useful tool.
Debuggers
There is a built-in debugger within the developer tools. We made a video to show the most basic functionality here — also have a look at 2.1.9 Debuggers.
debugger- If you place the expressiondebugger;somewhere in your code, Chrome will stop there and open the debugger. But pre-compilers like Babel might not accept it.- When the flow hits a breakpoint, the console can be used to interact with the code like setting variables. Obviously,
console.log()is one of the workhorses to display information during the execution but there is more (see here) console.table()helps to display arrays of objects in a nice format.console.trace('Header')outputs a stack trace (see here for details). A stack trace provides a list of subroutine calls.
Performance
The perceived performance of your app is of extreme importance. There are some aspects that we want to iterate:
- Your application architecture should be resilient against small performance issues within any element or layer. It should always fail gracefully (so no time out errors bubbling into the user’s face).
- Make sure to have performance metrics that you can test (best and maybe the only way to do this objectively is automate it)
- The performance depends on external factors such as network bandwidth, memory, CPU, browser type, browser version, which can even variate during the runtime of your app. Good if you have minimal requirements defined for the runtime environment.
- There are actually three distinct phases where performance can be optimized: Loading performance (how long does it take until I see something and how long until I can interact), rendering performance (how long does it take for changes to be reflected), write back performance (aka calling APIs and make sure the data is synchronized). See the Google Course on Performance in the resources as a good intro.
- Think about the render-pipeline as a change in the DOM or CSS can lead to massive rerendering efforts. Normally, frameworks such as React or Vue to the heavy lifting for you, but you need to stay within their design patterns.
- Use the Performance and the Network tab in the developer tools to learn about the performance bottlenecks in your app.
console.time('XYZ')andconsole.timeEnd('XYZ')to measure the time needed between two steps
Key Take-Aways
Get to know your system these days means knowing a good deal of how browsers work. They are pretty nifty tools now and offer a lot of good that can help during debugging. Check how the rendering works on different device resolutions on network circumstances.
