Skip to main content

SSJS vs AMPScript Performance

Should I use AMPScript or SSJS? Which is better? As always, it depends. Check the performance comparisons for various use cases.

There is much knowledge shared on blogs, social networks, and Stack Exchange in the Salesforce Marketing Cloud world. Frequently you will see some strong opinions on which scripting approach is best.

I decided to check some of those assumptions empirically. Some test results are obvious, and some might surprise you (just as they surprised me).

I split the article into two sections:

  1. Conclusions are the TL;DR of my tests. If you want quick high-level findings - go there.
  2. Performance Test Cases are the nerdy part, where I describe the exact code used for each case and more dive into detailed outcomes that might give you a better basis for a decision on what to use.
You Should Know

This article will be in constant Work In Progress state, as I plan to add new test cases and conclusions perpetually.

Should you have any interesting idea for a test case - let me know!

Next: speed comparison of mirrored SSJS Platform and Core functions.


AMPScript vs SSJS

For scripting in time-critical assets (Emails, SMS, Pushes), go with AMPScript. It is much more optimised for the most popular use cases in this space, which will make a difference when scaled for hundreds of thousands of executions.

For scripting in other assets (Landing Pages, Automation Studio), it depends on the use case. As a rule of thumb, AMPScript might be a bit more optimised, but for more complex projects, it lacks readability, flexibility and power (arrays, objects, try/catch, etc.). If you are building something simple - AMPScript might be the way to go. Otherwise, go with SSJS (or mix for optimisation).

SSJS Best Practices

When splitting your SSJS code block, try not to do it within a long loop (Code Block Breaking).

However, if you find an out-of-the-box AMPScript function that does something requiring custom development on the SSJS side (ProperCase, SFDC integration), it might be worth to inject AMPScript into your SSJS. The impact of code splitting on execution time might be much smaller than that of the complex code necessary to replicate a function (ProperCase). For functions available in both languages, you should stay with the SSJS not to mix scripting contexts (LowerCase & UpperCase).


The testing toolset is minimal by the nature of SSJS and AMPScript. I'm using a Cloud Page and new Date().getTime(); to capture the execution's beginning and end. Within this scope, I run a loop with the code I want to test. Finally, I divide the total time by the number of loop iterations to get an average run time.

This approach means that the millisecond values I provide are in no way the exact times you can use to calculate the speed at scale. But they should be standardised enough to allow for meaningful comparison between various scenarios. The actual times also change a bit when we run the test multiple times, as the strain on Marketing Cloud servers at the very moment of execution also has an impact. Focus less on exact milliseconds count and more on relations between the values.

In the test case descriptions, you can find additional details on the methodology: input used for the test, expected output, number of loop iterations or exact code tested.

You Should Know

For testing the execution speed of AMPScript block solutions, I'm using the SSJS to start and stop the count. I compared it with calculation using AMPScript FormatDate(Now(), 'ISO'), and there was no meaningful difference between the two.

Performance Test Cases

Code Block Breaking

I wanted to test the cost of breaking out of a code block for both SSJS and AMPScript.

Understanding the execution time impact of the scripting context switch was necessary for me to make valid conclusions for future tests and help decide on the best approach when coding a personalisation solution.

Test Cases

In this scenario, there is no context switch. I timed a pure SSJS loop to have a base for analysis.

for (var i = 0; i < 10000; i++) {
var a;

Outcomes (ms)


Sum Up

  1. Breaking out of the SSJS code block is impacting execution time.
  2. Breaking out of the AMPScript code block has close to none impact on execution time.


What should you use when you want to change a string to Proper Case? As there is no single function in SSJS for that, I compared two pure SSJS approaches (split/join & replace with RegEx) with AMPScript in SSJS and (nearly) pure AMPScript.

The test was performed using ten different strings varying in number of words and capitalization:

var sentences = [
'one', // 1
'one Two', // 2
'one Two THREE', // 3
'one Two THREE fOUR', // 4
'one Two THREE fOUR FiVe', // 5
'one Two THREE fOUR FiVe siX', // 6
'one Two THREE fOUR FiVe siX &', // 7
'one Two THREE fOUR FiVe siX & 8', // 8
'one Two THREE fOUR FiVe siX & 8 nine', // 9
'one Two THREE fOUR FiVe siX & 8 nine-ten' // 10

All approaches output final sentence as: One Two Three Four Five Six & 8 Nine-ten

Test Cases

function toTitleCase(string) {
var sentence = string.toLowerCase().split(" ");
for (var i = 0; i < sentence.length; i++) {
sentence[i] = sentence[i][0].toUpperCase() + sentence[i].slice(1);
sentence = sentence.join(" ");
return sentence;

title = toTitleCase(testedString);

Outcomes (ms)

SentenceSSJS SplitSSJS ReplaceAMPScript in SSJSAMPScript

Sum Up:

  1. Pure AMPScript execution time for ProperCase scenario murders SSJS.
  2. When working with arrays or regex replace, SSJS execution time extends with each additional word. However, AMPScript execution time is constant thanks to the optimised out-of-the-box ProperCase function.
  3. Although AMPScript in SSJS is doing levels-of-magnitude worse than pure AMPScript, it will be a better choice then pure SSJS for long sentences (10+ words).
  4. SSJS Replace might be the option to choose despite the performance if you want more flexibility (for example, changing that Nine-ten to Nine-Ten).
  5. Otherwise, for anything longer than a few words, consider breaking from the SSJS code block to leverage AMPscript.

LowerCase & UpperCase

Based on the Proper Case scenario's exciting outcomes, I decided to follow up on that with a performance comparison on a function that is available out-of-the-box in both SSJS and AMPScript. For testing, I used sibling string modification - Lower Case.

The test was performed using ten different strings varying in number of words and capitalization (same as for Proper Case):

var sentences = [
'one', // 1
'one Two', // 2
'one Two THREE', // 3
'one Two THREE fOUR', // 4
'one Two THREE fOUR FiVe', // 5
'one Two THREE fOUR FiVe siX', // 6
'one Two THREE fOUR FiVe siX &', // 7
'one Two THREE fOUR FiVe siX & 8', // 8
'one Two THREE fOUR FiVe siX & 8 nine', // 9
'one Two THREE fOUR FiVe siX & 8 nine-ten' // 10

All approaches output final sentence as: one two three four five six & 8 nine-ten

Test Cases

title = testedString.toLowerCase();

Outcomes (ms)

SentenceSSJS MethodSSJS FunctionAMPScript in SSJSAMPScript

Sum up

  1. The out-of-the-box JavaScript method works much better then the custom solution developer for Proper Case - just like the AMPScript function, it executes in constant time regardless of sentence length.
  2. Pure AMPScript execution time still is better, but due to constant time in both languages and much faster SSJS speed, there is no longer any reason to use AMPScript in SSJS or break out of SSJS code block.