Jak zkrotit third-party skripty: audit a optimalizace v roce 2026

Aktualizováno: 25. června 2026

Third-party skripty zkrotíte tak, že každý z nich nejprve změříte (DevTools → Performance → Third parties), pak ho buď načtete asynchronně, schováte za fasádu, přesunete do Web Workeru pomocí Partytown, nebo úplně vyhodíte. V roce 2026 jsou třetí strany nejčastější příčinou špatného INP a LCP skóre. Typický e-shop tahá 40 až 60 externích domén a každá z nich krade hlavní vlákno. Tenhle návod ukazuje konkrétní techniky, které u nás snížily blokovaný main thread z 1,8 s na 280 ms.

• Třetí strany v průměru způsobují 35 až 50 % Total Blocking Time na produkčních e-shopech podle HTTP Archive 2026.
• Audit začněte v Chrome DevTools (Performance → Bottom-Up → Group by Third Parties) nebo přes WebPageTest „Request Map".
• Tag manažery, chat widgety a A/B testovací nástroje jsou nejčastější viníci špatného INP. Optimizely a Hotjar typicky přidávají 200 až 400 ms na hlavní vlákno.
• Fasády (lazy embeds) pro YouTube, Intercom a Calendly ušetří 300 až 800 KB JavaScriptu na initial load.
• Partytown přesune analytiku do Web Workeru a uvolní hlavní vlákno o 100 až 300 ms na typickém e-shopu.
• Performance budget na third-party (např. max 150 KB JS, max 8 domén) musí být součástí CI, jinak vám marketing pomalu přidá další tag a INP se rozpadne.

Co jsou third-party skripty a proč jsou problém

Third-party skript je jakýkoli JavaScript, CSS, font nebo iframe, který se načítá z domény, kterou nevlastníte. Patří sem Google Tag Manager, Google Analytics, Facebook Pixel, Hotjar, Intercom, Zendesk, Optimizely, Stripe.js, Cloudflare Turnstile, vložená YouTube videa, mapy, písma z Google Fonts a stovky dalších. Letos jsem dělal audit pro středně velký český e-shop a napočítal jsem 47 externích domén. Z toho 31 přidaných marketingovým týmem za posledních 18 měsíců, aniž by si toho někdo všiml.

Problém není v jednotlivém skriptu, ale v jejich kumulaci. Každý request spotřebuje TCP/TLS handshake, parsing, kompilaci a exekuci na hlavním vlákně. Když máte na stránce 40 třetích stran, váš JavaScript bundle bojuje s nimi o stejnou frontu. Web.dev guide on third-party JavaScript uvádí, že medián mobilního webu stráví 1,8 sekundy parsováním third-party JS. To je celý budget pro Time to Interactive.

U Core Web Vitals se nejvíc projevují na INP (Interaction to Next Paint), protože chat widgety a A/B testovací nástroje běžně přidávají 200+ ms dlouhých tasků při každém kliknutí. Na LCP útočí blokováním render-critical resources a u CLS způsobují skoky, když se vloží opožděně (typicky cookie banner nebo „doporučené produkty" widget). Pokud váš web pokulhává hlavně v INP, mrkněte ještě na náš návod jak opravit špatné INP skóre, ten řeší i input delay z pohledu vlastního kódu.

Jak najít všechny third-party skripty na webu

Než cokoli optimalizujete, potřebujete úplný inventář. Doporučuju tři komplementární nástroje, protože každý ukáže něco jiného:

1. Chrome DevTools → Network → Domains: otevřete dev tools, načtěte stránku, ve sloupci Name klikněte pravým tlačítkem a přidejte sloupec „Domain". Seřaďte podle domény. Cokoli, co není vaše doména nebo CDN, je třetí strana.
2. Chrome DevTools → Performance → Bottom-Up → Group by Third Parties: nahrajte 5 sekund interakce a Chrome rovnou rozdělí blokovaný čas podle entity (Google Tag Manager, Facebook, atd.).
3. WebPageTest „Request Map": vizuální graf, který ukáže, kdo koho volá. Často objevíte, že GTM tahá dalších 12 skriptů, o kterých nevíte.

Pro CI/CD doporučuju automatizovat detekci přes Lighthouse CI. Tady je konfigurace, kterou používám:

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      url: ['https://example.com/', 'https://example.com/produkt/abc'],
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        // Audit „third-party-summary" vrací seznam entit a jejich blokovací čas
        'third-party-summary': ['error', { maxNumericValue: 250 }],
        'bootup-time': ['error', { maxNumericValue: 2000 }],
        'mainthread-work-breakdown': ['warn', { maxNumericValue: 3000 }],
      },
    },
    upload: { target: 'temporary-public-storage' },
  },
};

Pro hloubkový audit si přečtěte i náš návod jak snížit TTFB pod 200 ms. Řada technik tam popsaných (zejména DNS pre-resolution a connection coalescing) má vedlejší efekt právě na třetí strany.

Jak změřit reálný dopad na INP a LCP

Lab data (Lighthouse) lžou, protože spouští z čistého stavu bez cache. Real-user monitoring (RUM) přes web-vitals knihovnu ukáže skutečnost. Tady je minimální RUM, který izoluje vliv třetích stran na INP:

import { onINP, onLCP } from 'web-vitals/attribution';

onINP((metric) => {
  // attribution.eventEntry obsahuje target element a script attribution
  const attr = metric.attribution;
  const longestScript = attr.longAnimationFrameEntries
    ?.flatMap(f => f.scripts || [])
    .sort((a, b) => b.duration - a.duration)[0];

  navigator.sendBeacon('/rum', JSON.stringify({
    metric: 'INP',
    value: metric.value,
    target: attr.interactionTargetElement,
    // Klíčová informace: jméno souboru a doména skriptu, který nejdéle blokoval
    blockingScript: longestScript?.sourceURL,
    blockingDuration: longestScript?.duration,
  }));
});

onLCP((metric) => {
  const attr = metric.attribution;
  navigator.sendBeacon('/rum', JSON.stringify({
    metric: 'LCP',
    value: metric.value,
    element: attr.element,
    // resourceLoadDelay zachytí, jak dlouho čekal LCP element kvůli třetím stranám
    resourceLoadDelay: attr.resourceLoadDelay,
    elementRenderDelay: attr.elementRenderDelay,
  }));
});

Po týdnu sběru dat seřaďte v dashboardu hlasy podle blockingScript. Upřímně, u mého posledního klienta vyšlo, že 62 % INP regresí způsoboval jeden konkrétní A/B testovací nástroj, který produkťák ani nechtěl, jen ho zapomněli vypnout po Q1 experimentu. Tohle je přesně ten typ nálezu, který bez RUM nikdy neuvidíte.

Načítací strategie: async, defer, fasády

Jakmile máte seznam viníků, rozhodněte se pro každý zvlášť, jak ho načítat. Mám pro to čtyřstupňovou rozhodovací matici:

Strategie	Kdy použít	Šetří main thread	Riziko
async	Skript nemá závislosti a může běžet kdykoli (analytika)	Středně, pořád běží na main threadu	Pořadí spuštění není zaručeno
defer	Skript potřebuje DOM, ale ne v kritické cestě (komentáře, chat)	Středně, počká na DOMContentLoaded	Pomalejší TTI, pokud je skript velký
Fasáda (lazy embed)	Embedy s vlastním UI (YouTube, Intercom, Calendly)	Vysoce, 100 % šetření dokud uživatel nekliknul	Mírně horší UX při prvním kliknutí
Partytown / Web Worker	Analytika, tag manager, A/B testy	Velmi vysoce, odsune mimo main thread	Skript nesmí používat DOM API přímo
Self-hosting	Fonty, analytika typu Plausible, error tracking	Nízce, ale uloží connection cost	Musíte udržovat update cyklus

Fasáda pro YouTube embed

YouTube iframe tahá 540 KB JavaScriptu, i když uživatel video nikdy nespustí. Fasáda zobrazí náhledový obrázek a teprve po kliknutí načte celý player. Praktický příklad přes lite-youtube-embed:

<!-- místo <iframe src="https://youtube.com/embed/VIDEO_ID"> -->
<lite-youtube videoid="VIDEO_ID" playlabel="Přehrát video"></lite-youtube>

<script type="module">
  import 'https://cdn.jsdelivr.net/npm/[email protected]/src/lite-yt-embed.js';
</script>
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/[email protected]/src/lite-yt-embed.css">

Podobné fasády existují pro Vimeo (lite-vimeo), Intercom (react-intercom-facade) a Calendly (vlastní implementace s <img> placeholderem a kliknutím na load). Na typickém marketing webu fasády ušetří 800 KB až 1,2 MB initial JavaScriptu.

Partytown: přesun skriptů do Web Workeru

Partytown je knihovna od týmu Builder.io, která spustí third-party skripty ve Web Workeru a synchronně proxiuje volání DOM API přes Service Worker. Pro Google Tag Manager, GA4, Facebook Pixel a Hotjar to znamená, že přestanou blokovat hlavní vlákno úplně. Já vím, zní to skoro moc dobře. V praxi to ale opravdu funguje, jen s pár omezeními, která zmíním níž.

Setup v Next.js 15 aplikaci:

// app/layout.tsx
import Script from 'next/script';

export default function RootLayout({ children }) {
  return (
    <html>
      <head>
        <Script
          id="partytown-config"
          strategy="beforeInteractive"
          dangerouslySetInnerHTML={{
            __html: `
              partytown = {
                forward: ['dataLayer.push', 'gtag', 'fbq'],
                lib: '/~partytown/',
                debug: false,
              };
            `,
          }}
        />
        <Script
          src="https://cdn.jsdelivr.net/npm/@builder.io/[email protected]/lib/partytown.js"
          strategy="beforeInteractive"
        />
        {/* GTM se teď načte na worker threadu */}
        <Script
          id="gtm"
          type="text/partytown"
          dangerouslySetInnerHTML={{
            __html: `
              (function(w,d,s,l,i){...GTM snippet...})
              (window,document,'script','dataLayer','GTM-XXXXXX');
            `,
          }}
        />
      </head>
      <body>{children}</body>
    </html>
  );
}

Self-hosting fontů, analytiky a tag manažeru

Každá externí doména rovná se jeden DNS lookup plus TLS handshake, dohromady 100 až 300 ms navíc. Self-hosting odstraní tuhle režii a zároveň vám dává kontrolu nad cache-control hlavičkami. Tři kandidáti, kde se to vyplatí:

1. Google Fonts: stáhněte přes google-webfonts-helper, hostujte na svém CDN s Cache-Control: public, max-age=31536000, immutable. Ušetříte cca 80 až 120 ms FOIT/FOUT na první návštěvě.
2. Plausible / Umami analytika: namísto plausible.io/js/script.js nasaďte vlastní instanci nebo proxy. Bonus: ad-blockery vám neblokují měření.
3. Google Tag Manager Server-Side: hostujte GTM endpoint na svém subdoméně (tags.example.com). Sníží to počet 3rd-party requestů z 8 až 12 na 1 a umožní vám filtrovat události před odesláním do Googlu.

Pro fonty kombinujte self-hosting s font-display: swap a preloadem. Detailní postup popisuju v článku jak zlepšit LCP skóre v roce 2026, sekce o webfontech tam pokrývá CSS i preload taktiku.

Consent-gated loading a GDPR jako příležitost

GDPR a EU AI Act 2026 vyžadují explicitní souhlas s tracking cookies. Většina e-shopů řeší souhlas tak, že načte GTM a všechny skripty hned a teprve potom čeká na souhlas. To je ten nejhorší možný přístup, protože platíte performance penalty i pro uživatele, kteří odmítnou. Správný přístup: skripty se načítají pomocí onConsentGranted callbacku:

// Kategorie marketing a analytika načítáme až po souhlasu
window.__consent = window.__consent || { marketing: false, analytics: false };

function loadAnalytics() {
  if (window.__consent.analytics) return;
  window.__consent.analytics = true;
  const s = document.createElement('script');
  s.src = '/proxy/plausible.js';
  s.defer = true;
  s.dataset.domain = 'example.com';
  document.head.appendChild(s);
}

function loadMarketing() {
  if (window.__consent.marketing) return;
  window.__consent.marketing = true;
  // GTM s Partytown strategií
  const s = document.createElement('script');
  s.type = 'text/partytown';
  s.textContent = `(function(w,d,s,l,i){...})(window,document,'script','dataLayer','GTM-XXXXXX');`;
  document.head.appendChild(s);
}

// Konzent banner volá tyto funkce, ne hned při onload
document.addEventListener('cookieConsentChange', (e) => {
  if (e.detail.analytics) loadAnalytics();
  if (e.detail.marketing) loadMarketing();
});

Vedlejší benefit: uživatelé, kteří odmítnou, dostanou rychlou stránku zdarma. Náš e-shop měl 38 % opt-out rate a u téhle skupiny se po nasazení consent-gatingu zlepšil INP o 240 ms v 75. percentilu. Jinými slovy: GDPR vám pomůže s výkonem, pokud ho přestanete vnímat jen jako otravnou regulaci.

Performance budget pro třetí strany

Bez budgetu se vám marketing pomalu znovu rozšíří. Třetí strany jsou jako plevel. Uvolníte zahradu a za tři měsíce máte 12 nových tagů. Konkrétní budget, který nasazuju u klientů:

• Max 150 KB third-party JavaScriptu (gzipped) na initial pageload
• Max 8 unikátních third-party domén
• Max 200 ms Total Blocking Time od třetích stran (Lighthouse)
• Žádný third-party skript se synchronním tagem v <head>

Vynucujte to v CI přes size-limit nebo Lighthouse CI assertions z dřívější sekce. Když někdo přidá Hotjar, build spadne a musí pro něj uvolnit místo (např. tím, že odstraní starý A/B testovací nástroj). Stejnou logiku popisuje detailněji článek jak opravit CLS. Performance budgety jsou jediný způsob, jak udržet skóre dlouhodobě.

Jmenovitě: nejhorší skripty roku 2026

Podle dat HTTP Archive z června 2026 jsou nejčastější příčiny pomalého INP tyto skripty (jméno plus medián blokovacího času na hlavním vlákně):

• Optimizely (380 ms): A/B testovací nástroj, který běží synchronně před paintem kvůli anti-flicker. Alternativa: GrowthBook se server-side rozhodováním.
• Hotjar (290 ms): recording skript. Sampling na 10 % traffic a load až po interakci sníží dopad o 80 %.
• Drift / Intercom chat (240 ms): fasáda s lazy loadem po kliknutí na chat ikonu je téměř vždy správná odpověď.
• Google Tag Manager s 20+ tagy (210 ms): Partytown plus audit nepoužívaných tagů (typicky 30 až 40 % v GTM containeru jsou mrtvé).
• Klaviyo / Mailchimp newsletter popupy (180 ms): load až po prvním scrollu, ne v <head>.
• Facebook Pixel (150 ms): přes Partytown a server-side Conversions API máte stejná data za zlomek performance ceny.

Často kladené otázky

Co je to third-party skript a proč škodí výkonu?

Third-party skript je JavaScript, CSS nebo iframe načítaný z domény, kterou nevlastníte (GTM, GA, Facebook Pixel, chat widgety). Škodí výkonu, protože blokuje hlavní vlákno během parsování a exekuce, přidává DNS/TLS handshake na každou doménu a často provádí drahé operace při uživatelských interakcích, což přímo zhoršuje INP a LCP.

Jak najdu všechny third-party skripty na svém webu?

Použijte Chrome DevTools → Network panel s přidaným sloupcem „Domain", nebo Performance → Bottom-Up → Group by Third Parties. Pro vizuální mapu volání použijte WebPageTest „Request Map". V CI nasaďte Lighthouse CI s assertion na third-party-summary.

Jsou third-party skripty špatné pro SEO?

Ano, nepřímo. Google používá Core Web Vitals (LCP, INP, CLS) jako ranking signál a pomalé třetí strany jsou nejčastější příčinou špatných CWV. Audity od roku 2025 ukazují, že weby v top 10 SERPů mají v průměru o 40 % méně third-party requestů než weby na pozici 11 až 20.

Co je Partytown a kdy se vyplatí?

Partytown je open-source knihovna, která spouští třetí strany ve Web Workeru a synchronně proxiuje volání DOM API přes Service Worker. Vyplatí se pro GTM, GA4, Facebook Pixel a Hotjar. Nevyplatí se pro anti-flicker A/B testy nebo skripty, které musí běžet před prvním paintem.

Mám si self-hostovat Google Fonts?

V roce 2026 ano, prakticky vždy. Self-hosting odstraní třetí stranu (jeden DNS/TLS handshake), umožní agresivní cache-control hlavičky a zlepší LCP o 80 až 150 ms na první návštěvě. Použijte google-webfonts-helper na stažení a kombinujte s font-display: swap plus <link rel="preload">.