How To Measure The Impact Of OptinMonster On Your Website

Understanding the impact of OptinMonster on your website allows you to make more informed decisions; as the performance of your website plays a vital role in search rankings, user experience, sales, and conversions.

In this article, you’ll learn more about measuring the impact of OptinMonster on your website.

Before You Start

Here are some things to know before you begin:

Page Speed Testing

Measuring the exact impact OptinMonster has on your website is not an easy task. Tools like Google’s Pagespeed Insights or GTMetrix are great, but they don’t always give you the same consistent results.

The reason for that to happen is that there are many variables that go into measuring the page load. The same request can take different times to be resolved; the server could be busier for instance. And the order in which the requests resolve can influence what gets done first and when the page load actually finishes.

However, those tools can still provide us with great insights that can be very useful when trying to look for opportunities for improvement.

With vs Without OptinMonster

Comparing your website score with and without OptinMonster is the easiest and quickest way of trying to measure the impact OptinMonster has on your page load.

Although this is not the most accurate way, it can still point you in the right direction and hint you at things to look more in-depth.

Did your Time to Interactive metric get worse? What could be causing that? Could OptinMonster be loading too soon? Could delaying its execution help?

Did your Cumulative Layout Shift metric get worse? Do you have any Floating Bar campaigns or Inline showing up during page load?

It’s important that you examine the metric changes carefully. Does it make sense that OptinMonster would cause a change on that metric? Could other variable factors be the cause?

Pro Tip: To help you run a performance report without having to really disable OptinMonster for your whole website, you can use the query string param or cookie omshutdown=1 to disable OptinMonster on specific requests only. For example:

Disabling OptinMonster completely might be the most reliable approach, as for the omshutdown flag to work, the OptinMonster script still needs to be downloaded and executed on your page. But we believe the impact that just the OptinMonster script would have is too small that it should not be taken into consideration.

Number of Requests

Reviewing the requests that are triggered by OptinMonster might give you good insights into what things you could do differently to reduce the number of requests and the impact that has on your website performance.

OptinMonster Script Request

The very first request related to OptinMonster is for our script file:

That request is initiated from the embed code we provide for you to add to your page.

Our script file is where the OptinMonster Magic happens so it’s the script that’s responsible for fetching the campaign data, parsing it, processing the Display Rules, displaying the campaigns, and submitting the lead info to the back end.

We host the script in our CDN servers where it can be cached and served very fast in various locations around the world.

Once that script is downloaded and initialized, we trigger the request to fetch the campaigns’ data at a very early stage (this could be happening while your page is not fully loaded yet).

If you’re using the Global Embed code, you should expect only one request to fetch the campaigns’ data. The response should include all active campaigns that have been associated with that domain in your OptinMonster account. If you’re using the Campaign-Specific Embed code you should expect one request per embed code found on the page.

Those requests are served from our API and although they are also cached, we can’t set a very large TTL (time-to-live) for them. We don’t do that because that would cause an undesirable delay between your campaigns’ update and what your visitors would see.

Once the campaigns’ data are parsed, there are other requests that can be triggered depending on what type of campaigns have been loaded.

Web Fonts / FontAwesome Request

If at least one campaign has custom Web Fonts or FontAwesome icons and you have not disabled Web Fonts, then you should also expect a request to webfonts.js. That script is responsible to load any Web Fonts you may have in your campaigns and it will trigger more requests once your campaign is ready to be displayed.

Coupon Wheel Request

If at least one campaign has a coupon wheel, then you should also expect a request to

Date / Time Request

If at least one campaign has Date and Time Display Rules configured, then you should also expect requests to moment.min.js and moment-timezone-with-data-2012-2022.min.js.

Geolocation Request

If at least one campaign has a geolocation rule, then you should also expect a request to /v3/geolocate/json. This request is meant to identify the visitor’s geolocation info.

AdBlock Request

If at least one campaign has an AdBlock Display Rule configured, then you should also expect a request to prebid-ads.js. This request is meant to fetch the script that contains the logic for the AdBlock Display Rule.

MonsterEffects™ Request

If at least one campaign has MonsterEffects™ configured, then you should also expect a request to soundeffects.lib.js.

Summary of Requests

The following URLs are for all third-party resources (some internal, others external) that we have copied so we could serve from our own CDN servers where it can still be cached and served very fast. With the additional benefit of a DNS lookup reduction that your visitors’ browser would experience if requesting the same resources from their respective CDN servers.


It’s important to note that the requests are only made if those resources don’t already exist on the page. So if your website already uses the moment.js library to work with dates, OptinMonster will not request the moment.min.js resource again.

All of the requests above happen reasonably no longer after the OptinMonster script initialization; and depending on a lot of factors, they could happen even before your page is fully loaded yet.

Once one of your campaigns’ Display Rules has been processed and confirmed the rules have all passed, then the campaign is ready to be displayed.

The campaign display routine will also trigger some requests. So if you have a campaign being displayed early during the page load, you should also pay attention to the requests that get triggered in this phase.

The first request you should expect is one for the data for the campaign view that will get displayed first (Yes/No view or the Optin view). The request URL will look like this:{user-hash}/{campaignSlug}/{content-hash}-{view}.json

The response will contain the HTML markup and CSS styles for that view. The larger or more complex your view is, the larger the response size will be.

If the campaign has Web Fonts or FontAwesome icons, then you should expect a request to a CSS resource containing all the Web Fonts in the campaigns, which will then request the Web Font woff2 file for each font.

If your campaign view has images, then you should also expect one request per image present in the campaign view’s HTML markup.

Only after these requests have finished will the campaign be displayed on the screen. If many requests happen, that can result in a delay between the Display Rules passing and the actual display of the campaign.

Once the campaign is displayed, you should see one final request to /v3/i; which is the request that records the campaign impression.