What Is the Correct Order of Factors That Most Negatively Impact Form Performance in ServiceNow?

[VianyNidamanuri]

Hi Community,

I’m trying to clearly understand which elements slow down form performance the most in ServiceNow. I created an ordered list based on my experience, but I'm not completely sure about the accuracy.

I'd like to get validation from the community or hear your insights on whether this order makes sense—or if something should be moved up/down.

My Current Understanding of What Impacts Form Performance (from highest to lowest impact):

1️⃣ Client Scripts
Especially heavy onLoad / onChange scripts, synchronous logic, DOM manipulation, or loops.

2️⃣ UI Policies & UI Policy Scripts
Multiple conditions or scripted actions adding client‑side processing overhead.

3️⃣ Business Rules
Particularly synchronous/Before rules that affect form load or record submission.

4️⃣ Reference Qualifiers
Complex dynamic queries or dependent lookups that delay field population.

5️⃣ Form Size (number of fields/sections/tabs)
More UI components = more rendering time.

6️⃣ Related Lists
Large data sets or multiple related lists increasing the time before the form fully loads.

7️⃣ Client-side UI Actions
Buttons with inefficient scripts or synchronous logic.

Is this order correct?
If not, how would you reorder these elements based on your experience with form performance impacts?

Any best practices or real-world examples are also appreciated!

 

[Matthew_13]

Hi Buddy,

 Your list is on the right track 😁, but in practice the biggest impact on form performance usually comes from how much data the form has to retrieve and render first, and then from what runs on the client during load. Server logic like business rules tends to affect save/submit more than the initial form load.

Based on my experience a more typical order of impact would look like this (highest to lowest):

1. Related lists – multiple lists or large datasets can significantly delay form load because of additional queries, ACL checks, and rendering.

2. Reference qualifiers – especially dynamic/scripted ones that trigger extra lookups during load and field interaction.

3. Client scripts – heavy onLoad logic, synchronous calls, DOM manipulation, and loops can noticeably slow the form.

4. UI policies and UI policy scripts – generally lightweight, but large numbers with complex conditions add up.

5. Form size – more fields, sections, and tabs increase rendering time and trigger more policies and scripts.

6. Business rules – mainly affect save/submit; display rules can influence load but are usually less impactful than client-side processing and data retrieval.

7. Client-side UI actions – typically minimal impact unless they run heavy logic on load.

Also worth noting: in many real-world cases, the biggest performance issues come from things not always listed, such as heavy display business rules, GlideAjax calls during form load, poorly indexed fields used in qualifiers, and large activity/related data being rendered.

So your thinking is solid! just slightly reordered around data retrieval first, then client execution, then server-side logic.

@VianyNidamanuri - If help you answer, Please mark Solution Accepted and Thumbs Up

[SohamTipnis]

Hi @VianyNidamanuri,

You may add Script Include and flow design to your list, as per my experience.

If you find my answer useful, please mark it as Helpful and Correct ‌😊

Regards,
Soham Tipnis
ServiceNow Developer ||  Technical Consultant
LinkedIn: www.linkedin.com/in/sohamtipnis10