Appearance

Performance & SEO ​

In short

  • Loading: a small loader in the <head> adds the script while the page keeps loading. About 25 KB compressed, about 5 ms to run.
  • No flicker: only the elements a test changes wait for their variant, never the whole page.
  • If Dalton is down: your page loads as normal with the original.
  • SEO: search engines get your original page.
  • Measured: 10 Lighthouse runs with and without Dalton showed no difference beyond noise.

The script at a glance ​

Sizeabout 25 KB compressed (gzip), about 84 KB uncompressed. The same file for every site: your tests are loaded separately, so adding tests does not make the script bigger
Load timeunder 50 ms on a typical connection, then served from the browser cache
Execution timeabout 5 ms
How it loadsa small inline loader in the <head> adds the script; it does not block rendering
Connectionthe snippet preconnects to both Dalton domains so the connection is open early
Anti-flickeron by default, hides only the elements a test changes, never the whole page
Bots and crawlersknown crawlers and automated browsers are skipped and get your original page
Repeat visitsthe visitor's assigned variants are cached in browser storage for 24 hours

You copy the snippet from Connectors → Tracking → Dalton Script in Dalton. The install panel has tabs for JavaScript, Shopify, Wix, Elementor, React, Next.js and NuxtJS, and the anti-flicker setting.

html
<!-- Dalton Personalization Script -->
<link rel="preconnect" href="https://cdn.getdalton.com" />
<link rel="preconnect" href="https://global.dalton-cdn.com" />
<script id="dalton-installation-script">
  const DALTON_ID=YOUR-ID;
  const DALTON_CONFIG={customer_id: DALTON_ID};

  (function(d,a,l,t,o,n) {
    if (d.getElementById(t)) return;
    var js = d.createElement(a);
    js.id = t;
    js.async = false;
    var u = 'https://cdn.getdalton.com/' + o + '.min.js?' + Object.keys(n).map(function(k){return k+'='+encodeURIComponent(n[k])}).join('&');
    js.src = u;
    d.getElementsByTagName(l)[0].appendChild(js);
  })(document, 'script', 'head', 'dalton-sdk', DALTON_ID, DALTON_CONFIG);
</script>

js.async = false only keeps scripts in order. Because the loader inserts the script from JavaScript, it does not block rendering.

What we measured ​

We ran Lighthouse 10 times with Dalton and 10 times with the Dalton script blocked, on the production site of a European fashion retailer. Desktop, unthrottled. This measures the cost of loading the script on every page: Lighthouse identifies itself as an automated browser, which Dalton skips like a crawler, so applying a test is not part of it. To see a running test, preview it in a normal browser or watch field data (Check it on your own site). The site's pages are built by JavaScript in the browser, with no tests running above the fold.

Medians, with the range across the 10 runs:

MetricWithout DaltonWith DaltonDifference
Performance score99 (98-100)99 (98-100)0
First Contentful Paint425 ms (302-498)404 ms (290-518)-21 ms
Largest Contentful Paint929 ms (793-1,031)895 ms (767-1,009)-34 ms
Total Blocking Time1 ms (0-101)13 ms (0-58)+12 ms
Speed Index821 ms (706-901)790 ms (679-901)-31 ms
Range and median of 10 Lighthouse runs without and with Dalton, for FCP, LCP and Speed Index. The ranges overlap almost completely.10 runs each. Bar = range from fastest to slowest run, dot = median.Without DaltonWith DaltonFirst Contentful Paint425 ms404 msSpeed Index821 ms790 msLargest Contentful Paint929 ms895 ms0250 ms500 ms750 ms1,000 ms
  • The differences are within noise. Runs of the same setup already differ by about 200 ms from fastest to slowest.
  • Dalton does not make the page faster: the negative differences are run-to-run noise.
  • The chart is ordered by when each metric happens in the page load.
  • On a throttled slow-mobile profile, over 10 runs, the same site scored 65 without Dalton and 64 with it.

How a page loads with Dalton ​

What a visitor in the variant group sees. Without anti-flicker: the original tested element shows, then swaps to the variant. With a blocking script or page-wide hiding: the page stays blank until the testing script has run. Dalton: the page shows as normal; only the tested element waits a moment for its variant.No anti-flickerRest of the pageTested element, originalTested element, variantOriginal shows,then swapsPage waitsblocking script, orpage-wide hidingBlankRest of the pageBlankTested element, variantPage appears oncethe script has runDalton (Default)Rest of the pageTested element, variantPage as normal,no swap
  • How it loads: a small inline loader in the <head> adds the Dalton script. The browser keeps building and painting the page while it downloads, so the script does not block rendering.
  • Anti-flicker: the elements a test changes stay hidden until the variant is applied, then fade in over 0.2 s. Everything else renders normally. Most client-side testing tools prevent flicker either by blocking the page until their script has loaded, or by hiding the whole page until it has run, usually with a timeout of 0.5 to 4 seconds. Whole-page hiding has been measured delaying first paint and Largest Contentful Paint by seconds (SpeedCurve, DebugBear). As a safety net, an element is shown after 1 second even if the variant has not arrived.
  • Why high in the <head>: the earlier the script arrives, the sooner tested elements are ready. If it arrives after the page has rendered, anti-flicker is skipped and a change can be visible. That is also why we advise against installing through a tag manager.

Anti-flicker settings ​

Set this in the install panel. It changes one value in the snippet.

SettingWhat it doesWhen to use it
DefaultHides only the elements a test changes until the variant is applied, then fades them in.Most sites.
DisabledNothing is hidden. Adds skip_af: true to the snippet.When any hiding is unacceptable and a brief swap is fine.

There is also an Extensive setting. It works like the page-wide hiding many testing tools use by default: it hides the text, images and buttons in the visible part of the page from the first paint and shows them about 1 second later. Use it only if Default still shows a swap on your site, since it delays first paint and LCP by about a second.

Reliability ​

  • If Dalton is slow or unavailable, your page loads as normal. The loader does not block rendering, and with the Default setting nothing is hidden until the Dalton script has run. Visitors see your original page and no test runs.
  • Hidden elements are released after 1 second at most, even if the variant has not arrived.
  • The script is served from a global edge network with several cache layers. Returning visitors load it from their browser cache.
  • Pausing a test in the Dalton app stops it for all visitors.
  • An uptime SLA is not part of standard agreements, and your site does not depend on one: if Dalton is down, your original page loads as normal.

Platforms ​

  • Shopify: add the snippet at the top of the <head> in theme.liquid. See the Shopify tab in the install panel. A Dalton Shopify app is in review; ask us for early access.
  • Next.js, React and other single-page apps: on Next.js, Dalton re-applies changes after hydration and on client-side navigation automatically. On other React or single-page sites, turn on Reapply changes under Options in the install panel.
  • Any other platform: paste the snippet as high as possible in the <head> of every page.

Core Web Vitals in one minute ​

What each metric measures, and Google's thresholds

Google's Core Web Vitals are LCP, INP and CLS. FCP and TBT are supporting metrics that Lighthouse also reports. The targets are Google's "good" thresholds, met at the 75th percentile of real visits (TBT is measured in the lab only).

MetricWhat it measuresGood
First Contentful Paint (FCP)when the first text or image appears1.8 s or less
Largest Contentful Paint (LCP)when the main content (usually the hero image or headline) appears2.5 s or less
Interaction to Next Paint (INP)how quickly the page responds to clicks and taps200 ms or less
Cumulative Layout Shift (CLS)how much content jumps around while loading0.1 or less
Total Blocking Time (TBT)time the browser is too busy to respond to input (lab only)200 ms or less
Speed Indexhow quickly the visible page fills in (lab only)lower is better

Lab data versus field data. Lighthouse, and the lower half of PageSpeed Insights, run a simulated visit: that is lab data, good for comparing two setups. Google's page experience signals use field data from real Chrome users (the Chrome UX Report, shown at the top of PageSpeed Insights). The two often differ, and field data is the one Google uses.

Impact per metric ​

The script itself is small. What a test changes on the page usually matters more than the script, so most of the advice below is about the tests.

FCP and LCP ​

What can affect them: the script does not delay first paint. If a test changes the page's largest element, such as the hero, LCP waits until the variant is applied. A test that replaces that element, such as a new hero image, also changes LCP through the new image.

What to do: keep the snippet at the top of the <head>, installed directly rather than through Google Tag Manager, with both preconnect lines. Compress and size any image you add in a variant, and prefer changing an existing image's source over adding a second large image.

INP ​

What can affect it: the script's own work is about 5 ms at page load, so it does not compete with clicks. A variant with custom JavaScript that runs on clicks or scrolling can.

What to do: keep variant code light. If INP rises during a test, preview the page with and without that test to find the cause.

CLS ​

What can affect it: the script does not move content. A variant that inserts content after the page has loaded, for example once a widget appears, can push content down. Inserted content only counts as a shift if it moves something that was already visible.

What to do: give inserted elements a fixed height, or place them where they do not push existing content.

Check it on your own site ​

Lighthouse and PageSpeed Insights load the script, but Dalton skips those visits like it does for crawlers. Lab scores show the cost of loading the script; field data shows the effect of tests on real visitors.

1. Check when the script starts ​

In Chrome DevTools, open the Network tab and reload. The Dalton script should be one of the first requests. If it starts late, move the snippet higher in the <head>, and make sure it is not loaded through a tag manager.

Show where to look in the Network tab
Illustration of the Chrome DevTools Network tab: the Dalton script is requested right after the HTML document, before the site's own CSS, JavaScript and images.NetworkAll · Doc · CSS · JS · Img · FetchIllustrationNameTypeSizeTimeWaterfallwww.yourstore.comdocument18 kB120 mscdn.getdalton.com/YOUR-ID.min.jsscript25 kB38 msstyles.cssstylesheet42 kB64 msapp.jsscript96 kB140 msglobal.dalton-cdn.com/api/datafetch2 kB41 mshero.webpimage180 kB210 msLook for the Dalton script right after your HTML document.If it starts after your other scripts, or much later in the load, move the snippet up in the <head>.

2. Measure the loading cost ​

Run Lighthouse at least 10 times with Dalton and 10 times with the script blocked, then compare medians. Block it in DevTools under Network → Request blocking with the pattern *dalton*, or with the Lighthouse CLI flag --blocked-url-patterns="*dalton*". A single run says very little: the same page can score noticeably differently from one run to the next, as the ranges above show.

Show the request blocking panel
Illustration of the Chrome DevTools Network request blocking panel with the pattern *dalton* enabled.Network request blockingIllustrationEnable network request blocking*dalton*blocks both Dalton requestsReload and run Lighthouse with the pattern on, then again with it off. Compare the medians, not single runs.

3. Watch field data ​

Compare the Core Web Vitals in PageSpeed Insights or Search Console for the four weeks before and after you install Dalton.

We are happy to run this with your team on a staging environment.

Keep tests fast ​

  • Install the snippet directly in the <head>, as high as possible, not through Google Tag Manager.
  • Keep both preconnect lines.
  • Keep variant code focused: change what the test is about and nothing more.
  • Size and compress images you add in a variant.
  • Avoid variants that insert content above existing content after the page has loaded.
  • Conclude tests you are no longer learning from, and build winning changes into your site's own code when you can. Deployed winners are served by the Dalton script: search engines don't see them, and they disappear if you remove the script.

SEO ​

Dalton does not run for search engine crawlers, so Google sees your original page: the same page visitors in the control group see. An A/B test changes the page in place: no hidden elements, no separate URLs, no redirects. URL split tests, which send part of the visitors to a second URL, are the one exception. This matches Google's guidance on website testing: the same URLs for Googlebot and visitors, and remove test code once a test is concluded.

Security ​

Data is encrypted in transit and at rest, production access requires multi-factor authentication, and Dalton is scanned and penetration-tested via Aikido. Details, certifications and data location: Privacy & security.