App developers integrating PartnerJam's tracking code often ask whether it affects their app's performance — particularly LCP (Largest Contentful Paint), which is part of Shopify's Built for Shopify performance requirements.
Short answer: if you follow the implementation guide, there's no measurable impact on LCP or other Core Web Vitals.
We use the PartnerJam tracking code in our own Digismoothie apps, and they hold the Built for Shopify badge. If the script caused performance issues, we'd be the first to know.
Why there's no performance impact
The tracking code is designed to stay out of your app's critical path:
It loads asynchronously, so it doesn't block page rendering.
Each execution is lightweight — a single check with no heavy computation or DOM work.
Following the implementation guide ensures the script is added in a way that preserves these properties. The async loading pattern is the key — deviating from it (for example, loading synchronously or placing the code in a blocking context) can undermine the isolation, so it's worth sticking to the recommended integration exactly as documented.
The tracking code runs in your app's admin context, not on the merchant's storefront. Customer-facing pages — the ones that actually affect the store's public Lighthouse score — aren't touched.
Where to place the snippet
Our documentation uses root.tsx as an example, but the specific file doesn't matter. What matters is that the snippet:
Is loaded globally — on every page of your app's admin UI.
Runs as early as possible on the client.
Is included only once.
Any global entry point or layout that satisfies those three conditions works. If your app structure differs from the example, place it wherever the equivalent responsibility lives.
Why the snippet runs on every load
A question that comes up often: if the goal is to attribute one install per merchant, why does the snippet run on every admin page load — potentially thousands of times per merchant over the app's lifetime?
The short answer is: simplicity on your side. Running on every load means the attribution signal is guaranteed to fire at least once during the install window, without you needing to add state-tracking logic to figure out whether this particular merchant is a fresh affiliate install or a long-time user.
On our side, the check is cheap, and extra pings from merchants with no attribution to make are discarded harmlessly. We've designed the system to handle this volume by default.
If you'd prefer to be more surgical: you're welcome to add your own logic to only fire the snippet during the first few loads after install, or only when an affiliate referral is present in your install context. We fully support this and appreciate the effort, but it's genuinely not required — the default "just load it globally" path is the supported one.
Why the script is necessary
There's no alternative. Without the tracking code, PartnerJam has no way to know which publisher brought a specific merchant to your app. Shopify's Partner API doesn't expose install-source data, so attribution depends entirely on the signal the tracking code sends at install time.
No script means no attribution — which means no commissions, and no reason for publishers to promote the app.
If you're seeing a performance regression
If your app's metrics have degraded and you suspect the tracking code might be involved:
Verify your integration against the implementation guide. The most common cause of perceived impact is a deviation from the recommended async pattern.
Measure before and after with Lighthouse or Web Vitals in a staging environment, so you can isolate whether the script is actually the source of the regression or whether something else changed at the same time.
Reach out via in-app chat if the integration looks right and you're still seeing impact — we'll investigate with you.