The Now Platform® Washington DC release is live. Watch now!

Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
shruti_tyagi
ServiceNow Employee
ServiceNow Employee

One of the most frustrating things you can encounter is a slow-loading page or form. Oftentimes when a page/form is loading slowly, it can be due to the server or client-side JavaScript. In this blog I will help you identify the source of the slowness and how to debug it.

Is the page loading slow on the server or client side?

One way to identify whether the slow page is due to client scripts or something on the server side is to look at the top of the page. While it is loading, if you see something like this that shows the running transaction time, that means it is the server that is taking its time:

load time.png

If you see that page is loaded but the browser is still spinning, that means something on the client side is slow. Once the page is finished loading, you can always check the response time on the clock at the bottom right corner to see the server and browser times. If the source of the slow load is on the client side, Chrome dev tools can be used to pinpoint the slow JavaScript. Let's take a closer look at how to do this.

Troubleshooting slow client scripts

Let's take an example of an incident form. When I try to load incident form it takes ~2.5 seconds, out of which ~1.5 seconds is browser time and ~800 ms server time. This is not that bad, but let's see if we can optimize it further.

This is the response time that displays when I click on the clock icon at the bottom right corner:

load time 2.png

Now let's open the Chrome developer tools on the incident form for more debugging.

How to open Chrome developer tools to debug client-side slowness

There are two methods to opening Chrome dev tools:

Option 1: When you are on the form you want to debug, right-click the form and do inspect.

Option 2: In the Chrome menu, go to More Tools > Developer Tools. Depending on which version of Chrome you are on, it may be in a different location but usually clicking the wrench icon in the upper right will get you to this option.

Use Chrome to continue debugging

  1. In the developer tool, click the Performance panel and click the record button to capture a new recording.debugging step 1.png
  2. While recording the transaction, reload the form again. Once the form is loaded, stop recording. This will capture the screenshot of the performance of transaction. The summary contains a number of tabs, and the first tab displays a breakdown of the time. In this case, most of the time was while rendering scripting. Based on this we know there is some Javascript that is causing   slowness.
    debugging step 2.png
  3. Now, let's find out exactly which client script is slow. Click on third tab labeled Call Tree. Let's sort it on Total Time as I am interested in seeing the one with maximum time. I can see that the Parse HTML Activity took ~60% of time, so let's drill down into this activity to see what it has. Keep clicking in this activity until you find something interesting.debugging step 3.png
  4. I stopped drilling down when I saw these functions: onLoad_df2c8a16db43b2002f1e596e5e9619b3. To determine exactly what this is, click on the link directly across the first onLoad_df2c8a16db43b2002f1e596e5e9619b3 function to go to the source code. In this case it redirected me to this line:

    addRenderEventLogged(onLoad_df2c8a16db43b2002f1e596e5e9619b3, 'onLoad VIP Assignment Group','onLoad_df2c8a16db43b2002f1e596e5e9619b3');g_event_handlers_onLoad['onLoad_df2c8a16db43b2002f1e596e5e9619b3'] = 'VIP Assignment Group';g_event_handler_ids['onLoad_df2c8a16db43b2002f1e596e5e9619b3'] = 'f94ce56adb5efe002f1e596e5e96193c';function onLoad_132c8a16db43b2002f1e596e5e9619b4() {

    var caller = g_form.getReference('caller_id');

    if (caller.vip == 'true')

            g_form.setValue('location', caller.location);

}

5. This looks like a client script to me, so I will search this client script in my instance. To look for the client script:

    • Use sys_id (['onLoad_df2c8a16db43b2002f1e596e5e9619b3'] = 'f94ce56adb5efe002f1e596e5e96193c')
    • Use the script contains we are seeing in code
    • This looks like a name: onLoad VIP Assignment Group'

I am able to find the client script using the sys_id, its On Load client script (VIP Assignment Group) on the Incident table.

6. Let's check the script in the client script. Here is my code:

debugging step 6.png

Looks like a bad code - we are doing a server call from the client script to set the assignment group. To avoid the server call add display value, I will rewrite the code as per Client Script Best Practices by jake.gillespie. Here is my updated code:

debugging step 6-2.png

As we can see in my rewritten code above, there are three client scripts that were slow. I fixed all three of them using the same steps (1 through 6) and now my incident form is loading 1.2 seconds, out of which browser time is dropped down to 130 ms. Not bad.

In this example it was the client script that was causing slowness. Please note the client-side script is also coming from UI scripts or the script sections in UI Policies. Bottom line here is if you have a slow form load due to client-side scripting, take a moment to debug slowness using the browser performance tool.

Note: This example assumes that you are using the Chrome browser, but the other browsers have JavaScript consoles. I recommend you use Chrome when it comes to debugging and troubleshooting as it is pretty simple and easy to use. Also please note, I am on Chrome Version 58. If you are not on latest version of Chrome, use Timeline and Profile Panel as they are similar to the performance panel we just used.

15 Comments