SuiteScript Performance: A Practical Optimization Guide

Start with evidence. A script that feels slow may be waiting on a search, loading the same record many times, or doing work that belongs in a different script type. NetSuite's execution logs and SuiteScript governance data help you tell those cases apart.

Treat governance as an API contract

NetSuite assigns a usage limit to each script type and a usage cost to many API calls. The values differ by script type, API, and record category. Do not rely on a copied summary table. Check Oracle's current SuiteScript governance and limits and the governance entry on the API method you use.

You can inspect the remaining allowance during execution:

const script = runtime.getCurrentScript();
log.debug({ title: 'Remaining usage', details: script.getRemainingUsage() });

Log at useful boundaries, such as before and after a batch. Logging every row can create noise and add work of its own.

Reduce record and search work

A few changes often make scripts easier to operate:

• Request only the search columns the task needs.
• Put selective filters in the search instead of filtering a large result set in JavaScript.
• Avoid loading the same record inside nested loops.
• Use a field lookup when you only need a few body fields, if that API supports the record and fields involved.
• Combine related writes when doing so preserves validation and business rules.

These are hypotheses, not promised speedups. Measure the script with representative account data before and after each change.

For large result sets, use the paging method documented for Search.runPaged(). Oracle warns that paged searches need a unique, unambiguous sort order. Without one, rows can be duplicated or omitted while paging.

Pick the right script type

A user event or client script sits on an interactive path, so keep its work short. Move non-interactive processing to a scheduled or Map/Reduce script when the business process allows it.

Map/Reduce is useful when work can be split into independent keys. NetSuite handles yielding and parallel stages, but the design still matters. Keep each key idempotent where possible, record failures with enough context to retry them, and review the limits for each stage in Oracle's Map/Reduce governance.

Do not move a small task to Map/Reduce just because it is available. Scheduling and stage overhead can make a simple scheduled script easier to understand and run.

Cache stable, expensive reads carefully

N/cache can avoid repeating an expensive lookup. It is not a substitute for correct data access. Choose a key that includes every input that can change the answer, set a suitable TTL, and expect cache misses. Oracle's N/cache reference documents cache scopes and method costs.

Never cache permission-sensitive or customer-specific data under a shared key.

Use a small measurement loop

For one slow script:

1. Capture deployment, input size, elapsed time, remaining usage, and failure details.
2. Find the repeated or high-cost operation.
3. Change one thing.
4. Run the same input in a safe account.
5. Compare results and verify the records produced, not just the timing.

A useful test might compare 500 representative orders before and after removing a repeated customer lookup. The result belongs to that account and dataset. It should not be presented as a general benchmark.

Review checklist

• API costs checked against current Oracle documentation
• Remaining usage logged at batch boundaries
• Searches use selective filters and deterministic sorting
• Repeated record loads removed or justified
• Interactive scripts do only interactive work
• Batch operations can retry safely
• Cache keys include all relevant inputs
• Tests use representative volume and verify output

Performance work is done when the script is both faster enough and still correct.