By replacing synchronous network requests and making its initialization more interaction-friendly, Poptin reduced Interaction to Next Paint (INP) by 57% at the 75th percentile across thousands of Shopify stores.
Poptin is an all-in-one email marketing automation & conversion rate optimization platform that helps merchants create popups and lead-capture forms, and engage shoppers with on-site and email campaigns. The app is used by thousands of merchants around the world. Together, Shopify’s Web Performance team and Poptin’s developers identified and fixed a main-thread bottleneck in the app’s storefront script, improving responsiveness for merchants and their customers at scale.
Finding a performance opportunity
Third-party apps are an important part of the Shopify ecosystem, but their storefront code can affect a shopper’s experience beyond the features they see. During a web performance investigation, Shopify’s Web Performance team noticed that Poptin’s script was associated with slow interactions across page types.
A real-user monitoring (RUM) signal pointed to a particularly severe issue: Poptin’s script was responsible for a long task of around 900 milliseconds on the main thread during initialization. Our tests showed that the script was making synchronous XMLHttpRequest calls from its script load handler. Because synchronous requests block the main thread until the network response arrives, the browser could not process user input during the request chain.
The requests included calls to retrieve a client ID, read the cart, and retrieve price rules, as well as an additional synchronous cart request in another function. These calls ran on every page load, whether or not a popup was configured or displayed. On slower connections and devices, the network round trips made the impact even more pronounced.
The image above shows a Chrome DevTools performance profile, revealing a ~900ms task during page load caused by Poptin.
The investigation also showed that this was not an isolated result from one storefront. In an initial seven-day sample of stores where Poptin was the slowest script during interactions, the script was associated with a p75 INP of 984 milliseconds across hundreds of thousands interactions and thousands Shopify merchants.
Partnering on the solution
Shopify shared the findings with Poptin’s development team, including the trace evidence, the suspected root cause, and specific implementation options. The collaboration focused on two changes:
1. Making network requests asynchronous
The primary recommendation was to remove the synchronous request flags from their script and allow the existing asynchronous callbacks to handle the responses. Two parts of the code required a small structural refactor:
-
The client ID, cart, and price-rules requests were moved into a callback chain so that each request starts only after the data it depends on is available.
-
The function that returned cart data synchronously was changed to accept a callback, allowing the code that used the cart data to run after the response arrived.
This approach preserved the app’s behavior while ensuring that network latency no longer blocked the browser’s main thread.
2. Deferring initialization
Shopify also recommended scheduling Poptin’s initialization in a new task instead of running it directly inside the script load handler. This gives the browser an opportunity to process queued input before the app begins its work, making initialization more interaction-friendly by design.
The image above shows how the longest Poptin task is now ~75ms (a 91% reduction).
Poptin’s engineering team evaluated the proposal, adapted it to their architecture, and built on it with a comprehensive implementation.
Measuring the impact at scale
Results: faster interactions and fewer long tasks
Across all devices and browsers, Poptin’s release produced a substantial improvement in storefront responsiveness:
|
INP percentile |
Before |
After |
Change |
|---|---|---|---|
|
P50 |
88 ms |
64 ms |
−27% |
|
P75 |
280 ms |
120 ms |
−57% |
|
P90 |
736 ms |
272 ms |
−63% |
At the 75th percentile, INP moved from 280 milliseconds to 120 milliseconds - an improvement of 160 milliseconds and a move into the “Good” range. The largest gains appeared in the slower tail of the distribution, where shoppers are most likely to experience delayed feedback.
The attribution data available for browsers that support the Long Animation Frames API showed that the app’s blocking work had almost disappeared:
|
Metric |
Change |
|---|---|
|
Daily interactions where Poptin was the slowest script |
−98.6% |
|
Stores affected per day |
−89.7% |
|
Poptin-attributed script duration at p75 |
−46% |
|
Poptin-attributed INP at p75 |
−39% |
Even in the small number of interactions where Poptin still appeared as the slowest script, the p75 INP for those interactions improved by 39%.
What this collaboration shows
Third-party performance is a shared opportunity
An app does not need to be visibly rendered on the page to affect a shopper’s experience. Poptin’s initialization ran on every page load, which meant that improving the app’s underlying storefront script could benefit customers across many different storefronts and page types.
Deprecated browser APIs can create measurable costs
Synchronous XHR has been deprecated for years because of performance reasons. Replacing it with asynchronous requests eliminated the main source of Poptin’s long initialization tasks without changing the popup’s behavior.
Evidence makes collaboration effective
The partnership combined RUM data, performance traces, code-level analysis, local validation, and a controlled before-and-after measurement. This gave Poptin’s developers a clear problem to solve and a way to verify the result after shipping.
Attribution needs to be paired with experience-level measurement
Script-level attribution is useful for identifying which app is responsible for a slow interaction, but it does not cover every browser. Measuring INP across all pageviews provided a more complete view of the customer experience and showed that Poptin’s changes improved responsiveness at ecosystem scale.
The work with Poptin is an example of how Shopify and third-party app developers can collaborate to make storefronts faster and more responsive for merchants and shoppers around the world.
A call to third-party app developers
Every third-party app has an opportunity (and a responsibility) to understand how its code affects the stores that use it. We encourage app developers to regularly monitor real-user performance, inspect their scripts for main-thread work and blocking network requests, and test their apps on slower devices and connections. Small implementation details, such as a synchronous request during initialization, can become a significant experience issue when they run across thousands of storefronts. By measuring their impact, addressing bottlenecks proactively, and partnering openly on solutions, app developers can help make the entire Shopify ecosystem faster for merchants and shoppers.