Help Centre


How Salesfire keeps your page speed fast

Page speed is a very important metric for online businesses - visitors expect a fast and responsive experience online. In this article, we explain how we strive to keep your page speed performance to a maximum and outline our efforts to meet these expectations.

Asynchronous and non-blocking loading

The Salesfire script does not block any other content from loading on your website. Instead, as per industry standards, we load our script asynchronously. This allows your page to render and be visible to the visitor whilst Salesfire and other scripts load in parallel behind the scenes. Once our product has finished loading in the background, Salesfire will then prepare your campaigns and display any other complementary content.

Read more:


In addition to asynchronous-loading practices, we also utilise lazy-loading. This means that we only load the necessary functionality that is required for your website or the products that you have subscribed to. This keeps the amount of content downloaded and execution time down to the minimum required. These also load asynchronously and in parallel to maintain the fast and responsive experience your visitors are accustomed to.

Read more:


On-site content is only loaded when it is in the viewport. For example, our Recommendations units will only load when their location on the page is currently visible to the visitor. If it is below the fold, we will not load the unit until the visitor scrolls it into view. We also insert a placeholder where the unit is due to appear so it reduces layout shifts and repainting (i.e. pushing content down) as the unit loads.

Read more:

Unused JavaScript

Occasionally, Salesfire's script, among other first-party and third-party scripts, can flag the Reduce Unused Javascript page speed recommendation. As explained in the previous section, we lazy-load functionality to reduce the amount of unused JavaScript to a minimum.

There are instances where functionality may be loaded in anticipation of visitor’s behaviour, whilst this can be flagged by automated page speed analysers, we require this functionality to be loaded for when the visitor requires it. As much of our solution responds to visitor interaction, not all functionality is utilised immediately. This may be similar to your own website, where you load Add to Basket functionality in anticipation of the visitor interacting with the website at a later time in the page session to make a purchase.

Read more:


Salesfire operates its own Image Optimisation service. Our Image Optimisation service is responsible for several performance tasks. It compresses and reduces the size of images to the required quality and dimensions needed for that particular product, reducing file size. And secondly, it caches the images across different servers as near to your visitors as possible, to reduce the latency and time to download images. As we cache these images for you, it will also reduce the demand on your own asset servers. We aim to deliver all images in modern formats such as WebP where possible.

Read more:

Common Core Vitals Metrics

LCP - Largest Contentful Paint

This affects the longest render time for content. As Salesfire loads in the background once the primary content has been rendered and displayed we do not affect this. Despite this, it is good practice to ensure that images are compressed and resized to the required size and that campaigns do not load immediately, which we would not recommend from a UX perspective.

Read more:

CLS - Cumulative Layout Shift

This identifies any shift in layout and content once the page has loaded. Salesfire deploys various good practices to keep this to a minimum. This includes adding placeholders for deferred content as explained in the viewport-loading section. We also load many of our products such as Digital Assistant, Search and Overlays on top of the page to prevent any layout shifts.

Certain page speed measuring tools will notify of layout shifts that in practice do not cause a repaint or content moving. This happens in instances where we use iframes to sandbox content where these tools assume paints within iframes are affecting the parent frame's layers. Whilst this makes no noticeable difference to the end-user, these tools assume this is happening. We are investigating ways to ensure these tools understand this.

Read more:

FID - First Input Delay

This measures how much time a visitor must wait until they are able to interact with the website. For example, are links and buttons not interactive until a short delay after the page displays?

Salesfire does not impact the FID as we load complementary content after the initial First Contentful Paint.

Read more:,

Ongoing efforts

Our engineering teams are tasked with continuously focusing on maintaining a fast and responsive experience for our clients’ visitors. Any feature and enhancement releases have performance in mind and our teams are working on various projects to further research and release performance updates to keep our solutions up-to-date with the latest industry advice and browser advancements.

Advice and troubleshooting your page speed

  • Images: Ensure uploaded images are the correct size and dimensions.
  • Campaign triggering: Avoid overwhelming the visitor with too many campaigns as soon as they land on the website to improve the user journey and reduce potential page speed warnings.
  • Campaign triggering: Avoid using long delays for campaigns. Page speed tools often associate delays as long execution times. We’re investigating methods to use delays in campaigns without being flagged by page speed tools.

Further reading and resources

  • Help Centre - Browse our Help Centre for help, advice and best practices.
  • Academy - Become a CRO expert and join our Academy.