SfSkills Domains Docs GitHub

Home / devops / performance-testing-salesforce

performance-testing-salesforce

Use when planning or executing load tests, stress tests, or performance benchmarks against a Salesforce org. Covers Salesforce Scale Test, third-party tools (JMeter, BlazeMeter, k6), API throughput testing, Experience Page Time. NOT for Apex unit test performance assertions, LWC Jest tests, or query tuning — use data/soql-query-optimization.

Open the skill folder on GitHub

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:

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

SituationRecommended ApproachReason
Pre-release UI performance validationScale Test on Full Copy sandboxFirst-party tool with native EPT instrumentation; no additional licensing
API integration throughput testingk6 or JMeter against Full Copy or Partial Copy sandboxScale Test does not support API-only scenarios
Quick EPT spot-check on a single pageLightning Usage App + Chrome DevToolsNo test infrastructure needed; immediate feedback
Continuous performance regression detectionAutomated k6 scripts in CI pipeline against scratch org or sandboxCatch regressions early; integrate with existing DevOps tooling
Data volume testing for SOQL performanceFull Copy sandbox with production-scale dataQuery performance is data-volume-dependent; small sandboxes hide problems

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:

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

ArtifactDescription
Performance test planDocument specifying NFRs, test scenarios, environment requirements, tooling, and schedule
Load test scriptsk6 or JMeter scripts configured with OAuth auth, realistic payloads, and ramp-up profiles
EPT measurement reportBefore/after EPT metrics by page with environment details and optimization actions taken
Results summaryComparison of measured performance against NFRs with pass/fail status and bottleneck analysis

Dependencies

Package files