Üçüncü Taraf Script Denetimi: Etiket, Reklam, Sohbet

Üçüncü taraf script denetimi, sayfanızda çalışan ama sizin yazmadığınız kodu tek tek listeleyip her birinin maliyetini ve faydasını tartmaktır. Kısa cevap: önce envanter çıkarın, her scripti engelleyerek ölçün, kalmasına karar verdiklerinizi doğru yükleme stratejisiyle sınırlandırın ve bu işi ayda bir tekrarlayın. Bu yazı etiket yöneticisi, reklam kodu, sohbet eklentisi ve rıza aracı için bu süreci karar kuralları ve kontrol listeleriyle anlatır. Belirli bir hız skoru ya da sıralama sonucu vaat etmez.

Bu yazı, sitesine zamanla analiz, reklam ve canlı destek ekleyip sayfanın ağırlaştığını fark eden yayıncılar ve site sahipleri, pazarlama ekibinin etiket taleplerini performansla dengelemeye çalışan SEO uzmanları ve eklenen bir kodun bedelini sayıyla göstermek isteyen geliştiriciler için hazırlandı. Burada yalnızca üçüncü taraf koda odaklanıyoruz; genel sayfa hızı ölçümü ayrı bir konudur. Rıza araçlarının hukuki yönü bu yazının kapsamı dışındadır ve bu yazı hukuki tavsiye değildir.

Envanter Çıkarma: Sayfada Kimin Kodu Çalışıyor

Denetimin ilk adımı ölçmek değil, listelemektir. Çoğu sitede kimse tüm scriptleri bilmez; çünkü etiketler farklı kişiler tarafından, farklı zamanlarda ve çoğu kez tema ya da eklenti aracılığıyla eklenmiştir.

Üçüncü taraf ne demek

Lighthouse'un tanımı basittir: denetlenen URL'den farklı bir alan adında barındırılan script üçüncü taraftır. Bu tanıma göre bir CDN'deki kendi kütüphaneniz bile "farklı alan adı" sayılabilir; ama pratikte sizin kontrol ettiğiniz ve sizin güncellediğiniz kodla, başkasının sunucusundan gelen ve içeriğini değiştiremediğiniz kodu ayırmak gerekir. web.dev'in üçüncü taraf JavaScript yazısı (yeni sekmede açılır) yavaşlamanın yaygın bir nedeninin, bu kod üzerinde kontrolünüzün olmaması olduğunu söyler.

Envanteri nereden çıkarırsınız

Üç kaynağı birlikte kullanın:

1. Tarayıcı geliştirici araçlarının Ağ paneli: sayfa yüklenirken hangi alan adlarına istek gidiyor, her biri kaç istek ve ne kadar veri taşıyor.
2. Etiket yöneticisinin içi: hangi etiketler, hangi tetikleyicilerle yayında.
3. Sitenin şablon ve eklenti dosyaları: doğrudan koda yazılmış scriptler, tema ayarlarına yapıştırılmış kod parçaları.

Üçüncüsü çoğu kez atlanır. Etiket yöneticisinde görünmeyen bir script şablonda gömülü olabilir ve envanterde yoksa denetimde hiç sorgulanmaz.

Her satır için kayıt tutun

Envanter tablosunda her script için şu alanlar bulunsun:

Sahibi olmayan bir script, silinmesi en kolay adaydır. Birine "bu ne işe yarıyor" sorusunu sorduğunuzda kimse cevap vermiyorsa, sahibini bulana kadar o scripti kapatmak makul bir ilk denemedir.

Örnek senaryo: bir yayıncı blogu

Örnek senaryo olarak bir yayıncı blogunu düşünün. Sayfada bir analiz aracı, bir etiket yöneticisi, iki ayrı reklam sağlayıcısı, bir sohbet eklentisi, bir rıza çubuğu ve bir yorum sistemi var. Kimse hepsini aynı anda hatırlamıyor; sohbet eklentisi geçen yıl bir kampanya için eklenmiş ve kampanya bitmiş. Envanter çıkarılınca iki yinelenen analiz kodu ve kullanılmayan bir yorum sistemi de ortaya çıkıyor. Tek bir listeleme egzersizi, ölçüme başlamadan bile temizlik fırsatı verir.

Her Script İçin Maliyet ve Fayda

Envanter hazır olduğunda her satıra iki soru sorulur: bu script sayfaya ne kazandırıyor ve ne kaybettiriyor?

Maliyet kalemleri

web.dev yazısı maliyetleri şöyle sıralar: üçüncü taraf kod birçok sunucuya birçok ağ isteği atabilir ve her istek yükleme süresini uzatır. Ağır JavaScript ana iş parçacığını meşgul eder, DOM oluşturmayı engelleyebilir, etkileşimi geciktirebilir ve pili tüketebilir. Büyük, optimize edilmemiş görseller ya da videolar kullanıcının veri paketini harcar. Dikkatsiz yüklenen bir script tek hata noktası olabilir; yani onun sunucusu yavaşladığında sayfanız da takılır. Zayıf HTTP önbellekleme, eksik sıkıştırma ve document.write() gibi eski API'ler maliyeti artırır. Yazı ayrıca yavaş cevap veren bir üçüncü taraf gömmesinin async ya da defer olsa bile window.onload olayını bekletebildiğini belirtir.

Etkileşim tarafında script değerlendirmesi önemlidir. web.dev'in betik değerlendirmesi ve uzun görevler yazısı (yeni sekmede açılır) tarayıcının scripti ayrıştırıp derlediğini ve çalıştırdığını, bunun yükleme sırasında ana iş parçacığını meşgul edip kullanıcı etkileşimlerini geciktirebildiğini anlatır. Toplam Engelleme Süresi (TBT) INP ile iyi korelasyon gösterir; yüksek bir TBT, yükleme sırasında betik değerlendirmesinin etkileşimleri kötüleştirdiğine işaret edebilir.

Lighthouse ne söylüyor

Lighthouse'un "Üçüncü taraf kodun etkisini azaltın" denetimi, her üçüncü taraf scriptin yükleme sırasında ana iş parçacığını ne kadar engellediğini hesaplayıp toplar ve toplam engelleme 250 ms'yi aştığında uyarır. Denetimin belgesi (yeni sekmede açılır) yalnızca bu eşiği verir; sitenize özgü ek bir sınırı kendi ölçümlerinizden türetmeniz daha sağlıklıdır. Aynı belge, Lighthouse 13 ile bu denetimin "Verimli önbellek ömürlerini kullanın" içgörüsü içine taşındığını da not eder. Yani raporunuzda ayrı bir kutu görmemeniz, sorunun kalktığı anlamına gelmez.

Engelleyerek ölçme yöntemi

Bir scriptin gerçek maliyetini görmenin en doğrudan yolu onu kapatıp farkı ölçmektir. web.dev yazısındaki iş akışı şöyledir:

1. Ağ ve işlemci kısıtlamasını açın.
2. Ölçümü alın.
3. Ağ panelinde şüpheli isteğe sağ tıklayıp URL'yi engelleyin.
4. Sayfayı yeniden yükleyin ve tekrar ölçün.
5. En az üç kez tekrarlayın.

Yazı ayrıca Performans panelinde ürüne göre gruplamayı ve WebPageTest'te alan adı engellemeyi ve SPOF sekmesini (bir üçüncü tarafın zaman aşımına uğradığı ya da hata verdiği durumu simüle eder) anar. Üç tekrar, tek bir ölçümün gürültüsüne kanmamak içindir.

Faydayı da yazıya dökün

Maliyet yalnızca bir yüzdür. Faydayı da somutlaştırın:

• Bu script hangi karar için kullanılıyor ve son kullanılma tarihi ne?
• Kapatılırsa hangi gelir, rıza ya da ölçüm kaybolur?
• Aynı iş başka bir script ya da sunucu tarafı çözümle yapılabilir mi?
• Bu script yalnızca belirli sayfalarda gerekli mi?

Karar kuralı

Her satır için dört çıktıdan birini seçin:

1. Kaldır: Sahibi yok, faydası belirsiz ya da başka bir araçla yinelenen script.
2. Daralt: Fayda gerçek ama yalnızca belirli sayfalarda gerekli. Yalnızca o sayfalarda yükleyin.
3. Ertele: Fayda gerçek ve ilk ekran için gerekli değil. Etkileşim ya da görünürlük sonrasına bırakın.
4. Koru: Gelirle, yasal zorunlulukla ya da çekirdek işlevle doğrudan bağlı. Yine de doğru yükleme stratejisiyle ve bütçeyle koruyun.

Kısa kural: faydasını tek cümleyle ve bir sahiple söyleyemediğiniz script için "kaldır" varsayılan olsun.

Yükleme Stratejisi: Erteleme, Gecikmeli Başlatma ve Sınırlama

Bir script kalacaksa nasıl yükleneceği, maliyetini belirler. web.dev yazısının önerdiği araçlar şunlardır.

async ve defer

JavaScript varsayılan olarak ayrıştırıcıyı engeller. async, scripti HTML ayrıştırması sürerken indirir; indikten sonra çalıştırmak için ayrıştırmayı duraklatır. defer ise paralel indirir ve belge ayrıştırması bitince çalıştırır. Yazı, erken çalışması gereken scriptler (bazı analiz kodları gibi) için async, kritik olmayanlar için defer önerir. jQuery gibi temel kütüphanelerde async kullanmaktan kaçınılmasını söyler. Blink tabanlı tarayıcılarda iki nitelik de isteğin önceliğini düşürür; script, engelleyici bir script kadar erken gelmeyebilir. Yazı ayrıca birçok izleme scripti olan bir sayfayı tek başına async'in kurtarmayacağını belirtir.

Bağlantıyı önceden kurmak

DNS, yönlendirme ve HTTPS için TLS pazarlığı gibi bağlantı kurma adımları, özellikle zayıf ağlarda yavaştır. dns-prefetch yalnızca DNS çözümlemesini yapar; preconnect ise TCP gidiş gelişlerini ve TLS pazarlığını da yapar ve HTTPS kaynaklarında yükleme süresini belirgin biçimde düşürebilir. Yalnızca sayfanın erken ve kesin kullanacağı birkaç alan adı için preconnect kullanın; her alan adına eklemek kaynak harcar.

Tembel yükleme ve gecikmeli başlatma

Tembel yükleme reklam ve video gibi gömülü kaynakları ihtiyaç duyulana kadar, örneğin kullanıcı yaklaştığında erteler. Yazı bunun için IntersectionObserver'ı, kaydırma ve boyut değiştirme dinleyicileri ile getBoundingClientRect() birleşimine göre öneriyor, çünkü ikincisi hata yapmaya yatkın ve yavaştır. İçerik ana içerikten sonra ama olası bir kullanıcı etkileşiminden önce de yüklenebilir. Analiz kodunu geç yüklerken erken sayfa verisini korumak mümkündür; yazı bunun için bir örnek kurulumdan söz eder.

Sohbet eklentisi gibi araçlarda yaygın bir kalıp "önce basit bir düğme göster, tıklanınca gerçek eklentiyi yükle"dir. Bu, genel bir tasarım kalıbıdır ve web.dev yazısında anılmaz; ama tembel yükleme ilkesinin doğal bir uygulamasıdır. Düğme tıklanınca yükleme gecikir, bu yüzden düğmeye basma anında bir yükleniyor durumu göstermek gerekir.

Kendi sunucuda barındırma

Kendi sunucunuzda barındırmak DNS süresi ve HTTP önbellek başlıkları üzerinde kontrol verir. Yazı bir bedel de belirtir: kendi barındırdığınız script, API değişiklikleri ya da güvenlik düzeltmeleri için otomatik güncelleme almaz; güncellemeleri elle uygulamanız gerekir. Bu yüzden yalnızca sürüm takibini üstlenebileceğiniz scriptler için uygundur ve sağlayıcının şartlarının buna izin verdiğini ayrıca kontrol etmelisiniz.

Iframe ve sandbox

Bir iframe içinde yüklenen üçüncü taraf script ana sayfanın çalışmasını engellemez. Yazı bu yaklaşımın AMP'de kullanıldığını söyler. Ancak iframe'ler onload olayını yine bekletir; kritik işlevleri onload'a bağlamayın. Permissions Policy ile üçüncü taraf içeriğin bazı tarayıcı özellikleri kapatılabilir; iframe'in sandbox niteliği gömülü scriptlerin yapabileceklerini kısıtlar. İframe kaynaklı uzun görevler PerformanceObserver ve longtask atfı ile hangi çerçeveden geldiği görülerek tespit edilebilir.

Script boyutu ve görev bölme

Betik değerlendirme yazısına göre her klasik script elemanı kendi değerlendirme görevini oluşturur ve tek bir script için yaklaşık 100 KB sınırı iyi bir hedeftir; cihaz gücü değiştiği için kesin limit koymak zordur. Çalışmayı bölmenin başka yolları dinamik import (başlangıç dışındaki kodu dışarıda bırakır) ve web worker'dır (scripti ana iş parçacığı dışında çalıştırır). Bölmenin bir bedeli de var: küçük dosyalar daha az verimli sıkıştırılır ama önbellek yeniden kullanımını iyileştirir. Bu ilkeler sizin yazdığınız kod için geçerlidir; üçüncü taraf scriptin iç yapısını değiştiremezsiniz, yalnızca ne zaman ve nerede yükleneceğini seçebilirsiniz.

Örnek senaryo: sohbet eklentisini tek adımda hafifletmek

Bir hizmet sitesinde sohbet eklentisi her sayfada, sayfa açılır açılmaz yükleniyor. Engelleme testi eklentinin ana iş parçacığında belirgin bir süre tuttuğunu gösteriyor. Ekip üç karar veriyor: eklenti yalnızca fiyat ve iletişim sayfalarında yüklenecek, yüklenme düğmeye ilk dokunuşa ya da kısa bir bekleme sonrasına bırakılacak ve düğmeye basıldığında bir yükleniyor göstergesi çıkacak. Kullanım oranı üç ay sonra yeniden ölçülecek. Burada sayı uydurmuyoruz; önemli olan kararın sırası: önce ölç, sonra daralt, sonra ertele, sonra tekrar ölç.

Aynı mantık bir harita, bir video gömmesi ya da bir yorum sistemi için de çalışır. Her birinde "bu öğeyi herkes görüyor mu, yoksa sayfanın altında kalıp çoğu ziyaretçi için hiç gerekmiyor mu" sorusu, yükleme zamanını belirleyen en pratik filtredir.

Strateji seçim tablosu

Bu tablo bir başlangıç önerisidir. Her kararı engelleyerek ölçme yöntemiyle doğrulayın.

Etiket Yöneticisi: Kolaylık ve Risk

Etiket yöneticisi tek bir script gibi görünür ama içinde onlarca script barındırabilir. web.dev yazısı Google Tag Manager'ın etiketleri eşzamansız dağıtabildiğini, ağ çağrılarını azaltabildiğini ve veri katmanı üzerinden veri toplayabildiğini söyler. Riskleri de listeler: fazla etiket ve otomatik olay dinleyicileri ağ isteklerini artırır ve yanıt verme hızını düşürür. Erişimi olan herkes JavaScript ekleyebildiği için hem güvenlik hem performans riski doğar; yazı erişimin sınırlanmasını önerir.

Etiket yöneticisi için denetim soruları

• Hangi kapsayıcı yayında ve son yayın ne zaman yapıldı?
• Yayındaki her etiketin sahibi ve gerekçesi var mı?
• Duraklatılmış ama silinmemiş etiketler listeden temizlendi mi?
• Tetikleyiciler gereğinden geniş mi (tüm sayfalar, tüm tıklamalar)?
• Otomatik olay dinleyicileri gerçekten kullanılıyor mu?
• Kimler yayın yetkisine sahip ve değişiklikler inceleniyor mu?
• Aynı ölçüm iki yoldan (kodda ve etiketle) mı yapılıyor?

Yinelenen ölçüm hem verileri bozar hem maliyeti ikiye katlar.

Reklam, Sohbet ve Rıza Araçları

Bu üç grup, performansa en çok dokunan ve en çok tartışılan üçüdür. Ortak yanları, iş hedefiyle doğrudan bağlı olmaları ve bu yüzden "kaldır" yerine "yönet" kararının çoğu zaman doğru olmasıdır.

Reklam kodu

Reklam scriptleri çok sayıda ağ isteği, ek yarışma mantığı ve değişken yükseklikte içerik getirebilir. Burada iki ayrı sorun vardır: ana iş parçacığı yükü ve yerleşim kayması. Yer ayırma (yuvaya sabit minimum yükseklik vermek) ikincisini çözer; birincisi için yuvaları ekran dışındayken geç yüklemek ve gereksiz sağlayıcıyı azaltmak gerekir. Açık artırma mantığının sayfa üzerindeki etkisi için header bidding ve Prebid temelleri yazısına, reklamın Core Web Vitals ile dengesi için reklam ve Core Web Vitals dengesi yazısına bakın. Ekranı kaplayan reklam biçimleri ayrı bir kalite meselesidir; ayrıntısı araya giren reklamlar yazısındadır.

Sohbet eklentisi

Sohbet eklentileri sayfanın köşesinde küçük bir düğme gibi görünür ama genellikle kendi çerçevesini, yazı tiplerini ve bir bağlantıyı birlikte getirir. Şu kuralı uygulayın: eklenti yalnızca destek ya da satış açısından değerli sayfalarda yüklensin (örneğin fiyat ve iletişim sayfaları), makale gibi okunacak sayfalarda yüklenmesin. Sohbetin gerçekten kullanım oranını ölçün; kullanım düşükse kaldırmak ya da tıklayınca yüklemek mantıklıdır.

Rıza araçları

Rıza çubuğu sayfanın ilk ekranında görünür ve ölçümün geri kalanını belirler. Bu yüzden yavaşlatması iki kat zararlıdır: sayfayı geciktirir ve diğer scriptlerin yüklenmesini rızaya bağladığı için zinciri uzatır. Rıza aracının nasıl yükleneceği, hangi scriptleri rızaya kadar beklettiği ve ölçüm kaybının nasıl yönetileceği çerez onayı ve ölçüm kaybı rehberinde ayrıntılı anlatılıyor. Burada denetim açısından önemli olan şu: rıza aracı ana içeriği ve ilk etkileşimi engellememeli, rıza sonrası yüklenecek scriptler gerçekten rıza sonrasına bırakılmış olmalı. Bu araçların hukuki yönü için resmi kaynaklara ve hukuk danışmanına başvurun; bu yazı hukuki tavsiye değildir.

Yerleşim kayması ve etkileşim birlikte düşünülsün

Reklam, sohbet düğmesi ve rıza çubuğu sayfa yüklendikten sonra ortaya çıkan öğelerdir. Hangisinin yer ayırdığını, hangisinin içeriği ittiğini ve hangisinin ilk dokunmayı geciktirdiğini ayrı ayrı kaydedin. Aynı anda üç kaynağın kaymaya katkıda bulunduğu bir sayfada, tek tek kapatma deneyleri yapmadan hangisinin asıl sorumlu olduğunu anlayamazsınız.

Ayda Bir Tekrar Denetim

Üçüncü taraf kod durağan değildir: sağlayıcı sürüm değiştirir, pazarlama yeni bir etiket ekler, bir eklenti güncellenir. Tek seferlik temizlik birkaç ay sonra eski haline döner.

Aylık rutin

1. Envanter tablosunu güncelleyin: yeni alan adı, kaldırılan script, değişen sahip.
2. Ağ panelinden toplam üçüncü taraf istek sayısını ve en ağır beş alan adını kaydedin.
3. Lighthouse'u ana şablonlarda (ana sayfa, makale, liste, ödeme) aynı cihaz profiliyle çalıştırın ve üçüncü taraf kaynaklı engelleme süresini not edin.
4. Etiket yöneticisinde son ayın değişikliklerini gözden geçirin.
5. Alan verisini kontrol edin: etkileşim ve yerleşim kayması iyileşti mi, kötüleşti mi? Alan verisi 28 günlük kayan bir pencere olduğu için kısa dalgalanmalardan sonuç çıkarmayın.
6. "Kaldır, daralt, ertele, koru" kararlarını yeniden gözden geçirin.

Üçüncü taraf bütçesi

Bir "bütçe" belirleyin ve herkesle paylaşın: örneğin yeni bir script eklenmeden önce bir eskisinin kaldırılması ya da yeni scriptin engelleyerek ölçüm sonucunu sunması. Bu kural pazarlama ve geliştirme arasındaki tartışmayı sayıya bağlar. Yazılı bir eşik, yazılı olmayan bir "çok ağır" yorumundan daha az sürtüşme yaratır. Eşik değerini sitenizin kendi ölçümlerinden türetin; Lighthouse'un 250 ms'lik denetim eşiği bir başlangıç referansı olabilir ama sizin hedefiniz olmak zorunda değildir.

Sonucu ekibe anlatmak

Denetimin değeri, bulguların karar vericilere ulaşmasındadır. Rapor uzun olmak zorunda değil; tek sayfada şunlar yeterlidir: kaç script bulundu, kaçı kaldırıldı, daraltıldı, ertelendi ya da korundu; en ağır üç script ve her birinin engelleme testindeki farkı; korunan scriptlerin sahibi ve gerekçesi; bir sonraki gözden geçirme tarihi. Pazarlama tarafı bir etiketin kaldırılmasına itiraz ettiğinde elinizde sayı ve yazılı bir fayda notu olması, tartışmayı kişisel görüşten çıkarır.

Raporda kesinlik iddia etmekten kaçının ve bulguları tek bir ekran görüntüsüne değil, tekrarlanabilir ölçümlere dayandırın. Laboratuvar ölçümü tek bir cihaz ve ağ simülasyonudur; gerçek ziyaretçilerde sonuç farklı olabilir. Bu yüzden her kararı alan verisinde de izleyin ve beklenen iyileşme görünmüyorsa kararı geri almaktan çekinmeyin. Kaldırılan bir script gelir ya da ölçüm kaybına yol açtıysa, bunu not edip daha hafif bir alternatif ya da daha geç bir yükleme yoluyla yeniden değerlendirin.

Güvenlik ve sürekli kontrol

Yazı, HTTPS kullanmayı, karma içerikten kaçınmayı, Content Security Policy script-src ile hangi kaynaklardan script yükleneceğini sınırlamayı ve alt kaynak bütünlüğü ile güvenli aktarımı kullanarak üçüncü taraf scriptleri düzenli denetlemeyi öğütler. Performans denetimi ile güvenlik denetimi aynı envanteri paylaşabilir; iki işi birlikte yapmak zaman kazandırır.

Kontrol listesi

• Envanterde her script için amaç, sahip ve eklenme tarihi var mı?
• Sahibi olmayan veya yinelenen script kaldırıldı mı?
• Her script engelleyerek en az üç kez ölçüldü mü?
• Yalnızca belirli sayfalarda gereken scriptler orada sınırlandı mı?
• Kritik olmayan scriptler defer, tembel yükleme ya da etkileşime kadar erteleme ile yükleniyor mu?
• Sadece gerçekten kullanılan alan adlarına preconnect var mı?
• Etiket yöneticisinde duraklatılmış etiketler temizlendi mi ve yayın yetkisi sınırlı mı?
• Reklam yuvaları yer ayırıyor ve ekran dışındayken geç mi yükleniyor?
• Sohbet eklentisi yalnızca değerli sayfalarda mı yükleniyor?
• Rıza aracı ana içeriği engellemiyor mu?
• Bir sonraki denetim tarihi takvimde mi?

Karar tablosu

Sık Sorulan Sorular

Üçüncü taraf script nedir ve neden yavaşlatır?

Denetlenen sayfadan farklı bir alan adında barındırılan scripttir. web.dev'e göre birçok sunucuya çok sayıda ağ isteği atabilir, ana iş parçacığını meşgul edip DOM oluşturmayı ve etkileşimi geciktirebilir ve içeriği üzerinde kontrolünüz olmadığı için yavaşlamanın yaygın bir nedenidir.

async ve defer arasındaki fark nedir?

async scripti ayrıştırma sürerken indirir ve indiği anda çalıştırır; defer paralel indirir ama belge ayrıştırması bittikten sonra çalıştırır. Erken çalışması gereken scriptler için async, kritik olmayanlar için defer önerilir. jQuery gibi temel kütüphanelerde async kullanmayın.

Google Tag Manager sayfamı yavaşlatır mı?

Tek başına değil, içine konan etiketler ve tetikleyiciler yavaşlatır. web.dev'e göre GTM etiketleri eşzamansız dağıtabilir ama fazla etiket ve otomatik olay dinleyicileri ağ isteklerini artırır ve yanıt verme hızını düşürür. Duraklatılmış etiketleri temizleyin ve yayın yetkisini sınırlayın.

Lighthouse'taki 250 ms eşiği nedir?

Lighthouse, üçüncü taraf scriptlerin yükleme sırasında ana iş parçacığını toplam olarak engelleme süresini hesaplar ve 250 ms'yi aşarsa uyarır. Bu bir denetim eşiğidir, kullanıcı deneyimi için kesin bir hedef değildir. Lighthouse 13'ten itibaren denetim "Verimli önbellek ömürlerini kullanın" içgörüsüne taşınmıştır. Denetim adları ve eşikler Lighthouse sürümüne göre değişebilir; kullandığınız sürümün belgesine bakın.

Bir scriptin gerçek maliyetini nasıl ölçerim?

Ağ ve işlemci kısıtlamasıyla ölçüm alın, Ağ panelinde scriptin URL'sini engelleyin, sayfayı yeniden yükleyip tekrar ölçün ve bunu en az üç kez yapın. Farkı fayda ile birlikte değerlendirin.

Denetimi ne sıklıkla tekrarlamalıyım?

Sabit bir sıklık kuralı yoktur; pratik öneri olarak ayda bir ve her büyük kampanya, tema ya da etiket değişikliğinden sonra yapın, çünkü üçüncü taraf kod sizin müdahaleniz olmadan da değişebilir.

Sonuç

Üçüncü taraf script performansı bir kez çözülen bir sorun değil, düzenli yönetilen bir envanterdir. Önce sayfada çalışan her scripti sahibi ve amacıyla listeleyin. Sonra her birini engelleyerek ölçün, faydasıyla tartın ve kaldır, daralt, ertele ya da koru kararını verin. Kalanlar için async, defer, preconnect, tembel yükleme ve gerektiğinde iframe ile sınırlama gibi yükleme stratejilerini uygulayın. Etiket yöneticisinde erişimi sınırlayın, reklam yuvalarında yer ayırın, sohbet ve rıza araçlarını ana içeriği engellemeyecek biçimde yükleyin. Ayda bir bu döngüyü yenileyin. Bu adımlar daha hızlı ve kararlı bir deneyimi hedefler; belirli bir skor ya da sıralama sonucu garanti etmez ve rıza konularında hukuki tavsiye değildir.

Sayfa deneyimine saygılı reklam alanları arıyorsanız Akua Adforce'taki reklam alanları sayfasına göz atabilirsiniz; kapsam ve koşullar ürün sayfasında listelenir.