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:
- This guide covers technical information in detail and is intended for advanced users only.
- We also recommend our How to Optimize Campaign Usage in OptinMonster and OptinMonster Campaign Performance Technical Overview and Defaults guides for more performance optimization details.
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 consistent results. Even so, these tools can provide you with great insights on your site’s performance and on opportunities for improvement.
The reason results can be inconsistent is because of the many variables that go into these measurements. One example is inconsistent load on the server (busier during one request than another). Another influencing factor is the order in which the requests resolve, determining what gets completely loaded first, and can affect the final page load completion.
With vs Without OptinMonster
One quick and easy way to measure OptinMonster’s impact on your site is to compare your scores for when OptinMonster is used and when it is not.
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 factors be the cause?
The OptinMonster Request Lifecycle
To illustrate the steps we take to improve performance, it’s important to understand the requests we make. Below is a detailed overview of the HTTP requests OptinMonster makes, what they do, and why they’re important.
OptinMonster Script Request
The very first request related to OptinMonster is for our script file: https://a.omappapi.com/app/js/api.min.js
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 begins and is responsible for: fetching campaign data, parsing it, processing the display rules, displaying the campaign(s), and submitting leads.
We host our script on our CDN servers where it is cached and served from various locations around the world, fast and efficiently.
Once our script is downloaded and initialized, we fetch campaign 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 to see only one request to fetch campaign data. The response will include data for all active campaigns that are associated with your site domain.
If you’re using the Campaigns-Specific Embed code, you will see one request for each campaign.
These requests are served from our API and, although cached, we don’t set a large TTL (time-to-live) for them. That would cause an undesirable delay between when you update your campaign(s) and when your visitors see those updates.
Once the campaign data is parsed, there are a number of requests that could be made depending on your campaigns.
JavaScript Module Requests
OptinMonster utilizes JavaScript modules to break our code into smaller “chunks” that are then fetched when needed. The purpose of this approach is to deliver multiple small files rather than one large file and comes with numerous benefits. Among them are:
- We can take advantage of the recommended HTTP/2 protocol and performance improvements that come with it.
- We serve files on an as-needed basis. This means that, depending on your campaigns, some modules will be loaded while others won’t. This allows us to serve less code overall without sacrificing functionality.
- Modules greatly improve Core Web Vital scores, especially as they relate to unused code.
Module requests usually take the form of:
https://a.omappapi.com/app/js/{number}.{hash}.min.js
For example:
https://a.omappapi.com/app/js/13.5335765312.min.js
Web Fonts / FontAwesome Request
If at least one campaign uses web fonts or Font Awesome icons (and you haven’t disabled web fonts), you should see a request for webfonts.js. This script is responsible for loading any web fonts your campaign(s) use and will trigger more requests once campaigns are ready to be displayed.
Coupon Wheel Request
If at least one campaign uses a coupon wheel, you should see a request to popmotion.global.min.js.
Date / Time Request
If at least one campaign uses date/time Display Rules, you should see requests for moment.min.js and moment-timezone-with-data-2012-2022.min.js.
Geolocation Request
If at least one campaign uses a geolocation Display Rule, you should see a request to /v3/geolocate/json. This request is used to fetch the visitor’s geolocation information.
AdBlock Request
If at least one campaign uses an AdBlock Display Rule, you should see a request to prebid-ads.js. This request fetches a script that contains logic for this rule.
MonsterEffects™ Request
If at least one campaign uses MonsterEffects™ you should see a request for soundeffects.lib.js.
Summary of Requests
The following URLs are for all third-party resources (some internal, others external) that we serve from our own CDN servers. These resources are cached and served very fast. This also affords us the added benefit of reducing the number of DNS lookups.
https://a.omappapi.com/app/js/webfont/1.5.18/webfont.jshttps://a.omappapi.com/app/js/prebid-ads.jshttps://a.omappapi.com/app/js/soundeffects/soundeffects.lib.jshttps://a.omappapi.com/app/js/moment.js/2.24.0/moment.min.jshttps://a.omappapi.com/app/js/moment-timezone/0.5.23/moment-timezone-with-data-2012-2022.min.jshttps://a.omappapi.com/app/js/popmotion/8.5.5/popmotion.global.min.js
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.
These requests happen soon after the OptinMonster script is initialized and, depending on various factors, could happen even before your page is fully loaded.
Once a campaign’s rules have passed and it can be shown, a few more requests will be made. If you have a campaign that is displayed early during page load, you should pay attention to these requests.
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 will be for data of the campaign view that will be displayed first (Yes/No view or the Optin view). The request will look like this:
https://app.staging.optinmonster.com/app/campaign-views/{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 uses web fonts or Font Awesome icons, you should see a request to a CSS file containing all of the fonts used in the campaign, this will in turn request each font’s woff2 file.
If your campaign view has images, then you should see 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 analytics request to track your campaign’s performance.
