Really solid empirical approach — and your observations are actually correct in several ways. The "client-side GlideRecord is inefficient" claim is true but often poorly explained. Let me break down exactly what's happening and where the nuance lies.
Why the Claim Exists — The Real Reasons
1. No Field Restriction by Default (The Main Offender)
When most developers use client-side GlideRecord, they write it like this:
javascript
var g = new GlideRecord("incident");
g.query(function(r) {
while (r.next()) {
console.log(r.getValue("number"));
}
});
With no setDisplayFields() or setFields(), ServiceNow returns the entire record — every field, every value — across the wire. For incident that can be 100+ fields per row. You noticed this yourself when testing as admin — the payload size kills performance even if the server query is fast.
Your version with setDisplayFields(["number"]) sidesteps this entirely. Most developers don't know or don't bother doing this, which is why the blanket warning exists.
2. No Server-Side Business Logic Control
With a Script Include (GlideAjax), you control exactly what runs server-side:
javascript
// Server controls the query, fields, filtering, limits — all opaque to client
var _ = new GlideRecordSecure("incident");
_.addEncodedQuery("active=true^priority=1");
_.setLimit(50);
With client-side GlideRecord, the client dictates the query to the server. This means:
- Users can open DevTools and modify the query parameters before they're sent
- There's no server-side validation of what's being requested
- A curious user can change
setLimit(50) to setLimit(9999) trivially
For non-sensitive data this is fine. For anything security-sensitive, it's a problem.
3. ACL Evaluation Overhead (What You Observed)
Your 4-second GlideAjax result on first run vs faster GlideRecord — this is likely because GlideRecordSecure in your Script Include evaluates field-level and row-level ACLs server-side for every record, every field. Client GlideRecord also does ACL checks but the payload restriction via setDisplayFields means fewer ACLs to evaluate.
The caching speedup you noticed on consecutive runs is exactly this — ACL decisions get cached per session.
4. The sysparm_processor=AJAXGlideRecord Detail You Caught
You're right that client GlideRecord is just a GlideAjax wrapper under the hood. This means it has the same round-trip cost as GlideAjax — the difference is just in what the server does with the request. There's no magic efficiency difference at the transport layer.
Where Your Approach Actually Holds Up
Your instinct about Script Includes is valid and the claim is overstated in these cases:
| Situation |
Client GlideRecord Fine? |
Fetching a small, known field set with setDisplayFields |
✅ Yes |
| Non-sensitive data, no security concern |
✅ Yes |
| Simple one-off lookups where a Script Include feels like overkill |
✅ Yes |
| Large result sets with no field restriction |
❌ No |
| Security-sensitive queries |
❌ No |
| Complex server-side logic / joins / aggregates |
❌ Script Include wins |
The One Thing You May Be Overlooking
The setDisplayFields method is not documented officially for client-side GlideRecord and behaves differently across contexts (Service Portal vs platform UI). You noticed Portal GlideRecord doesn't have it — that inconsistency is a real maintenance risk. If a future ServiceNow release changes that undocumented behavior, your optimized client GlideRecord silently becomes the unoptimized version again, and you'd have no warning.
A Script Include is explicit and version-stable by comparison.
Bottom Line
The inefficiency claim is really about how most developers use client GlideRecord, not the API itself. Your disciplined use of setDisplayFields and setLimit produces a reasonable result. The legitimate reasons to still prefer Script Includes are security control, server-side logic complexity, and cross-context consistency — not raw performance when the client GlideRecord is used carefully.
Your empirical instinct was right to question the blanket claim.
