Kodėl trečiųjų šalių skriptai tampa našumo priešais
Kiekvienas iš mūsų turbūt esame susidūrę su ta situacija – svetainė kraunasi amžinybę, o Chrome DevTools rodo, kad kažkoks analytics.js ar kitas trečiosios šalies skriptas užima 80% viso puslapio įkėlimo laiko. Problema ta, kad šiuolaikinės svetainės tiesiog neįsivaizduojamos be išorinių skriptų. Google Analytics, Facebook Pixel, reklaminiai tinklai, chat’o widgetai, A/B testavimo įrankiai – viskas tai reikalinga verslui, bet kartu tampa tikru košmaru performance’o optimizavimui.
Pagrindinė bėda su third-party scripts yra ta, kad jūs neturite jokios kontrolės virš jų kodo kokybės ar dydžio. Gali būti, kad įtraukiate 5KB skriptą, kuris paskui dinaminiai įkrauna dar 500KB papildomų resursų. O gal tas skriptas blokuoja pagrindinį thread’ą, nes kažkas nusprendė, kad sinchroninis XMLHttpRequest yra puiki idėja 2024 metais. Juokinga, bet liūdna realybė.
Dar vienas aspektas – jūs priklausote nuo trečiosios šalies infrastruktūros. Jei jų CDN lėtai atsako arba visai nukrista, jūsų svetainė kenčia. Mačiau atvejų, kai vienas chat widget’as, kurio niekas net nenaudojo, pridėdavo 3-4 sekundes prie Time to Interactive metrikos.
Kaip išmatuoti tikrąją žalą
Pirmas žingsnis visada – išmatuoti. Ne spėlioti, ne „man atrodo”, o tikrai pamatuoti, kiek kiekvienas skriptas kainuoja. Chrome DevTools Coverage tab’as čia jūsų geriausias draugas. Atidarykite jį, perkraukite puslapį ir pamatysite, kiek kodo iš tikrųjų yra vykdoma, o kiek tiesiog užima vietą.
WebPageTest yra kitas must-have įrankis. Paleiskite testą su „Block Requests” funkcija ir pamatykite, kaip jūsų svetainė veiktų be tam tikrų trečiųjų šalių skriptų. Kartais rezultatai būna šokiruojantys – svetainė be visų tų „būtinų” skriptų įsikrauna 5 sekundes greičiau.
Lighthouse Performance auditas taip pat puikiai išskaido, kurie skriptai labiausiai prisideda prie Main Thread Blocking Time. Dažniausiai pamatysite, kad Google Tag Manager su visais savo tag’ais yra vienas didžiausių kaltininkų. Ironija ta, kad įrankis, sukurtas marketingo komandai „netrukdyti developerių”, dažnai sukelia didžiausias problemas.
// Paprastas būdas išmatuoti konkretaus skripto įtaką
const startTime = performance.now();
const script = document.createElement('script');
script.src = 'https://third-party.com/script.js';
script.onload = () => {
console.log(`Script loaded in ${performance.now() - startTime}ms`);
};
document.head.appendChild(script);
Lazy loading strategijos, kurios tikrai veikia
Pirmasis ir paprasčiausias būdas sumažinti third-party scripts įtaką – nekrauti jų iš karto. Daugelis skriptų iš tikrųjų nėra reikalingi, kol vartotojas nepradeda su jais sąveikauti. Chat widget’as? Užkraukite jį tik tada, kai vartotojas nuslenka puslapį žemyn arba pabando kažką paspausti.
Intersection Observer API čia tampa neįkainojamas. Galite stebėti, kada tam tikras elementas pasirodo viewport’e, ir tik tada įkrauti susijusį skriptą. Pavyzdžiui, jei turite YouTube video embed’ą, užkraukite visą YouTube player infrastruktūrą tik tada, kai vartotojas beveik pasiekia tą sekciją.
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
loadThirdPartyScript();
observer.unobserve(entry.target);
}
});
});
observer.observe(document.querySelector('.chat-widget-container'));
Facade pattern’as – dar vienas genialus triukas. Vietoj tikro YouTube iframe, parodykite thumbnail’ą su play mygtuku. Kai vartotojas paspaudžia, tik tada įkraukite tikrą player’į. Tai sutaupo šimtus kilobaitų ir daugybę HTTP request’ų. Yra net paruoštų bibliotekų kaip lite-youtube-embed, kurios daro būtent tai.
Dar vienas dažnai pamirštamas dalykas – daugelis analytics skriptų gali būti įkrauti su requestIdleCallback. Jei naršyklė turi laisvo laiko, ji įkraus skriptą. Jei ne – vartotojas to net nepastebės, nes jis bus užsiėmęs sąveikaujant su jūsų turiniu.
Resource hints ir kaip jais nepiktnaudžiauti
DNS prefetch, preconnect, prefetch, preload – visi šie resource hints gali padėti, bet tik jei žinote, ką darote. Mačiau svetaines su 20+ preconnect direktyvų, kurios absoliučiai nieko nepadėjo, nes naršyklė turi limitą, kiek jų gali apdoroti vienu metu.
Preconnect naudokite tik kritiškiausiems third-party domenams. Jei žinote, kad Google Analytics bus įkrautas kiekviename puslapyje, <link rel="preconnect" href="https://www.google-analytics.com"> gali sutaupyti 100-200ms DNS lookup ir SSL handshake laiko. Bet nereikia to daryti su 15 skirtingų domenų.
DNS prefetch yra lengvesnė alternatyva – jis tik išsprendžia DNS, bet neužmezga TCP/SSL connection. Tai puiku mažiau kritiniams resursams. Pavyzdžiui, jei turite social media share mygtukus, kurie kreipiasi į Facebook ar Twitter domenus, dns-prefetch gali būti pakankamas.
Preload yra galingas, bet pavojingas įrankis. Jei preload’inate skriptą, kuris paskui nėra naudojamas, jūs tiesiog švaistysite bandwidth’ą. Chrome DevTools net rodo warning’us, kai preload’inti resursai nebuvo panaudoti per 3 sekundes. Naudokite jį tik tada, kai tikrai žinote, kad resursas bus reikalingas greitai.
Self-hosting vs CDN dilema
Vienas iš kontroversiškiausių klausimų – ar verta self-host’inti third-party scripts? Google Fonts, Google Analytics, jQuery iš CDN – ar ne geriau viską laikyti savo serveryje?
Argumentai už self-hosting’ą yra stiprūs. Jūs turite pilną kontrolę – galite nustatyti agresyvius cache header’ius, naudoti HTTP/2 server push, optimizuoti delivery su savo CDN. Google Fonts self-hosting gali sutaupyti visą round-trip’ą į Google serverius. Yra įrankių kaip google-webfonts-helper, kurie padaro šį procesą trivialiu.
Bet yra ir trūkumų. Jūs prisiimate atsakomybę už updates. Jei Google Analytics atnaujina savo skriptą su bug fix’u ar nauja funkcija, jūs to negausite automatiškai. Taip pat praranda shared cache benefit’ą – nors reikia pripažinti, kad šiuolaikinės naršyklės vis labiau partition’ina cache, tai nebėra toks didelis privalumas kaip anksčiau.
Mano asmeninė rekomendacija – kritiniams resursams kaip fonts, kurie tikrai nepasikeičia dažnai, self-hosting yra no-brainer. Analytics ir kitiems dinamiškesniems skriptams – priklauso nuo jūsų situacijos. Jei turite gerą CI/CD pipeline’ą ir galite automatizuoti updates, eikite į priekį.
Content Security Policy kaip našumo įrankis
CSP dažniausiai yra suvokiamas kaip security feature, bet jis gali būti ir puikus našumo optimizavimo įrankis. Kai turite griežtą CSP, jūs iš esmės kontroliuojate, kokie third-party scripts gali būti įkrauti. Tai verčia komandą sąmoningai galvoti apie kiekvieną naują skriptą.
Dažnai marketingo komanda „tik greitai įmeta” naują tracking pixel’į per GTM, ir niekas net nepastebi, kol svetainė tampa lėta. Su CSP, toks skriptas tiesiog neveiks, kol kas nors sąmoningai neįtrauks jo į allowed sources. Tai sukuria natural checkpoint’ą diskusijai – ar tikrai mums reikia šito skripto?
Content-Security-Policy:
script-src 'self'
https://www.google-analytics.com
https://www.googletagmanager.com;
Be to, CSP gali padėti identifikuoti „script injection” atakas, kurios kartais atsitinka per kompromituotus third-party scripts. Jei kažkas bando įkrauti skriptą iš neautorizuoto domeno, CSP violation report’as jums apie tai praneš. Tai ne tik security win, bet ir performance win, nes blokuojate potencialiai kenksmingus ar lėtus skriptus.
Žinoma, CSP implementacija nėra triviali, ypač jei jau turite daug third-party dependencies. Pradėkite su report-only mode, surinkite violations, ir palaipsniui griežtinkite policy. Tai investicija, bet ilgalaikėje perspektyvoje ji apsimoka.
Service Workers ir išmanesnis caching
Service Workers atveria visiškai naują dimensiją third-party scripts valdymui. Galite interceptinti request’us į third-party domenus ir taikyti custom caching strategijas. Pavyzdžiui, Google Analytics skriptą galite cache’inti ilgiau nei jie rekomenduoja, ir atnaujinti background’e.
Workbox biblioteka daro tai super paprastai. Galite nustatyti stale-while-revalidate strategiją third-party scripts – vartotojas gauna cached versiją iš karto (greitis), o background’e patikrinama, ar yra naujesnė versija (freshness).
// workbox-config.js
module.exports = {
runtimeCaching: [{
urlPattern: /^https:\/\/www\.google-analytics\.com/,
handler: 'StaleWhileRevalidate',
options: {
cacheName: 'google-analytics',
expiration: {
maxAgeSeconds: 60 * 60 * 24 * 7 // 1 savaitė
}
}
}]
};
Dar įdomesnė galimybė – galite modifikuoti response’us on-the-fly. Jei third-party skriptas grąžina per didelius cache header’ius arba jų visai neturi, galite juos pridėti ar pakeisti Service Worker’yje. Tai suteikia jums kontrolę, kurios normaliai neturėtumėte.
Tačiau būkite atsargūs – per agresyvus caching gali reikšti, kad vartotojai ilgai naudoja outdated skriptų versijas. Visada turėkite mechanizmą force update’inti cache, kai tikrai reikia. Versioning Service Worker’io faile yra paprastas būdas tai pasiekti.
Parcel bundling ir code splitting third-party libraries
Jei naudojate third-party bibliotekos kaip npm package, o ne external script tag’ą, turite daugiau optimizavimo galimybių. Modern bundlers kaip Webpack, Rollup ar Vite gali daryti tree-shaking ir išmesti nenaudojamą kodą.
Lodash yra klasikinis pavyzdys. Jei import’uojate visą biblioteką, gaunate ~70KB. Bet jei naudojate tik kelis utility functions, galite import’uoti tik juos: import debounce from 'lodash/debounce'. Su tree-shaking, bundle’yje atsidurs tik tas funkcijas, kurių tikrai reikia.
Code splitting leidžia išskaidyti third-party dependencies į atskirus chunks, kurie įkraunami tik tada, kai reikalingi. Jei turite admin panel’į, kuris naudoja daug heavy libraries, nėra jokios priežasties krauti jų regular users. Dynamic imports čia yra jūsų draugas.
// Vietoj
import Chart from 'chart.js';
// Darykite
const loadChart = async () => {
const Chart = await import('chart.js');
return Chart.default;
};
// Ir naudokite tik tada, kai reikia
button.addEventListener('click', async () => {
const Chart = await loadChart();
new Chart(ctx, config);
});
Dar vienas triukas – naudokite bundle analyzer tools kaip webpack-bundle-analyzer. Jis vizualizuoja, kas sudaro jūsų bundle’į, ir dažnai rasite siurprizų. Kartą mačiau projektą, kuris per klaidą bundle’ino visą Moment.js biblioteką su visomis locale failais, nors naudojo tik date formatting. Tai buvo 200KB+ nereikalingo kodo.
Kada atsisakyti trečiųjų šalių skriptų visiškai
Kartais geriausias optimizavimas yra tiesiog neturėti skripto. Rimtai, užduokite sau klausimą – ar tikrai reikia to chat widget’o, kurį naudoja 0.5% vartotojų? Ar tikrai reikia penkių skirtingų analytics platformų, kurios visos track’ina tą patį?
Daugelis third-party tools turi lightweight alternatyvas. Vietoj pilno Intercom widget’o, galite turėti paprastą „Contact us” formą, kuri įkrauna Intercom tik tada, kai vartotojas tikrai nori chat’inti. Vietoj Google Maps embed’o su visa infrastruktūra, galite naudoti static map image su link’u į pilną žemėlapį.
Analytics yra kita sritis, kur galima daug sutaupyti. Ar tikrai reikia Google Analytics, Hotjar, Mixpanel, Facebook Pixel ir dar trijų kitų tracking scripts? Dažnai 80% insights galite gauti iš vieno gerai sukonfigūruoto įrankio. O jei tikrai reikia daugiau, yra server-side tracking sprendimų, kurie visai neapkrauna kliento.
Social media widgets – dar vienas low-hanging fruit. Facebook like button įkrauna megabaitus JavaScript. Vietoj to, galite turėti paprastą link’ą arba custom styled button’ą, kuris atidaro share dialog’ą naujame lange. Vartotojas gauna tą pačią funkcionalumą, bet jūsų svetainė įsikrauna sekundėmis greičiau.
Kai greitis tampa konkurenciniu pranašumu
Grįžtant prie esmės – third-party scripts optimizavimas nėra vienkartinis projektas, tai ongoing procesas. Nauji skriptai atsiranda, seni pasensta, vartotojų poreikiai keičiasi. Kas ketvirtį peržiūrėkite, kokie skriptai kraunami jūsų svetainėje ir ar jie visi dar reikalingi.
Sukurkite performance budget’ą ir įtraukite jį į CI/CD pipeline’ą. Jei naujas deployment’as viršija nustatytą third-party scripts dydžio limitą, build’as turėtų fail’inti. Tai gali atrodyti drastiška, bet tai vienintelis būdas išlaikyti discipliną ilgalaikėje perspektyvoje.
Komunikacija su stakeholders yra kritinė. Marketingo komanda turi suprasti, kad kiekvienas naujas tracking pixel’is turi kainą – ne tik pinigine prasme, bet ir vartotojų patirties prasme. Lėta svetainė reiškia mažesnį conversion rate, o tai tiesiogiai veikia bottom line. Kai parodote skaičius, diskusijos tampa daug produktyvesnės.
Galiausiai, greitis yra feature. Vartotojai jaučia skirtumą tarp svetainės, kuri įsikrauna per 2 sekundes, ir tos, kuri įsikrauna per 6. Google tai žino ir įtraukia page speed į ranking faktorius. Jūsų konkurentai tai žino ir investuoja į performance. Klausimas ne ar turėtumėte optimizuoti third-party scripts, o kaip greitai galite pradėti.
Pradėkite nuo matavimo, identifikuokite didžiausius kaltininkus, taikykite čia aprašytas strategijas, ir matuokite rezultatus. Performance optimizavimas nėra magija – tai metodiškas darbas, bet rezultatai tikrai to verti. Ir kas žino, gal jūsų optimizuotas, žaibiškai greitas website taps pavyzdžiu kitiems.