Performance Testing Salesforce

Performance Testing Salesforce

Activates when a practitioner needs to plan, execute, or interpret load tests, stress tests, or performance benchmarks against a Salesforce org. Covers the full lifecycle from environment selection through test design, execution with first-party (Scale Test) or third-party tools, and results interpretation with a focus on platform-specific constraints.

Before Starting

Gather this context before working on anything in this domain:

• Sandbox type availability — Scale Test requires a Full Copy sandbox. Developer and Developer Pro sandboxes have 200 MB storage limits and do not replicate production data volume or record distribution. Performance numbers from undersized sandboxes are meaningless.
• API limit awareness — The concurrent API request limit applies only to requests running longer than 20 seconds. Short-lived requests do not count toward the concurrency cap. The total daily API request limit is edition-dependent and shared across all integrations.
• EPT baseline — Experience Page Time (EPT) is the Salesforce-native metric for Lightning page load performance. The target is under 3 seconds. EPT is measured in the browser, not on the server, so network latency and client hardware affect results.

Core Concepts

Salesforce Scale Test

Scale Test is the first-party performance testing service from Salesforce. It runs synthetic load against a Full Copy sandbox to simulate user concurrency for Lightning UI flows. Scale Test is available at no additional cost for Enterprise, Unlimited, and Performance editions. Tests are requested through Salesforce Support and scheduled in coordination with the Scale Test team. Results include EPT measurements, server-side timings, and governor limit consumption per transaction.

Key constraints: Scale Test only runs against Full Copy sandboxes. It does not support API-only load generation. Test scenarios must be defined as UI-based user journeys. Maximum test duration and concurrency are coordinated per engagement.

API Load Testing

For integration-heavy orgs, API throughput testing validates that REST, SOAP, Bulk, and Streaming API calls perform within acceptable bounds under production-like concurrency. The concurrent long-running request limit (default 25 for most editions) applies only to requests exceeding 20 seconds. The total API request limit is a 24-hour rolling window. API load tests should use authenticated sessions from a dedicated integration user with appropriate API permissions.

Third-party tools such as JMeter, k6, and BlazeMeter are the standard approach. Each test must include realistic authentication (OAuth 2.0 flows), proper session management, and representative payload sizes.

Experience Page Time (EPT)

EPT measures the time from navigation start to the point where the page is interactive in Lightning Experience. Salesforce exposes EPT in the Lightning Usage App and via the EventLogFile (EPT event type). The EPT target of under 3 seconds applies to standard and custom Lightning pages. EPT is affected by component count, wire adapter calls, Apex controller round-trips, and third-party scripts loaded on the page.

Common Patterns

Pattern 1: Scale Test for UI Performance Baseline

When to use: Before a major release, org migration, or Lightning transition when you need to validate that UI performance meets NFRs under concurrent user load.

How it works:

1. Provision a Full Copy sandbox and ensure data volume matches production.
2. Open a Support case requesting Scale Test and provide target concurrency, key user journeys, and preferred test window.
3. Scale Test team configures synthetic users and runs the test during the scheduled window.
4. Review the results report for EPT distributions, server response times, and any governor limit warnings.
5. Address hotspots (slow Apex controllers, heavy LWC components, inefficient SOQL) and retest.

Why not the alternative: Third-party UI automation tools (Selenium, Playwright) do not execute inside the Lightning runtime the same way real users do, and they cannot produce EPT metrics natively. Scale Test uses Salesforce's own instrumentation.

Pattern 2: API Throughput Testing with k6 or JMeter

When to use: When integrations are a significant part of the workload and you need to validate API response times and throughput under concurrent load.

How it works:

1. Identify the integration endpoints (REST, SOAP, Bulk API) and their expected peak concurrency.
2. Create test scripts that authenticate via OAuth 2.0 Connected App credentials (never hardcode passwords).
3. Ramp concurrency gradually: start at 10% of target, then 25%, 50%, 75%, 100%.
4. Monitor response times, HTTP status codes (watch for 429 and 503), and API usage via the API Usage Notification in Setup.
5. Correlate results with EventLogFile entries (API event type) for server-side timings.

Why not the alternative: Scale Test does not cover API-only workloads. Manual spot-checks with Postman or Workbench do not reveal concurrency-related degradation.

Pattern 3: EPT Measurement and Optimization Cycle

When to use: When Lightning pages feel slow and you need data-driven evidence to prioritize optimizations.

How it works:

1. Enable the Lightning Usage App in Setup and review the EPT dashboard for baseline metrics.
2. Identify pages with EPT above 3 seconds.
3. Use Chrome DevTools Performance tab with the Lightning Extension to profile specific pages.
4. Reduce component count, defer non-critical wire calls, replace imperative Apex with cacheable wire adapters, and remove unused third-party scripts.
5. Remeasure EPT and compare against baseline.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner working on this task:

1. Define performance NFRs — Confirm EPT targets (under 3 seconds default), API response time SLAs, and peak concurrency expectations. Reference the architect/nfr-definition-for-salesforce skill if NFRs are not yet defined.
2. Select the test environment — Provision a Full Copy sandbox for realistic testing. Verify that data volume, sharing rules, and org configuration match production. Developer and Developer Pro sandboxes are not valid for performance testing.
3. Design test scenarios — Map critical user journeys (UI flows) and integration patterns (API calls) to test scripts. Include realistic think times and data variation. A test scenario that always reads the same record is not representative.
4. Choose tooling — Use Scale Test for UI concurrency validation. Use k6, JMeter, or BlazeMeter for API load testing. Use Lightning Usage App and Chrome DevTools for EPT profiling.
5. Execute tests incrementally — Ramp load gradually. Start at low concurrency to establish baseline, then increase to target. Monitor for HTTP 429 (rate limit) and 503 (service unavailable) responses.
6. Analyze results and act — Compare EPT and response times against NFRs. Investigate governor limit warnings. Address the top bottleneck first — typically slow Apex, heavy SOQL, or oversized LWC component trees.
7. Retest and document — After optimizations, retest at the same concurrency level. Document before/after metrics, environment details, and any platform limits encountered.

Review Checklist

Run through these before marking work in this area complete:

• Performance NFRs are defined with specific, measurable targets (EPT < 3s, API p95 < 2s, etc.)
• Full Copy sandbox is provisioned and verified to have production-representative data volume
• Test scenarios cover both UI user journeys and API integration patterns
• OAuth 2.0 authentication is used in API test scripts (no hardcoded credentials)
• Load ramp-up is gradual, not a spike to full concurrency
• Results are compared against defined NFRs, not just "it didn't break"
• EventLogFile data (EPT and API event types) is reviewed for server-side confirmation
• Bottlenecks are documented with root cause and remediation actions

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. Concurrent API limit applies only to long-running requests — The 25-request concurrent limit (most editions) only counts requests that have been running for more than 20 seconds. Short-lived API calls do not consume concurrency slots. Teams often over-engineer throttling for fast endpoints based on a misunderstanding of this limit.
2. Developer Pro sandbox is not a valid performance environment — Developer Pro sandboxes have a 200 MB data storage cap and do not replicate production data volume, custom indexes, or sharing rule calculations. Performance numbers from Developer Pro are not transferable to production. Full Copy is the minimum for meaningful results.
3. EPT is a client-side metric that varies by browser and network — EPT measures time-to-interactive in the browser. The same page can show 1.5s EPT on a corporate LAN and 4.5s on a VPN connection. Always document the client environment alongside EPT measurements. Server-side response time (from EventLogFile) is the stable comparison point.
4. Scale Test results include sandbox overhead — Full Copy sandboxes may have slightly different performance characteristics than production due to infrastructure differences. Use Scale Test results for relative comparisons (before vs. after optimization) rather than absolute production predictions.
5. API daily limit is shared across all integrations — A load test consuming 100,000 API calls may exhaust the daily limit for the entire sandbox, blocking other development work. Schedule API load tests during off-hours and notify the team before running.

Output Artifacts

Related Skills

• architect/nfr-definition-for-salesforce — Use first to define measurable performance requirements before testing
• devops/environment-strategy — Use to plan sandbox allocation and determine which sandbox types are available for performance work
• data/soql-query-optimization — Use when performance testing reveals slow queries as a bottleneck
• apex/apex-cpu-and-heap-optimization — Use when Apex governor limits are hit during load testing