When NetSuite Feels Slow
Slow dashboards, timeout errors, and sluggish saved searches frustrate users and hurt productivity. Performance issues usually stem from: heavy saved searches, inefficient SuiteScript, too many portlets, unindexed custom fields, or system preferences. This guide covers optimization strategies you can implement with minimal developer help, plus when to call in SuiteScript expertise.
Saved Search Optimization
Use indexed fields in criteria (e.g., trandate, entity, subsidiary, mainline). NetSuite indexes standard fields; custom fields need explicit indexing. Avoid "Is Not Empty" on non-indexed fields when possible—it forces full scans. Limit result columns; each adds processing. Use summary searches instead of detail when you only need counts or sums. Avoid formulas on millions of rows; pre-calculate in custom fields and summarize those. Test with "Execute" and note execution time; if over 30 seconds, optimize or split the search. Add date range filters to limit the dataset.
| Issue | Fix |
|---|---|
| Search timeout | Add date/subsidiary filters, reduce columns, use summary |
| Slow criteria | Use indexed fields, avoid NOT and OR on non-indexed |
| Heavy formulas | Pre-calculate in custom fields, use simpler expressions |
| Too many results | Add summary type, limit rows, or split into multiple searches |
Governance and Limits
NetSuite enforces governance limits on scripts: units per execution (e.g., 10,000 for scheduled), units per day. Saved searches have row limits (e.g., 1000 default). Monitor usage in Setup > System Information. Optimize scripts to reduce units: avoid search.create in loops (load IDs first, then batch), use bulk operations (record.submitFields), cache lookups in maps. Exceed limits and scripts fail—plan for growth.
Script Optimization
Use N/search (SuiteScript 2.x) instead of deprecated N/search Module. Use search.create with filters to limit result set before processing. For mass updates, use record.submitFields (fewer units than full load/save) or bulk processing APIs. Avoid loading full records when a few fields suffice—use search or getSublistSubrecord for specific fields. Reduce round-trips: batch lookups, avoid nested loops that call search repeatedly. Use pagination for large result sets.
Dashboard and Portlet Tuning
Limit portlets per dashboard—each runs a search or report on load. Aim for 5–8 portlets; more can slow the homepage. Simplify underlying saved searches (fewer columns, stricter criteria). Consider removing rarely-used portlets. Use KPI portlets (lightweight) instead of full result tables where a single number suffices. For Workbook-based dashboards, apply the same filters and dataset limits.
System Preferences and Indexing
Review Setup > Company > General Preferences. Some settings affect performance (e.g., logging level, session timeout). Work with NetSuite support for server-side tuning; most settings are managed by NetSuite. Custom fields used in search criteria should be indexed when possible: check "Store Value" and "Indexed" in the field definition. Adding indexes improves search speed significantly but adds storage; balance for high-use fields only.
Common Pitfalls
Search in beforeLoad: Avoid running heavy searches on every page load. Unbounded date ranges: Always filter by date. Mainline=false with many lines: Transaction line searches can return millions of rows; filter aggressively. Duplicate portlets: Same search in multiple portlets runs multiple times—consolidate.
YRK Consulting performs NetSuite performance reviews. Get in touch.