In the previous article, you’ve seen what Chrome DevTools protocol is and how Selenium 4 came up with its native support for Chrome DevTools protocol, etc. In this article, you’ll learn how to measure the performance metric of your web application, capture console errors, blocking certain requests the web application makes internally, emulate device viewports, etc.
Emulate Devices:
We can emulate different devices in the browser (i.e) different viewports that each device supports. This helps to validate how does the web application looks and behaves on different devices. Apple captures various device viewports here to adjust display sizes accordingly. Puppeteer also captures various device descriptors here that can also be used as a reference.
To override different viewports we need to fire the setDeviceMetricsOverride event under the Emulation domain. setDeviceMetricsOverride takes up arguments like width, height, scale, etc. Screen orientation is set as PortraitPrimary by default. Therefore, it can be overridden as LandscapePrimary to load applications in the landscape mode of a device. The setUserAgentOverride event under the Emulation domain overrides user agent to mobile safari.
Here’s the result of the code example above:
Performance Metrics:
The Internet gets heavier and heavier every year. If we check the state of the web we can see that a median page on mobile weights at about 1.5MB, with the majority of that being JavaScript and images. When a user navigates to a web page, they’re looking for visual feedback to reassure them that everything is working as expected. Therefore to understand it better there are metrics like First Paint, First Contentful Paint, First Meaningful Paint, Time to Interactive.
Below Screenshot of load timeline help you better visualize where the load metrics fit in the load experience:
getMetrics event in the Performance domain helps us capture all the performance metrics of application. Below code snippet in Selenium 4 helps us list down all the metrics of the TestProject web application.
Results of getMetrics event look like following:
Performance Monitor gets a real-time view of various aspects of a page’s load or runtime performance, including:
- CPU usage.
- JavaScript heap size.
- The total number of DOM nodes, JavaScript event listeners, documents, and frames on the page.
- Layouts and style recalculations per second.
If users are reporting that your app feels slow or janky, check the Performance Monitor for clues.
Console:
Web Developers log messages to the console to make sure that their JavaScript is working as expected. Web Developers often log these messages due to below reasons:
- Making sure that the code is executing in the right order.
- Inspecting the values of variables at a certain moment in time.
Google has a wonderful demo application to understand more about different types of console messages in the Chrome DevTools Console. We are going to use the same sample application to read all the console errors programmatically using DevTools events in the Log domain. entryAdded listener event in the Log domain captures all the messages logged in the browser console.
Emulate Timezone:
We can emulate different timezones on a web page using setTimezoneOverride event in the Emulation domain. Below is the sample code snippet that emulates different timezone on a web page:
Filter URLs:
We can intercept certain requests that the application makes and block it to understand how the application behaves. More importantly, applications come up with random popups of promotions or feedbacks when reading interesting articles, during an eCommerce purchase, etc. Ads are another important aspect where the ads popup spontaneously to gain users’ attention from the actual page content based on their browsing history. setBlockedURLs event in Network domain blocks any resource from loading. Below is the sample code snippet:
Sample code snippets are available here.