You inherit a production Incident form that's taking 8-10 seconds to load.

Setting the Stage

An 8-10 second load time on a relatively simple form suggests the issue isn't form complexity alone. The out-of-the-box Incident form loads in ~2 seconds, and anything over 3-4 seconds is considered slow by users. With only 45 fields and small related lists, you're likely dealing with inefficient scripts, unnecessary synchronous operations, or poorly optimized business rules rather than data volume.

Diagnostic Approach (What Makes This Senior)

Phase 1: Isolate the Layer - First, determine where time is spent: network latency, server processing, or browser rendering. Open browser DevTools (Network and Performance tabs) to measure server response time versus client-side script execution. If the server responds in 1 second but total load is 8 seconds, the problem is client-side scripts or related list rendering.

Phase 2: Methodical Elimination - Don't randomly remove elements. Instead: (1) Disable all client scripts and UI policies, reload, and note the improvement; (2) Re-enable them one category at a time; (3) Check if related lists are set to load 'on demand' or 'after form loads'—switching to on-demand can dramatically reduce initial load time. A user reported 20-30 second related list loads that improved by deferring their initialization.

Phase 3: Deep Inspection - Check for: (a) Synchronous GlideRecord queries in onLoad scripts that block the browser; (b) UI policies with complex conditions evaluated on every field; (c) Reference fields with large choice lists lacking filters; (d) Business rules executing on form load when they should only run on update/insert; (e) Multiple onLoad scripts doing similar work instead of consolidated logic.

The Solution

// PROBLEM: Synchronous blocking query in onLoad script
function onLoad() {
  var caller = g_form.getValue('caller_id');
  var grCaller = new GlideRecord('sys_user');
  grCaller.addQuery('sys_id', caller);
  grCaller.query(); // BLOCKS - synchronous
  if (grCaller.next()) {
    g_form.setValue('assignment_group', grCaller.assignment_group);
  }
}
// SOLUTION: Asynchronous approach with GlideAjax
function onLoad() {
  var caller = g_form.getValue('caller_id');
  if (caller) {
    var ga = new GlideAjax('GetCallerInfo');
    ga.addParam('sysparm_caller_id', caller);
    ga.getXMLAnswer(function(answer) {
      g_form.setValue('assignment_group', answer);
    });
  }
}
// Server-side script processor (GetCallerInfo)
var caller_id = this.getParameter('sysparm_caller_id');
var gr = new GlideRecord('sys_user');
gr.get(caller_id);
answer = gr.assignment_group.toString();

Senior Considerations

• Root Cause vs. Symptom - A 'slow form' complaint could originate from network issues, browser extensions, or instance performance. Separate diagnosis from solution. Don't optimize scripts if the real issue is a missing database index on a related list query.
• Trade-offs Matter - Deferring related list loads improves perceived performance but delays user access to that data. Document the choice: is 3-second form + 2-second related list load better UX than 8-second complete load? Depends on user workflow.
• Avoid Premature Optimization - A great answer includes asking: 'Is this actually a problem for users, or is it acceptable?' If 80% of users are satisfied, optimizing further wastes effort. Use performance monitoring to establish baselines.
• Caching Considerations - Implementing client-side caching for reference data (e.g., assignment groups) can help, but requires cache invalidation strategy. Too short = unnecessary queries; too long = stale data. This is a production risk.
• Browser and Network Variability - Internet Explorer performs 3x slower than Chrome. Users on slow networks or VPNs may see different times. Document whether the 8-second complaint is widespread or isolated to specific users/locations.
• Monitoring is Ongoing - Set up a performance dashboard tracking form load times by form, user location, and time of day. Slow form loads often spike during peak hours due to instance load, not form design.
• Business Rule Audit - Display business rules execute on form load and can be expensive. Verify none are doing unnecessary queries. Move calculation logic to server-side where possible.
• Production Impact - Before deploying optimizations, test on a clone of production data. A change that improves load time with 10 related list records might fail with 10,000 records.