What Sonar Does: Flags the heavy hitters
Sonar surfaces which scripts run on which record types, how long they typically take, and which ones are the biggest contributors to slow saves, so you're not guessing which script to open first.
NetSuite Performance Optimization
Increase Page Speed & Load Times
Slow record loads, laggy saves, and sluggish searches usually trace back to the same source: User event scripts that have piled up over years of NetSuite use, whether written by your team or installed through a bundle.
Anchor Group uses Sonar, our own audit tool built for NetSuite environments, to scan your account and pinpoint exactly which scripts are dragging down performance.
From there, our NetSuite optimization and development team fixes them: retiring the ones you no longer need, rewriting the ones worth keeping to run more efficiently, or moving them to run asynchronously so they never hold up a save.
The Problem
Why NetSuite Gets Slower the Longer You Use It
NetSuite doesn't ship slow. It gets slow. Every workflow, every integration, every "quick script" a past developer added to automate a task adds another user event script to the record. Individually, each one might run in a fraction of a second. Stacked together on a heavily used record type like Sales Order or Item Fulfillment, they add up to real, felt delays every time someone clicks Save.
Scripts pile up over years
Most NetSuite accounts have been live for 3, 5, sometimes 10+ years. Scripts get added for one-off projects and rarely get removed, even after the business process they supported has changed.
Bundles quietly add dozens more
Every bundle you install can bring its own set of scripts along with it, sometimes dozens at once. A single feature add-on can multiply your script count overnight without anyone realizing it.
Every save waits in line
Standard (synchronous) user event scripts run in a queue before a record is allowed to finish saving. If a dozen scripts fire on beforeSubmit and afterSubmit, the user waits for all of them, every time.
Nobody knows what's safe to touch
Without documentation, it's hard to know which scripts are load-bearing and which were built for a process that no longer exists. That uncertainty is usually why nothing gets cleaned up.
Biggest hidden source of script bloat
Installing a bundle isn't the same as adding one script; it's often adding a whole package of them. This applies to bundles published by Oracle itself as well as bundles from third-party software providers whose point solutions integrate with NetSuite. Many NetSuite partners build their integrations as bundles specifically so a customer can install a working point solution quickly, but that speed comes with a tradeoff: you inherit every script in the bundle, whether or not your business ends up using every feature it enables. A few years and a handful of bundles later, it's common for an account to be running scripts nobody on the current team even knew existed.
Step One: Diagnose
Sonar & NetSuite APM Find Culprits in Minutes, Not Weeks
Sonar is an Anchor Group solution built specifically to audit a NetSuite environment. Instead of manually opening every script deployment in your account and guessing at its impact, Sonar scans your account and identifies which user event scripts are actually contributing to slow page loads and save times, along with the reasons why, so you know which scripts are worth reviewing first. We pair it with Oracle NetSuite's own Application Performance Management (APM) SuiteApp for the account-wide performance data that confirms and quantifies what Sonar finds.
Origin Tracing: Traces scripts back to their source
Sonar identifies whether a slow script is custom code your team owns, part of an Oracle-owned bundle, or came bundled with a third-party point solution, so you know exactly who to talk to before touching it.
What You Get: A fast, prioritized audit
Rather than a multi-week manual code review, you get a prioritized list of scripts worth reviewing, letting your team (or ours) focus effort on the handful of scripts actually causing the slowdown.
The audit is just the starting point
Once Sonar identifies a script that's slowing things down, the next question is always the same: is this script still needed at all? A surprising number of flagged scripts turn out to support a process the business abandoned years ago, and can simply be retired.
[ Anchor Group's Layer ]
Sonar: script-level judgment
Sonar tells you which scripts are worth reviewing and why: which ones are custom code, which came bundled with an install, and which look like candidates for retirement, consolidation, or a move to an Event Subscriber script.
[ NetSuite's Layer ]
APM: account-wide performance data
Anchor Group also runs Oracle NetSuite's own Application Performance Management (APM) SuiteApp alongside Sonar. APM is a free, Oracle-built tool that gives account-wide visibility into page load times, script execution timing, saved search performance, and SuiteCloud processor queues, through its Performance Health Dashboard, Page Time Summary, SuiteScript Analysis, and SuiteCloud Processors Monitor tools. Where Sonar zeros in on which scripts to act on, APM gives us the underlying system data to confirm the impact of a fix and track performance over time.
Step Two: Decide
Evaluate Each Script: Retire, Rewrite, or Re-Platform
Once Sonar hands over the list of scripts that are actually contributing to slow load times, Anchor Group's NetSuite developers evaluate each one individually. Every script lands in one of three buckets.
Retire it
If the script supports a process the business no longer runs, or duplicates functionality NetSuite now handles natively, we recommend removing it entirely. This is the fastest and cheapest performance win available, and it's more common than most teams expect.
Consolidate and rewrite it
If the logic is still needed, we look at whether it can be combined with other scripts on the same record and rewritten to run more efficiently. Multiple scripts making redundant searches, loading the same record twice, or looping inefficiently are common patterns we clean up. Fewer, tighter scripts mean less overhead on every save.
Move it to an Event Subscriber script
If the logic needs to stay largely as-is but doesn't need to finish before the user moves on, we migrate it to NetSuite's new Event Subscriber script type, introduced in the 2026.2 release. This is often the single biggest speed win available for scripts that can't simply be deleted.
A note on bundle-owned scripts
When a slow script belongs to an Oracle bundle or a third-party partner's bundle rather than your own custom code, the fix looks a little different. We can't rewrite code we don't own, so for those scripts we work with you to confirm whether the underlying feature is still in active use, coordinate directly with the bundle provider on configuration or performance settings, or, where the functionality has been replaced by something else, safely uninstall the bundle and every script that came with it.
The 2026.2 Advantage
Meet the Event Subscriber Script: NetSuite's New Way to Run Logic Asynchronously
Historically, a NetSuite user event script had to finish running before the record was allowed to finish saving. If a beforeSubmit or afterSubmit script called an external API, ran a heavy saved search, or updated related records, the user sat and waited for every step to complete before they could move on.
NetSuite's 2026.2 release introduced the Event Subscriber script type, a new SuiteScript 2.1 script built specifically to run follow-up processing after a record event, like a create, update, or delete, without holding up the record operation itself. Because it runs after the originating transaction has already completed, the person clicking Save never waits on it.
50–80% of the time a user event script fires in a given account
Anchor Group finds the logic inside it is actually a strong candidate to run as an Event Subscriber script instead. That's a wide swath of everyday save-time delay that's addressable without changing a single line of business logic, just where and when it runs.
Not every script is a candidate
Anything that validates data or needs to block a save if a condition isn't met still needs to run synchronously as a standard user event script. But because so much of a typical user event's logic doesn't actually need to finish before the save, re-platforming that logic onto an Event Subscriber script is often the single largest performance improvement available on a given record type: the business logic doesn't change, only when and how it runs, and it gets a much longer runtime window in the process.
Why Anchor Group
Diagnosis and Development, Handled Together
A lot of firms can tell you that your scripts are slow. Fewer can actually go in, evaluate what each one does, and fix it without breaking the business processes that depend on it. Anchor Group pairs the Sonar audit and NetSuite APM data with hands-on NetSuite development, so the same team that finds the problem is the one that solves it.
We test before we touch
Every change is validated in a sandbox against your real business processes before it ever touches production, so a performance fix never becomes a functionality regression.
-
We document what we find
You get a clear record of which scripts were retired, rewritten, or converted, and why, so the next developer who touches your account isn't starting from zero.
-
We stay in your corner after
Performance work isn't one-and-done. As new scripts get added over time, Anchor Group's ongoing NetSuite support and optimization services keep your account from drifting back to where it started.
What Our Customers Say
See what's actually slowing your NetSuite account down.
Run a Sonar audit and get a prioritized list of the scripts worth fixing first, in a matter of minutes, not weeks.
Frequently Asked Questions
NetSuite Page Speed & Script Performance FAQs
The questions we hear most from admins and NetSuite users dealing with slow record saves, sluggish dashboards, and scripts that seem to run forever.
Slow record saves almost always trace back to what's running on that record type, not the NetSuite platform itself. Every standard user event script attached to a record runs synchronously, meaning the record isn't considered saved until every beforeSubmit and afterSubmit script finishes. On a heavily customized record type like Sales Order or Item Fulfillment, it's common to have a dozen or more scripts stacked up, each adding its own runtime to every single save.
There's no hard cap, which is exactly why script bloat sneaks up on accounts over time. NetSuite will happily run as many user event scripts as are deployed to a record, one after another in the order shown on the Scripted Records page. Performance degrades gradually as scripts accumulate, so by the time it's noticeable, an account often has years of scripts layered on a single record type with no one script being the obvious culprit.
Yes, and it's one of the most overlooked causes of NetSuite performance issues. Installing a bundle isn't the same as adding one script; a single Oracle or third-party partner bundle can quietly install dozens of scripts at once to support a point solution like a tax engine, EDI connector, or shipping integration. Those scripts count toward the total running on a record whether or not the business ends up using every feature the bundle enables.
This error means a script ran out of its allotted governance units before it finished executing; NetSuite caps how many units a script can consume (1,000 for a standard user event script, for example) to keep any one script from monopolizing shared server resources. It's usually a sign of an inefficient pattern, like running a search or loading a record inside a loop, rather than a NetSuite limitation. Fixing the underlying script logic almost always resolves it for good, rather than just pushing the failure further down the road.
In our experience, it's rarely the core platform. NetSuite performance problems generally come from one of three places: server-side (your scripts, workflows, and saved searches), network (the connection between your browser and NetSuite's data center), or client-side (your browser, extensions, and machine). Most of the recurring, account-wide slowness we're brought in to fix is server-side, which is exactly what a script audit is built to find.