How to measure the time taken for screen transitions

[bonsai]

I'm planning to measure the time taken for screen transitions during non-functional requirements testing.

I considered looking at the "LCP" value in the browser's developer tools performance, but I couldn't measure it when transitioning screens on the portal.

It seems that LCP cannot be measured because only the display on the widget changes.

Is there a better way?

The targets for measurement are as follows:
* From login to the portal's top screen
* From the portal's top screen to the catalog item input form
* From a platform module to the list screen
* From the platform list to the record form screen
* Screen transition when clicking a platform link set on the portal

[Naveen20]

LCP doesn't work well for Service Portal screen transitions. The portal is an AngularJS single-page application (SPA), so navigating between pages only swaps widget content within the same shell. The browser doesn't treat that as a new page load, which is why LCP doesn't fire again after the initial load.

Here are approaches that work better for each of your scenarios:

For Service Portal transitions (top screen, catalog item, portal links):

The most reliable method is the User Timing API (performance.mark / performance.measure). You can place performance.mark('transitionStart') in the widget client script that triggers the navigation, and performance.mark('transitionEnd') in the destination widget's $onInit or link function once rendering is complete. Then call performance.measure('screenTransition', 'transitionStart', 'transitionEnd') to get the duration. You can read results via performance.getEntriesByName('screenTransition') in the console.

Alternatively, open DevTools Network tab, clear it, then trigger the navigation. The waterfall from the first XHR fired to the last response received gives you a good proxy for server + data load time. It won't capture client-side rendering, but combined with the Performance panel's "Timings" lane it gets you close.

For Platform UI transitions (module to list, list to form):

These are full page navigations, so standard browser metrics work. The Navigation Timing API is straightforward — run this in the console after the page loads:

var t = performance.timing;
console.log('Total load: ' + (t.loadEventEnd - t.navigationStart) + 'ms');
console.log('Server response: ' + (t.responseEnd - t.requestStart) + 'ms');
console.log('DOM rendering: ' + (t.domComplete - t.domLoading) + 'ms');

Also, ServiceNow has a built-in transaction timing feature. Set the system property glide.ui.transaction_timing to true — this displays server-side round-trip time in the banner/footer area for each page load. It's useful for isolating server processing time vs. client rendering time.

For login → portal top screen:

This is a cross-origin redirect flow (login.do → portal), so the Navigation Timing API on the portal landing page captures the full sequence from navigationStart. The performance.timing approach above works here since it's a real full-page load.

General tips for consistent measurement:

Use a clean browser profile with cache disabled (DevTools → Network → "Disable cache") for repeatable results. Run each transition multiple times and average. If you want to automate this, consider writing an Automated Test Framework (ATF) test with custom steps that log timestamps, or a simple Selenium/Playwright script that injects performance.now() calls around each navigation and collects the results.