JavaScript Site Hızını Nasıl Etkiler? Performans İçin JS Optimizasyonu

JavaScript optimizasyonu, sayfanıza eklediğiniz her script dosyasının indirme, ayrıştırma ve çalıştırma maliyetini azaltarak sitenin daha hızlı açılmasını ve tıklamalara daha çabuk yanıt vermesini sağlama işidir. 2012'den beri müşteri sitelerinde en sık karşılaştığım yavaşlık kaynağı görseller değil, kontrolsüz büyüyen JavaScript oluyor. Bu yazıda sorunun nereden çıktığını ve adım adım nasıl çözdüğümü anlatıyorum.

Site hızının arama sıralamasına genel etkisini site hızı SEO'yu nasıl etkiler yazısında, ölçüm adımlarını ise Lighthouse ile site performans testi rehberinde ele aldım. Burada odak yalnızca JavaScript: tarayıcının onu nasıl işlediği, nerede tıkandığı ve sizin neyi değiştirebileceğiniz.

JavaScript site hızını nasıl etkiler ve javascript optimizasyonu neden gerekir?

JavaScript, tarayıcının ana iş parçacığında çalışan ve çalıştığı süre boyunca sayfanın çizilmesini, kaydırılmasını ve tıklamalara yanıt vermesini durdurabilen koddur. Bu nedenle script ne kadar büyük ve ağırsa, sayfa o kadar geç ekrana gelir ve etkileşime o kadar geç yanıt verir. Javascript optimizasyonu bu bekleme süresini kısaltmayı hedefler.

Görsellerden farkı şu: tarayıcı 300 KB'lık bir görseli yalnızca indirir ve çözer. Aynı boyuttaki bir JavaScript dosyasını ise indirir, ayrıştırır, derler ve sonra çalıştırır. Dolayısıyla byte başına maliyeti çok daha yüksektir. Üstelik bu işin büyük kısmı, kullanıcının dokunuşlarını da işleyen aynı ana iş parçacığında olur.

Sahada gördüğüm tablo çoğu zaman aynı: site ilk yapıldığında hızlıdır, ardından her kampanya için bir piksel, her ihtiyaç için bir eklenti eklenir. Bir yıl sonra sayfa, kimsenin tam listesini bilmediği onlarca script yükler. Kısacası JavaScript sorunu genellikle tek bir büyük hatadan değil, birikimden doğar.

Tarayıcı bir JavaScript dosyasını nasıl işler?

Tarayıcının bir script için yaptığı işi dört adımda düşünebilirsiniz. Her adımın ayrı bir maliyeti var ve optimizasyon da bu adımlara göre ayrışıyor:

1. İndirme: Dosya ağdan gelir. Burada boyut, sıkıştırma ve önbellek belirleyicidir.
2. Ayrıştırma ve derleme: Motor kodu okur ve çalıştırılabilir hale getirir. Özellikle orta segment telefonlarda bu adım belirgin süre alır.
3. Çalıştırma: Motor kodu ana iş parçacığında yürütür; DOM'u değiştirir, olay dinleyicileri kurar.
4. Sonrası: Kodun tetiklediği stil hesabı, yerleşim ve çizim işleri gelir.

Ancak asıl kritik nokta, ana iş parçacığının aynı anda tek bir iş yapabilmesidir. web.dev'deki uzun görevleri optimize etme rehberi, 50 milisaniyeyi aşan her işi "uzun görev" olarak tanımlar. Uzun görev sürerken kullanıcı bir butona dokunursa, tarayıcı bu dokunuşu görev bitene kadar işleyemez. Bu yüzden ölçerken yalnızca dosya boyutuna değil, çalışma süresine de bakmanız gerekir.

Render engelleyen script nedir?

Render engelleyen script, HTML içinde head bölümüne async veya defer olmadan yazılmış klasik bir script etiketidir. Tarayıcı böyle bir etiketi gördüğünde HTML'i okumayı durdurur, dosyayı indirir, çalıştırır ve ancak ondan sonra sayfayı kurmaya devam eder.

Sonuç olarak kullanıcı, ağ yavaşsa saniyelerce boş ya da yarım bir ekran görür. Üstelik bu script sayfanın ilk görünümü için hiç gerekli olmayabilir. Örneğin bir sohbet balonu, bir analitik kütüphanesi ya da bir kaydırıcı eklentisi çoğu zaman head içinde senkron yüklenir; fakat hiçbiri ilk ekranın çizilmesi için şart değildir.

Lighthouse raporu bu durumu "render engelleyen kaynakları kaldırın" başlığıyla gösterir. Ben bir siteye ilk baktığımda kaynak kodunu açıp head içindeki script etiketlerini tek tek sayıyorum. Her biri için tek bir soru soruyorum: bu kod, kullanıcı sayfanın üst kısmını görmeden önce mutlaka çalışmak zorunda mı? Cevap neredeyse her zaman hayır çıkıyor.

defer ve async arasındaki fark nedir?

İki özellik de script'in HTML ayrıştırmasını durdurmadan arka planda inmesini sağlar. Fark, çalışma zamanında ortaya çıkar. MDN script belgesi davranışı ayrıntılı anlatıyor; özetini aşağıdaki tabloda topladım.

Kısacası, birbirine bağımlı scriptleriniz varsa defer kullanırsınız, çünkü sıra korunur. Başka hiçbir koda bağlı olmayan bir ölçüm etiketi içinse async yeterlidir. Pratikte ben sitenin kendi kodunu defer ile, üçüncü taraf etiketlerini ise mümkünse async veya gecikmeli yüklemeyle ayırıyorum.

Javascript optimizasyonu için ilk nereden başlamalısınız?

İlk adım envanter çıkarmaktır. Hangi script'in neden yüklendiğini bilmeden yaptığınız her iyileştirme tahmine dayanır. Ben envanteri şu sırayla çıkarıyorum:

• Chrome DevTools içindeki Network sekmesinde yalnızca JS filtresini açarak her dosyanın boyutunu ve kaynağını listeliyorum.
• Coverage panelinde sayfa açılışında kullanılmayan kod oranına bakıyorum.
• Performance panelinde bir kayıt alıp ana iş parçacığındaki uzun görevlerin hangi dosyaya ait olduğunu işaretliyorum.
• Her üçüncü taraf etiketi için bir sahip belirliyorum: bu kodu kim istedi, hâlâ kullanılıyor mu?

Bu tablo çoğu zaman şaşırtıcı sonuç verir. Örneğin iki yıl önce bitmiş bir kampanyanın pikseli hâlâ yükleniyordur ya da aynı analitik kodu hem tema hem de etiket yöneticisi üzerinden iki kez çalışıyordur. Dolayısıyla javascript optimizasyonu çoğu zaman kod yazmakla değil, gereksiz kodu silmekle başlar. En ucuz ve en hızlı kazanç budur; üstelik silinen kod bir daha bakım da istemez, test de gerektirmez.

Kullanılmayan JavaScript'i nasıl bulup temizlersiniz?

Kullanılmayan JavaScript, sayfaya yüklenen ama o sayfada hiç çalışmayan koddur. Tipik örnek, yalnızca iletişim sayfasında gereken bir form doğrulama kütüphanesinin sitenin her sayfasında yüklenmesidir. Coverage paneli bu oranı dosya bazında kırmızı ve yeşil çubuklarla gösterir.

Temizlik için üç yol izliyorum. İlk olarak, hiç kullanılmayan eklenti ve kütüphaneleri tamamen kaldırıyorum. Ardından yalnızca belirli sayfalarda gereken kodu o sayfalara taşıyorum. Son olarak büyük bir kütüphanenin küçük bir parçası kullanılıyorsa, ya o parçayı ayrı içe aktarıyor ya da işi tarayıcının yerleşik özellikleriyle çözüyorum.

Öte yandan bir uyarı eklemem gerekiyor: Coverage yalnızca kaydettiğiniz oturumdaki kullanımı gösterir. Bir menü açılmadıysa, o menünün kodu kullanılmamış görünür. Bu yüzden silmeden önce sayfadaki tüm etkileşimleri deneyip yeniden bakmanızı öneririm. Aksi halde hızlanan ama menüsü açılmayan bir siteyle karşılaşırsınız.

Code splitting nedir ve ne zaman işe yarar?

Code splitting, uygulamanın tüm JavaScript kodunu tek bir büyük dosya yerine sayfaya veya özelliğe göre küçük parçalara bölmektir. Böylece kullanıcı yalnızca o an ihtiyaç duyduğu kodu indirir. Modern paketleyiciler bunu dinamik import ifadesiyle otomatik yapar.

En çok işe yaradığı yer, tek sayfa uygulamaları ve React, Vue gibi çatılarla kurulmuş sitelerdir. Örneğin yönetim paneli, grafik kütüphanesi ya da ödeme adımı kodu ana sayfa ziyaretçisine hiç gönderilmemelidir. Rota bazlı bölme bu işi büyük ölçüde çözer.

Ancak bölmeyi abartmak da sorun yaratır. Onlarca minik parça, her biri için ayrı istek ve bağımlılık zinciri demektir. Ben genellikle önce rota bazlı bölmeyle başlıyorum, ardından yalnızca gerçekten ağır olan bileşenleri, yani harita, editör veya video oynatıcı gibi parçaları ayrı yüklüyorum. Kurumsal ölçekte bölme konusunu mimari düzeyde merak ederseniz micro frontend mimarisi yazıma göz atabilirsiniz.

Üçüncü taraf scriptler siteyi ne kadar yavaşlatır?

Üçüncü taraf scriptler, sizin sunucunuzdan değil başka bir firmanın sunucusundan gelen kodlardır: reklam pikselleri, analitik, sohbet araçları, ısı haritaları, A/B test araçları ve gömülü videolar. Asıl sorun, bu kodun boyutunu ve davranışını sizin yönetmemenizdir; sağlayıcı dosyayı güncellediğinde maliyet de değişir.

Kesin bir yavaşlama oranı vermem mümkün değil, çünkü etki etiketin türüne ve nasıl yüklendiğine göre çok değişir. Yine de sahada tekrar tekrar gördüğüm bir örüntü var: ana iş parçacığındaki uzun görevlerin önemli bir kısmı çoğu zaman sitenin kendi kodundan değil, üçüncü taraf etiketlerden çıkıyor. Bu, saha tecrübesine dayalı bir gözlem; garanti değil ve her sitede ayrıca ölçmeniz gerekiyor.

Performance panelinde "Third-party" gruplamasını açtığınızda hangi alan adının ne kadar ana iş parçacığı süresi harcadığını görürsünüz. Bu liste, pazarlama ekibiyle konuşurken elinizdeki en somut belgedir. Çünkü "bu piksel sayfayı yavaşlatıyor" demek yerine "bu piksel her açılışta şu kadar süre alıyor" diyebilirsiniz.

Üçüncü taraf etiketleri hızı bozmadan nasıl yönetirsiniz?

Pazarlama etiketlerini kaldırmak her zaman seçenek değildir; dönüşüm ölçümü olmadan reklam bütçesini yönetemezsiniz. Bu nedenle hedef, etiketleri silmek değil, doğru zamanda ve doğru yerden yüklemektir. Benim uyguladığım kurallar şunlar:

• Her etiket yalnızca gerektiği sayfada çalışır; örneğin satın alma pikseli yalnızca teşekkür sayfasında.
• Sohbet balonu, harita ve video gibi ağır bileşenler kullanıcı tıklayana kadar yalnızca hafif bir önizleme gösterir.
• Aynı işi yapan iki araç varsa biri kalır; iki ısı haritası aracına nadiren ihtiyaç olur.
• Etiket yöneticisindeki her etiketin bir sahibi ve gözden geçirme tarihi olur.
• Kritik olmayan etiketleri sayfa yüklendikten sonra tetiklerim.

Burada bir dengeye dikkat etmeniz gerekiyor. Dönüşüm etiketini çok geç tetiklerseniz, sayfadan hızlı çıkan kullanıcıların dönüşümünü kaçırabilirsiniz. Dolayısıyla ölçüm etiketlerini ertelerken ölçüm kaybını da kontrol edin. Google Ads yönetimi yaptığım hesaplarda bu dengeyi hız ve dönüşüm verisini yan yana izleyerek kuruyorum.

JavaScript ile INP arasındaki ilişki nedir?

INP (Interaction to Next Paint), kullanıcının tıklama, dokunma veya tuş basışından sonra ekranda bir sonraki görsel güncellemenin ne kadar sürede geldiğini ölçer. web.dev INP rehberine göre 200 milisaniye ve altı iyi kabul edilir. JavaScript, bu metriğin en doğrudan belirleyicisidir.

Bir etkileşimin gecikmesi üç parçadan oluşur: giriş gecikmesi, olay işleyicinin çalışma süresi ve sonrasındaki çizim gecikmesi. Giriş gecikmesi, kullanıcı dokunduğunda ana iş parçacığı başka bir uzun görevle meşgulse uzar. İşleyici süresi ise doğrudan sizin yazdığınız kodun ağırlığıdır. Kısacası, her iki tarafta da suçlu çoğunlukla JavaScript'tir.

Bu yüzden LCP'si iyi olan bir sitenin INP'si kötü olabilir. Sayfa hızlı açılır, ama "sepete ekle" butonuna bastığınızda yarım saniye hiçbir şey olmaz. Kullanıcı bunu tıklamanın çalışmadığı şeklinde algılar ve tekrar basar. Bu sürtünmenin satışa etkisini SEO ve UX uyumu yazısında daha geniş ele aldım.

Uzun görevleri bölmek için ne yapabilirsiniz?

Uzun görevi bölmek, tek seferde 300 milisaniye süren bir işi, arada tarayıcıya nefes aldıran küçük parçalara ayırmaktır. Böylece kullanıcı bu sırada dokunursa, tarayıcı parçalar arasında dokunuşu işleyebilir.

web.dev'in önerdiği yöntem, kodun içine bilinçli "yield" noktaları koymaktır. Chrome'da desteklenen scheduler.yield() fonksiyonu, çalışmayı durdurup kontrolü tarayıcıya verir ve devamı öncelikli olarak sıraya alır. Desteklemeyen tarayıcılar içinse setTimeout ile benzer bir geri dönüş yazabilirsiniz. Önemli olan her satırdan sonra değil, kullanıcıya görünen iş ile arka plan işi arasında yield etmektir.

Pratik bir örnek vereyim: bir filtre butonuna basıldığında hem ürün listesini güncelleyen hem de analitik olayı gönderen, hem de URL'yi yazan bir işleyici düşünün. Önce listeyi güncellersiniz, sonra yield edersiniz, ardından analitik ve URL işini yaparsınız. Böylece kullanıcı sonucu hemen görür; geri kalan işi tarayıcı onun fark etmeyeceği bir anda bitirir.

Framework seçimi JavaScript performansını nasıl etkiler?

Seçtiğiniz çatı, sayfanın ne kadar JavaScript göndereceğini baştan belirler. Tamamen istemci tarafında çizilen bir tek sayfa uygulaması, içeriği göstermeden önce çatının kendisini ve uygulama kodunu indirip çalıştırmak zorundadır. Sunucu tarafında çizilen ya da statik üretilen sayfalar ise HTML'i hazır gönderir.

Bu, React veya Vue kötü demek değildir. Ancak bir kurumsal tanıtım sitesinin, bir hesap makinesi kadar etkileşime ihtiyacı yoksa, her ziyaretçiye tam bir uygulama çatısı göndermek pahalı bir tercihtir. Son yıllarda yaygınlaşan "adacık" yaklaşımı, sayfanın yalnızca etkileşimli bölümlerini JavaScript ile canlandırır ve geri kalanını düz HTML bırakır.

Benim önerim şu: çatıyı ekibin alışkanlığına göre değil, sayfanın gerçekten ne kadar etkileşim içerdiğine göre seçin. Web tasarım projelerinde ilk toplantıda bu soruyu soruyorum, çünkü sonradan çatıyı değiştirmek, baştan doğru seçmekten çok daha maliyetlidir.

JavaScript ile çizilen içerik SEO'yu nasıl etkiler?

Google, JavaScript SEO temelleri belgesinde sayfaları güncel bir Chromium ile oluşturduğunu, ancak bu oluşturma adımının taramadan sonra ayrı bir kuyrukta gerçekleştiğini anlatır. Yani içerik yalnızca JavaScript çalıştıktan sonra ortaya çıkıyorsa, Google'ın onu görmesi ek bir adıma bağlıdır.

Pratikte en sık gördüğüm sorunlar şunlar: bağlantıların gerçek a etiketi yerine tıklama olayıyla yapılması, başlık ve açıklama etiketlerinin yalnızca istemci tarafında yazılması ve hata sayfalarının 200 kodu dönmesi. Bu sorunların hiçbiri doğrudan hız sorunu değildir; fakat JavaScript'e aşırı bağımlılığın aynı kökten çıkan sonuçlarıdır.

Bu nedenle önemli içeriği, başlıkları ve iç bağlantıları sunucudan gelen HTML'de tutmanızı öneririm. Konunun tarama ve dizine ekleme tarafını teknik SEO ipuçları ve yapay zeka sonrası teknik SEO yazılarımda ayrıntılı anlattım. Üstelik yapay zeka tarayıcılarının önemli bir kısmının JavaScript çalıştırmadığını da hesaba katmak gerekiyor.

Paket boyutunu küçültmek için hangi teknikleri kullanırsınız?

Kodu silemediğiniz ve bölemediğiniz durumda, kalan kodu mümkün olduğunca küçük göndermek gerekir. Bu noktada javascript optimizasyonu daha teknik bir hale gelir. Kullandığım temel teknikler şunlar:

1. Küçültme (minify): Boşlukları, yorumları ve uzun değişken adlarını kaldırır. Derleme aracınızın üretim modunda genellikle hazır gelir.
2. Sıkıştırma: Sunucunun JavaScript dosyalarını Brotli veya gzip ile göndermesi aktarım boyutunu belirgin biçimde düşürür.
3. Tree shaking: Paketleyicinin kullanılmayan dışa aktarımları pakete koymaması. ES modül yapısı gerektirir.
4. Gereksiz polyfill temizliği: Hedef tarayıcı listesini güncel tutarak modern tarayıcılara eski tarayıcı yamaları göndermemek.
5. Ağır kütüphane değişimi: Tarih biçimlendirme veya animasyon için kullanılan büyük kütüphaneleri, yerleşik tarayıcı API'leri ya da daha küçük alternatiflerle değiştirmek.

Ancak şunu unutmayın: sıkıştırma aktarım boyutunu düşürür, çalıştırma maliyetini değil. Tarayıcı sıkıştırması çözülen kodun tamamını yine ayrıştırıp çalıştırır. Bu yüzden sıkıştırmayı son adım değil, temel bir hijyen kuralı olarak görün.

Önbellek ve kaynak ipuçları JavaScript yüklemesini nasıl hızlandırır?

Tekrar gelen ziyaretçi için en hızlı dosya, hiç indirilmeyen dosyadır. Bu yüzden JavaScript dosyalarına içerik özetli dosya adları verip uzun süreli önbellek başlıkları tanımlarsınız. Dosya değiştiğinde adı da değişir; böylece kullanıcı eski sürümde takılı kalmaz.

Kaynak ipuçları ise ilk ziyarette işe yarar. Örneğin kritik bir üçüncü taraf alan adına preconnect vermek, bağlantı kurulumunu erkene çeker. Sayfanın hemen ihtiyaç duyduğu ama tarayıcının geç keşfettiği bir modül için modulepreload kullanabilirsiniz.

Öte yandan ipuçlarını her şeye eklemek ters etki yapar. Her preload, tarayıcıya "bunu şimdi indir" der ve bant genişliğini diğer kaynaklarla paylaşır. Sonuç olarak her şeyi öncelikli yaptığınızda hiçbir şey öncelikli olmaz. Ben preload listesini genellikle iki üç kalemle sınırlı tutuyorum ve her birinin etkisini ölçerek karar veriyorum.

Mobil cihazlarda JavaScript neden daha büyük bir sorundur?

Geliştiriciler siteyi çoğunlukla güçlü dizüstü bilgisayarlarda test eder. Oysa ziyaretçilerin büyük kısmı orta segment telefonlardan gelir. Aynı JavaScript dosyasını ayrıştırmak ve çalıştırmak, işlemcisi daha zayıf bir cihazda belirgin şekilde daha uzun sürer.

Bu yüzden masaüstünde akıcı görünen bir etkileşim telefonda takılabilir. Chrome DevTools'ta işlemci yavaşlatma seçeneğini açarak bu farkı kabaca görebilirsiniz; ancak gerçek cihazda test etmenin yerini tutmaz. Ben elimde her zaman eski bir orta segment Android telefon bulunduruyorum.

Ayrıca mobil ağ koşulları da işin içine girer. İndirme süresi uzadığında, render engelleyen her script kullanıcıyı daha uzun süre boş ekranla baş başa bırakır. Mobil deneyimi bütüncül değerlendirmek isterseniz mobil uyumluluk testi yazıma bakabilirsiniz. Kısacası mobil ziyaretçi için javascript optimizasyonu bir incelik değil, temel gerekliliktir.

Pratikte mobil için ayrı bir kontrol listem var. Önce telefonda ilk ekranı çizmek için gereken script sayısına bakıyorum. Ardından dokunmatik menünün, filtrelerin ve sepet butonunun gecikmesini yavaşlatılmış işlemciyle deniyorum. Son olarak mobilde hiç görünmeyen bir bileşenin kodunun yine de yüklenip yüklenmediğini kontrol ediyorum; örneğin yalnızca masaüstünde açılan geniş bir mega menü, telefonda da tüm koduyla gelebiliyor. Bu tür bulgular genellikle hızlı ve risksiz kazançlar sağlıyor, çünkü kullanıcıya görünen hiçbir şeyi değiştirmiyorsunuz.

JavaScript performansını hangi araçlarla ölçersiniz?

Ölçüm iki türlüdür: laboratuvar verisi ve saha verisi. Laboratuvar verisi kontrollü bir ortamda tek bir yükleme simüle eder; saha verisi ise gerçek kullanıcılardan toplanır. İkisi farklı soruları yanıtlar, dolayısıyla ikisine de ihtiyacınız var.

• Lighthouse: Toplam Engelleme Süresi (TBT), kullanılmayan JavaScript ve render engelleyen kaynaklar için hızlı teşhis verir.
• Chrome DevTools Performance: Hangi fonksiyonun ne kadar sürdüğünü milisaniye düzeyinde gösterir.
• PageSpeed Insights: Hem laboratuvar sonucunu hem de sitenizin yeterli trafiği varsa Chrome kullanıcı verisini aynı sayfada sunar.
• Search Console: Core Web Vitals raporunda sorunlu URL gruplarını listeler.

Burada önemli bir ayrıntı var: INP bir saha metriğidir ve Lighthouse gibi etkileşimsiz laboratuvar testlerinde doğrudan ölçülmez. Laboratuvarda TBT, ana iş parçacığının ne kadar meşgul olduğuna dair iyi bir işaret verir; ancak gerçek INP için saha verisine bakmanız gerekir. Search Console rehberimde bu raporun nasıl okunacağını adım adım anlattım.

JavaScript optimizasyonunda en sık yapılan hatalar nelerdir?

Yıllar içinde aynı hataları farklı sitelerde tekrar tekrar gördüm. En yaygın olanları şöyle sıralayabilirim:

• Yalnızca Lighthouse puanını hedeflemek ve gerçek kullanıcı verisine hiç bakmamak.
• Bir "hız eklentisi" kurup tüm scriptleri körü körüne ertelemek; bu da menülerin, formların ve ödeme adımının bozulmasına yol açabiliyor.
• Kritik görsel veya içerik JavaScript ile yüklenirken onu da tembel yüklemeye dahil etmek.
• Etiket yöneticisini sınırsız bir çöplük gibi kullanmak.
• Optimizasyonu bir kez yapıp sonrasında yeni eklenen kodu hiç denetlememek.

Bunların ortak noktası, ölçmeden karar vermektir. Bu yüzden her değişiklikten önce ve sonra aynı koşullarda ölçüm alıyorum. Üstelik değişikliği tek tek yapıyorum; beş şeyi birden değiştirdiğinizde hangisinin işe yaradığını, hangisinin bir şeyi bozduğunu anlayamazsınız.

JavaScript performansını kalıcı hale getirmek için ne yapmalısınız?

Tek seferlik bir temizlik birkaç ay içinde eriyip gider. Kalıcı sonuç için süreç kurmanız gerekir. Bunun en etkili yolu bir performans bütçesidir: örneğin ana sayfanın ilk yüklemede gönderebileceği JavaScript miktarına ve uzun görev sayısına bir üst sınır koyarsınız.

Ardından bu bütçeyi yayın sürecine bağlarsınız. Derleme aracı paket boyutu sınırı aştığında uyarı verir, yeni bir üçüncü taraf etiketi eklenmeden önce ise kısa bir onay adımı işler. Böylece hız, kimsenin fark etmediği bir anda değil, bilinçli bir kararla değişir.

Son olarak ayda bir kez saha verisine bakmayı alışkanlık haline getirin. Search Console veya PageSpeed Insights üzerindeki eğilim, yeni bir eklentinin veya kampanya etiketinin etkisini genellikle hızla ortaya çıkarır. SEO danışmanlığı verdiğim sitelerde bu kontrolü aylık rapora dahil ediyorum.

Eski bir sitede javascript optimizasyonu nasıl planlanır?

Yıllar içinde büyümüş bir sitede her şeyi aynı anda düzeltmeye çalışmak çoğu zaman işe yaramaz. Bu yüzden ben işi önce riske göre sıralıyorum. Ödeme adımı, iletişim formu ve menü gibi gelir getiren bölümlere dokunan değişiklikleri en sona bırakıyorum; tanıtım sayfalarındaki gereksiz kodu ise ilk hafta temizliyorum.

İkinci kural, her değişikliği geri alınabilir tutmaktır. Örneğin bir etiketi silmeden önce etiket yöneticisinde duraklatıyorum ve bir hafta dönüşüm verisini izliyorum. Veri bozulmadıysa kalıcı olarak kaldırıyorum. Böylece hem hız kazanırsınız hem de pazarlama ekibinin ölçümünü riske atmazsınız.

Üçüncü kural ise ekiple aynı dili konuşmaktır. Geliştirici "ana iş parçacığı", pazarlamacı "piksel", yönetici "satış" der. Ben bu yüzden her bulguyu üç sütunlu bir listeye yazıyorum: ne yavaşlatıyor, kimin sorumluluğunda ve kaldırılırsa hangi ölçüm etkilenir. Bu liste, teknik bir konuyu karar verilebilir bir iş listesine çevirir.

Son olarak zamanlamayı gerçekçi kurun. Küçük bir kurumsal sitede ilk temizlik birkaç günde bitebilir; büyük bir e-ticaret sitesinde ise aynı iş haftalara yayılabilir. Bu süreler saha tecrübesine dayalı başlangıç aralığıdır, garanti değildir. Asıl belirleyici, kodun ne kadar belgelenmiş olduğu ve kararları kimin verdiğidir. Belgesiz bir sitede önce keşfe, sonra temizliğe zaman ayırmanız gerekir.

Özetle javascript optimizasyonu adımlarını hangi sırayla uygulamalısınız?

Buraya kadar anlattıklarımı uygulanabilir bir sıraya dökersem, benim sahada izlediğim yol şudur:

1. Envanter çıkarın: her script'in kaynağını, boyutunu ve sahibini listeleyin.
2. Gereksiz olanı silin; en büyük ve en ucuz kazanç buradan gelir.
3. Render engelleyen scriptleri defer veya async ile yükleyin.
4. Üçüncü taraf etiketleri sayfaya ve zamana göre sınırlayın.
5. Rota bazlı code splitting uygulayın.
6. Uzun görevleri bölün ve etkileşim işleyicilerini hafifletin.
7. Küçültme, sıkıştırma ve önbelleği doğru yapılandırın.
8. Performans bütçesi koyup aylık saha verisiyle izleyin.

Bu sıralamanın mantığı basit: önce maliyeti sıfıra indiren adımlar, sonra maliyeti azaltan adımlar, en son da maliyeti koruyan süreç gelir. Kendi sitenizde bu adımları uygulamak için destek isterseniz iletişim sayfasından bana yazabilirsiniz; önce mevcut durumu ölçer, ardından hangi adımın sizin için en çok kazanç getireceğini birlikte belirleriz.