Πρακτικός οδηγός για να δαμάσεις analytics, διαφημίσεις και chat widgets: defer, facades, Partytown, fetchpriority και LoAF monitoring με πραγματικά παραδείγματα από production e-commerce.
Ενημερώθηκε: 3 Ιουλίου 2026
Η βελτιστοποίηση third-party scripts σημαίνει να ελέγχεις πότε, πώς και αν φορτώνονται εξωτερικά scripts (analytics, διαφημίσεις, chat widgets, A/B testing) ώστε να μην καταστρέφουν τα Core Web Vitals της σελίδας σου. Στα e-commerce sites που δουλεύω, τα third-party scripts ευθύνονται τυπικά για το 40–70% του συνολικού JavaScript execution time, και είναι ο κυριότερος λόγος που το INP και το LCP «σκάνε» στο πεδίο ενώ φαίνονται πράσινα στο Lighthouse.
async δεν φτάνει: για tags που δεν τρέχουν στην πρώτη οθόνη χρειάζεσαι defer, facade patterns ή Partytown.fetchpriority="low" στα script tags είναι πλέον υποστηριζόμενο σε Chromium 121+ και μειώνει το network contention με το LCP resource.Πριν αρχίσεις να κόβεις scripts, χρειάζεσαι δεδομένα. Το Lighthouse σου δίνει την ενότητα «Reduce the impact of third-party code», αλλά η τιμή που βλέπεις είναι lab-based και σχεδόν πάντα υποεκτιμά την πραγματική επίδραση σε mobile hardware. Στη δουλειά μου, το πρώτο πράγμα που κάνω σε κάθε audit είναι να τρέξω WebPageTest με throttling «Motorola G4 - 3G Fast» και να ανοίξω το Waterfall με την επιλογή «Highlight requests from third-party domains».
Ένα πιο ακριβές νούμερο έρχεται από field data. Χρησιμοποιώ την βιβλιοθήκη web-vitals.js για Real User Monitoring με ένα custom attribution layer που κρατάει το sourceUrl της εντολής JavaScript που προκάλεσε το longest input delay. Έτσι, όταν δεις ένα INP των 480 ms στο checkout, ξέρεις ότι φταίει το gtm.js ή το hotjar.js, όχι απλά «κάτι στο main thread».
Ένα εργαλείο που συνιστώ ανεπιφύλακτα είναι το Request Map Generator. Δείχνει οπτικά ποιο third-party script φορτώνει άλλο third-party script (τα λεγόμενα «piggyback tags»). Σε ένα e-commerce project είχαμε 27 tags που κανείς στην εταιρεία δεν ήξερε ότι υπήρχαν. Φορτώνονταν, όπως ανακαλύψαμε τελικά, από ένα ad network που το marketing είχε βάλει το 2021 και όλοι το είχαν ξεχάσει.
Το πιο κοινό λάθος που βλέπω σε production e-commerce sites είναι να χρησιμοποιούν async για κάθε third-party script γιατί «το είπε το Lighthouse». Το async λέει στον browser: «κατέβασέ το παράλληλα, αλλά μόλις έρθει τρέξε το ΤΩΡΑ». Αν αυτό συμβεί την ώρα που ο χρήστης προσπαθεί να πατήσει «Add to cart», βλέπεις INP των 700 ms. Έτυχε να κυνηγήσω αυτό ακριβώς το bug τρεις φορές μέσα σε ένα εξάμηνο.
<!-- ΛΑΘΟΣ: μπλοκάρει το main thread όποτε νά ‘ναι -->
<script async src="https://cdn.example.com/analytics.js"></script>
<!-- ΣΩΣΤΟ για analytics: defer, εκτελείται μετά το parsing -->
<script defer src="https://cdn.example.com/analytics.js"></script>
<!-- ΑΚΟΜΑ ΚΑΛΥΤΕΡΟ: module + defer by default σε evergreen browsers -->
<script type="module" src="/js/analytics-modern.js"></script>
<script nomodule defer src="/js/analytics-legacy.js"></script>Ο πίνακας παρακάτω συνοψίζει τη συμπεριφορά:
| Χαρακτηριστικό | async | defer | type="module" |
|---|---|---|---|
| Download παράλληλα με parsing | Ναι | Ναι | Ναι |
| Εκτέλεση μετά DOMContentLoaded | Όχι | Ναι | Ναι (defer by default) |
| Διατηρεί τη σειρά εκτέλεσης | Όχι | Ναι | Ναι |
| Καλό για analytics / tracking | Οριακά | Ναι | Ναι |
| Καλό για ad networks | Όχι πλέον | Ναι με facade | Ναι |
| Επίπτωση σε INP | Υψηλή | Χαμηλή | Χαμηλή |
Ένα YouTube embed φέρνει περίπου 540 KB JavaScript. Ένα Intercom chat widget φέρνει 380 KB. Ένα Zendesk widget 720 KB. Αν έχεις τρία τέτοια στην ίδια σελίδα, ξεκίνησες με 1,6 MB third-party JS πριν καν φορτώσει το προϊόν σου. Το facade pattern λύνει αυτό το πρόβλημα δείχνοντας μια στατική εικόνα ή HTML placeholder που «μοιάζει» με το widget, και φορτώνει το πραγματικό script μόνο όταν ο χρήστης αλληλεπιδράσει.
<!-- Facade για YouTube embed -->
<div class="yt-facade" data-video-id="dQw4w9WgXcQ">
<img src="https://i.ytimg.com/vi/dQw4w9WgXcQ/hqdefault.jpg"
alt="Play video" width="480" height="270" loading="lazy">
<button aria-label="Play video" class="yt-play-btn">▶</button>
</div>
<script>
document.querySelectorAll('.yt-facade').forEach(facade => {
facade.addEventListener('click', () => {
const id = facade.dataset.videoId;
const iframe = document.createElement('iframe');
iframe.src = `https://www.youtube-nocookie.com/embed/${id}?autoplay=1`;
iframe.allow = 'autoplay; encrypted-media';
iframe.allowFullscreen = true;
facade.replaceWith(iframe);
}, { once: true });
});
</script>Για το Intercom έχω γράψει έναν wrapper που εμφανίζει μόνο ένα κουμπί «Chat» με CSS animation. Το πραγματικό Intercom SDK φορτώνεται με import() dynamic όταν ο χρήστης πατήσει το κουμπί ή σκρολλάρει κάτω από το 50% της σελίδας, όποιο συμβεί πρώτο. Απλή ιδέα, αλλά κερδίζεις σταθερά 300 ms στο TTI σε mid-range Android.
Το Partytown από το Builder.io είναι μια βιβλιοθήκη που τρέχει third-party scripts μέσα σε ένα Web Worker, ελευθερώνοντας εντελώς το main thread. Είναι κατάλληλο για Google Tag Manager, Facebook Pixel, TikTok Pixel, και όλα τα «fire-and-forget» tracking scripts που δεν χρειάζονται άμεση πρόσβαση στο DOM.
Στην πρώτη μεγάλη μετάβαση που έκανα (ένα fashion e-commerce με ~2M sessions/μήνα), το Partytown έπεσε το TBT από 2.100 ms σε 640 ms σε mid-range Android. Το INP βελτιώθηκε από 380 ms σε 190 ms. Αλλά, ειλικρινά, υπάρχουν footguns και έφαγα δύο εβδομάδες debugging πριν βγει σταθερό.
// Ρύθμιση Partytown με Next.js 15
// app/layout.tsx
import { Partytown } from '@builder.io/partytown/react';
export default function RootLayout({ children }) {
return (
<html>
<head>
<Partytown
debug={false}
forward={['dataLayer.push', 'fbq', 'gtag']}
resolveUrl={(url) => {
// Reverse proxy για να παρακάμψουμε CORS
if (url.hostname === 'www.googletagmanager.com') {
return new URL(`/proxy/gtm${url.pathname}`, location.href);
}
return url;
}}
/>
<script type="text/partytown" src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX" />
</head>
<body>{children}</body>
</html>
);
}Το Google Tag Manager είναι το «Trojan horse» της απόδοσης. Φαίνεται μικρό (55 KB gzipped) αλλά ο container σου συνήθως φέρνει 15–40 άλλα tags. Το χειρότερο; Το marketing team μπορεί να προσθέσει tags χωρίς code review, οπότε ένα Monday morning βλέπεις το LCP να έχει πέσει 800 ms και δεν ξέρεις γιατί. Το έχω ζήσει, δεν είναι ευχάριστο.
Η στρατηγική που εφαρμόζω σε production:
data.example.com) και ο server προωθεί σε Google, Meta, TikTok. Το client-side JS πέφτει από 300 KB σε 20 KB.consent events στο GTM. Πριν το consent, μόνο anonymized pings στέλνονται. Αυτό συμμορφώνεται με τους κανονισμούς του GDPR και μειώνει το initial JS.Ειρωνικά, το ίδιο το CMP είναι συχνά το μεγαλύτερο performance hit. Το OneTrust φέρνει 250 KB. Το Cookiebot 180 KB. Το Didomi 130 KB. Και συνήθως είναι render-blocking επειδή πρέπει να ξέρεις consent status πριν φορτώσεις οτιδήποτε άλλο. Δύο πράγματα βοηθούν: (α) αυτο-φιλοξένησε το CMP script σε δικό σου CDN, (β) χρησιμοποίησε <link rel="preload"> για το CMP και βάλε το πρώτο στο <head>.
Το fetchpriority attribute είναι σχετικά νέο (baseline στο Chromium 121, Safari 17.2, Firefox 132) αλλά κάνει τεράστια διαφορά σε third-party scripts. Λες στον browser: «αυτό το script είναι χαμηλής προτεραιότητας, μην το ανταγωνίζεσαι με το LCP resource μου». Περισσότερες πληροφορίες θα βρεις στα MDN docs για το fetchpriority.
<!-- LCP hero image: υψηλή προτεραιότητα -->
<img src="/hero.avif" fetchpriority="high" width="1200" height="600" alt="">
<!-- Analytics: χαμηλή προτεραιότητα, εκτός network critical path -->
<script defer fetchpriority="low"
src="https://cdn.example.com/analytics.js"></script>
<!-- Third-party font από Google Fonts: preconnect -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- DNS lookup για third-party domain -->
<link rel="dns-prefetch" href="https://www.googletagmanager.com">
<!-- Speculation Rules για prefetch της επόμενης σελίδας -->
<script type="speculationrules">
{
"prefetch": [{ "source": "document", "where": { "href_matches": "/product/*" }, "eagerness": "moderate" }]
}
</script>Το Speculation Rules API (Chromium 121+) είναι ιδιαίτερα ισχυρό για e-commerce όπου ο χρήστης συνήθως πλοηγείται σε πολλές σελίδες προϊόντος. Prefetching της επόμενης σελίδας κάνει το third-party JS να «εκτελείται εκ των προτέρων» χωρίς να επηρεάζει την τρέχουσα σελίδα. Και ναι, το έχω δοκιμάσει σε production, δουλεύει.
Η Long Animation Frames API (LoAF) διαθέσιμη από Chromium 123 αντικαθιστά τη Long Tasks API με πολύ πιο πλούσια δεδομένα. Πλέον μπορείς να δεις ποιο ακριβώς script blocked το frame, ποια CSS animations έγιναν rendered, και ποιες forced synchronous layouts συνέβησαν. Πρόσφατα το χρησιμοποίησα για να βρω ότι ένα Segment SDK έκανε 47 forced reflows μέσα σε 300 ms.
// Attribution third-party scripts μέσω LoAF
if ('PerformanceObserver' in window) {
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (entry.duration > 50) {
entry.scripts.forEach(script => {
const url = new URL(script.sourceURL || location.href);
if (url.origin !== location.origin) {
navigator.sendBeacon('/rum/loaf', JSON.stringify({
origin: url.origin,
duration: script.duration,
forcedStyleAndLayoutDuration: script.forcedStyleAndLayoutDuration,
invoker: script.invoker,
url: location.pathname
}));
}
});
}
}
}).observe({ type: 'long-animation-frame', buffered: true });
}Με αυτό το snippet συλλέγεις attributed δεδομένα από πραγματικούς χρήστες. Στη δουλειά μου, ένα dashboard στο Grafana δείχνει top-10 «offending scripts» ανά ώρα. Ξέρεις άμεσα αν ένα νέο tag που έβαλε το marketing στο GTM ρίχνει το INP.
Το checklist που τρέχω πριν κάθε production release:
defer ή async, ποτέ blocking.navigator.sendBeacon, όχι synchronous XHR.Ένα πράγμα που πρόσθεσα φέτος: automated Lighthouse CI που τρέχει σε κάθε PR και αποτυγχάνει αν το «third-party summary» πάει πάνω από το budget. Στοιχειώδες, αλλά έσωσε τη σελίδα μας από 4 «marketing surprise» tags αυτό το τρίμηνο. Για βαθύτερη μελέτη στο INP και τη βελτιστοποίησή του, καθώς και στο πώς το TTFB επηρεάζει το network waterfall, ρίξε μια ματιά στους σχετικούς οδηγούς.
Σύμφωνα με το HTTP Archive (Q2 2026), τα third-party scripts ευθύνονται κατά μέσο όρο για 40–70% του main-thread JavaScript execution σε e-commerce sites. Αυτό μεταφράζεται σε 1.100 ms Total Blocking Time και ~150 ms αύξηση INP στο p75.
Ναι, από την έκδοση 0.10 το Partytown θεωρείται stable. Δουλεύει καλά για GTM, Meta Pixel, TikTok Pixel και generic analytics. Αποφύγε το για A/B testing tools και chat widgets, γιατί αυτά χρειάζονται sync DOM access.
Όχι πάντα. Το self-hosting βοηθάει με το caching (μεγαλύτερο max-age) αλλά χάνεις το edge caching της Google. Καλύτερη λύση: server-side GTM σε δικό σου subdomain, που συνδυάζει και τα δύο οφέλη.
Με performance budgets στο CI/CD. Ρύθμισε Lighthouse CI ώστε να αποτυγχάνει το build αν το third-party JS υπερβεί ένα όριο (π.χ. 150 KB). Το θέμα γίνεται τεχνικό κώλυμα, όχι organizational fight.
Το dns-prefetch κάνει μόνο DNS lookup (φθηνό). Το preconnect ανοίγει και TCP+TLS connection (πιο ακριβό, όριο 3–4). Το preload κατεβάζει το ίδιο το resource. Για third-party CDNs χρησιμοποίησε preconnect για τα 2–3 πιο κρίσιμα και dns-prefetch για τα υπόλοιπα.
Οδηγός βελτιστοποίησης INP — ο δείκτης Core Web Vitals που αποτυγχάνει το 43% των ιστοσελίδων. Μάθετε πώς να σπάσετε long tasks, να χρησιμοποιήσετε scheduler.yield() και να πετύχετε INP κάτω από 200ms με πρακτικά παραδείγματα κώδικα.