Understanding cookies in Klaviyo

1. What this guide is for

Customers often ask:

• “Are all these Klaviyo scripts really necessary?”
• “Is Klaviyo slowing down my site or hurting my PageSpeed score?”
• “Can I remove some Klaviyo scripts (e.g., for forms, Reviews, Customer Hub) without breaking things?”

This guide explains, at an internal level:

• What the main Klaviyo scripts do
• Which scripts are required vs. optional
• How Klaviyo’s JavaScript impacts site speed and PageSpeed reports
• How to triage and respond when customers raise performance or “too many scripts” concerns
• How this changes as new products (e.g., Reviews, Customer Hub) are added

Use this as a backbone for internal understanding; customer-facing responses should be simplified and linked to the appropriate Help Center docs.

2. Key concepts: Klaviyo onsite JavaScript & cookies

2.1 Klaviyo.js (core onsite script)

Klaviyo.js is the primary onsite JavaScript snippet that:

• Powers Active on Site tracking (onsite activity like browsing sessions)
• Enables Klaviyo signup forms to load and function on the site
• Is injected automatically via many ecommerce integrations, or can be manually installed on other platforms

If a customer:

• Wants Klaviyo signup forms on their site
• Wants web tracking / “Active on Site” / product browsing behavior

…then Klaviyo.js (or the equivalent integration-injected script) is required. Removing it will break those features.

Klaviyo’s onsite JavaScript uses first‑party cookies, not third‑party cookies. The script is loaded by the merchant’s site (directly or via a tag manager/app).

2.2 Klaviyo tracking cookies

When Klaviyo’s JavaScript is enabled, Klaviyo sets the __kla_id cookie:

• It tracks and identifies site visitors using an auto-generated ID
• Visitors become identified when they:
  • Submit a Klaviyo signup form
  • Click a link in a Klaviyo email or SMS (with link tracking enabled)
• By default, PII in this cookie is held temporarily for 24 hours, and a fully identified cookie can last up to 2 years (subject to browser restrictions like Safari ITP).

Customers can also opt into Extended ID (more persistent identification) or disable cookies entirely, but this directly impacts tracking and personalization.

3. Types of Klaviyo scripts customers may see

The exact script inventory on a given site may change over time as Klaviyo adds products (e.g., Reviews, Customer Hub) or as the customer enables new features. Internally, it’s more useful to think in categories rather than a fixed list.

3.1 Core web tracking & forms

1. Klaviyo.js / Active on Site snippet

• Provides:
  • Active on Site tracking
  • Web behavior events (e.g., viewed product, viewed category, etc., depending on integration)
  • Underlying plumbing for onsite identification and some feature hooks
• Usually present when:
  • Ecommerce integration is connected (e.g., Shopify, BigCommerce, etc.) and web tracking is enabled
  • Manually installed based on our generic integration docs

2. Signup form loader / forms-related JS

• Provides:
  • Rendering and behavior of Klaviyo onsite signup forms (popups, fly-outs, embedded forms, etc.)
• Usually present when:
  • There are Live or Editing forms in the account (anything not in Draft)

If they don’t use Klaviyo signup forms:

• We advise marking all forms as Draft so that no forms are published on the site.
• Klaviyo.js may still be used for tracking, but not for forms.

3.2 Product‑specific front-end scripts (e.g., Reviews, Customer Hub, etc.)

Newer Klaviyo products that surface widgets onsite (e.g., Reviews display widgets, Customer Hub pages or components) may bring their own product-specific scripts. These:

• Are scoped to that feature (e.g., rendering a reviews widget)
• Often rely on core web tracking (Klaviyo.js) for identification, events, or analytics
• May be loaded via:
  • Dedicated script tags
  • The main Klaviyo bundle, with product features toggled
  • App-embed style configurations (e.g., for Shopify-like platforms)

As product coverage grows, customers may see:

• Multiple script tags referencing static-tracking.klaviyo.com or similar domains used to serve tracking and JS assets
• Additional inline or deferred scripts injected by an app integration

Important: The exact composition of these scripts changes over time as we introduce new products and refactor bundles. For that reason, avoid hard‑coding a specific list of all scripts in static internal or external content; instead, describe them by function (e.g., “core tracking”, “forms”, “reviews display”, “Customer Hub components”).

4. Site speed and PageSpeed: what’s actually happening

4.1 How Klaviyo.js loads

Klaviyo’s JavaScript is loaded asynchronously, meaning:

• It does not block other parts of the page from loading.
• The browser can continue rendering the main content while the Klaviyo script loads in parallel.

However, tools like Google PageSpeed Insights and other site speed audits may still flag Klaviyo’s script as contributing to load times, even though it is asynchronous.

Klaviyo engineers actively work to optimize klaviyo.js and continue to roll out improvements that reduce its footprint and improve performance.

4.2 Shopify-specific note: app embed vs manual snippet

For Shopify:

• We recommend enabling Active on Site tracking through the Klaviyo Shopify app embed, rather than manually installing the script in theme code.
• This often bypasses the store’s native tag manager and can result in faster loading of Klaviyo’s JavaScript.

If a customer has:

• Both the app embed and a manual script
• Or multiple overlapping scripts added by theme customizations or older setup

…we may be able to reduce duplication and thereby improve performance.

5. Required vs. optional: answering “Are all these scripts necessary?”

When a customer asks if all Klaviyo scripts are necessary or if they can remove some, walk through this checklist.

5.1 Clarify what features they use

Ask internally (or the customer):

1. Do they use Klaviyo forms on their website?
2. Do they rely on web tracking:
   • Active on Site
   • Viewed product / browse abandonment
   • Detailed behavioral triggers
3. Are they actively using product‑specific onsite features:
   • Reviews display
   • Customer Hub pages or widgets
   • Other new Klaviyo onsite components

If they use forms and/or web tracking:

• Core Klaviyo.js and forms-related scripts are required. Removing them will:
  • Break onsite forms
  • Remove Active on Site and some web events
  • Reduce the value of flows and segments that depend on that data

If they do not use forms, but want tracking:

• They still need Klaviyo.js for tracking.
• However, you can:
  • Confirm all signup forms in the account are set to Draft, so no forms load on-site.

If they do not want any tracking or web personalization:

• They can choose to disable cookies and/or block tracking domains for compliance or privacy reasons.
• Consequences:
  • No web tracking data (Active on Site, viewed product, etc.)
  • No personalized onsite experiences based on Klaviyo data

Internal guidance: This is a business decision for the customer. We should be clear about trade‑offs, especially around attribution, flows, and segmentation.

5.2 Product-specific scripts

For newer products (Reviews, Customer Hub, etc.):

• If the customer is using those features, the product‑specific scripts are required to render widgets and capture interactions.
• If they are not using a given product’s onsite components:
  • In some cases, we can disable that product’s onsite widgets or configuration so that the additional script is not injected.
  • This is product‑ and integration‑specific; consult the latest product docs, since behavior can change as we iterate.

Because these implementations evolve, do not promise that “we can always remove X script.” Frame it as “we can review which features are enabled and minimize scripts for unused features where supported.”

6. How to handle complex site speed tickets

Some tickets on this topic get very complex (multiple integrations, legacy snippets, heavy theme code, other third parties, ad scripts, etc.). Here is a recommended triage flow.

6.1 Confirm the source and duplication

1. Check integration method:
   • Is Klaviyo connected via a native ecommerce integration?
   • Is there also a manual snippet in theme code or tag manager?
2. Look for duplicates:
   • Multiple instances of the Klaviyo snippet
   • Old klaviyo.js snippets alongside newer app-embed or product-specific loaders
3. Map scripts to features:
   • Which script is loading forms?
   • Which one is used for web tracking?
   • Which ones are tied to Reviews, Customer Hub, or other products?

Outcome: aim to get to one authoritative setup for core tracking/forms and only the minimum product scripts needed.

6.2 Distinguish real performance problems from PageSpeed noise

1. Ask for:
   • Actual user-facing symptoms (slow page load for shoppers? specific devices? specific pages?)
   • Sample URLs and timestamps
2. Compare:
   • PageSpeed/Lighthouse recommendations (which often flag all third-party scripts)
   • Real load times in browser dev tools or RUM analytics, if available

Internal framing:

• It’s expected that PageSpeed will flag most third-party scripts, including ours, even when they load asynchronously.
• Our job is to:
  • Ensure we are not duplicating or misconfigured on the site
  • Help the customer understand the trade‑off between marketing functionality and test scores
  • Highlight ongoing engineering efforts to keep Klaviyo.js lean and performant

6.3 When to escalate

Escalate to Backline when:

• There is strong evidence that:
  • Klaviyo scripts are blocking critical content (e.g., due to incorrect placement or a bug)
  • Klaviyo JS is causing JavaScript errors that break site functionality
• Performance regressions appear after a specific Klaviyo feature rollout or after enabling a new product

Provide:

• Exact URLs and timestamps
• Screenshots
• Clear mapping of:
  • Which scripts are present
  • Which Klaviyo features are in use
  • What the customer is reporting (synthetic score vs real user impact)

7. Privacy, consent, and when customers want “less tracking”

Sometimes “too many scripts” is shorthand for privacy concerns rather than pure performance.

Key points you can use internally (and then adapt externally):

• Klaviyo uses first-party cookies for onsite tracking—data is used for that merchant’s site only, not shared across sites.
• Customers can:
  • Update their cookie notices and privacy policy to explain Klaviyo’s tracking behavior and, if used, Extended ID.
  • Use consent management to block or allow Klaviyo tracking domains per user choice.

If they fully disable Klaviyo tracking JS:

• Klaviyo forms may still load (if configured) but won’t personalize or track behavior.
• They lose granular onsite behavioral data (browsing, viewed product, etc.).

Sources

• Troubleshooting Klaviyo.js and site speed reports
• Klaviyo onsite Javascript and Browser Cookie / iOS 14 Privacy changes