Site Performansı Neden Zamanla Düşer?

Başlangıç ölçümünün sınırları ve referans yanılsaması

Yayın günündeki Lighthouse skoru veya laboratuvar ölçümü, o anın fotoğrafıdır. İçerik değişir, eklentiler güncellenir, sunucu yapılandırması farklılaşır; başlangıç skoru ise referans olarak yerinde kalır ve zamanla yanıltıcı bir karşılaştırma noktasına dönüşür.

İlk ölçümün güvenilirliğini azaltan birkaç etken vardır. Önbellekleme henüz ısınmamıştır, CDN yapılandırması tam oturmuş olmayabilir, medya kütüphanesi küçüktür. Bir ay sonra cache hit oranı yükselmişse gerçek alan verisi (field data), ilk lab ölçümünden daha iyi çıkabilir. Ama ters yönde de gelişme yaşanır.

Temel sorun başlangıç sonrasındaki dönemde ortaya çıkar. Sayfa sayısı artınca her yeni sayfa tipi yeni varlıklar getirir. Bir kategori sayfasına eklenen filtre bileşeni ana sayfayı doğrudan etkilemez; ancak o JavaScript bundle'ı site genelinde yükleniyorsa etkiler. Bu ayrımı başlangıç ölçümü göstermez. Gözlemlenebilmesi için sürekli alan verisi takibi şarttır.

Eklenti birikimi ve görünmez yük

WordPress veya benzer bir CMS kullanıyorsanız eklenti sayısının zamanla arttığını fark edersiniz. İlk altı ay on eklentiyle başlarsınız; on sekizinci ayda yirmi beş veya daha fazlasıyla çalışıyor olabilirsiniz. Her eklenti meşru bir ihtiyacı karşılar, ama her biri bir yükleme maliyeti taşır.

Maliyet her zaman dosya boyutundan kaynaklanmaz. Bazı eklentiler küçük ama kötü yazılmış scriptler çalıştırır; bazıları aynı kütüphanenin farklı sürümlerini ikinci kez yükler; bazıları ise gerekli olmayan sayfalarda bile kendi varlıklarını zorla ekler. Bunların toplamı, her sayfanın taşıdığı "temel yük"ü yavaş yavaş şişirir.

Eklenti birikiminin özellikle sinsi tarafı, devre dışı bırakılan eklentilerin bile iz bırakabilmesidir. Veritabanında artık tablolar, varlık klasöründe kullanılmayan dosyalar, hatta bazen stil sayfalarını etkileyen hooks (kancalar) kalmaya devam eder. Yeni eklentiyi kaldırdınız, ama miras yük orada duruyor olabilir.

Çözüm her eklentiyi reddetmek değildir. Bir eklentiye ihtiyaç duyulduğunda hangi sayfalarda yükleneceğini kontrol etmek, gereksiz bağımlılıkları devre dışı bırakmak ve deaktif eklentileri düzenli aralıklarla temizlemek, birikimi önleyen pratik adımlardır.

Büyüyen medya kütüphanesi ve görsel boyut kayması

Site açılışında yüklenen görseller genellikle özenle hazırlanmıştır. Ama altı ay sonra blog yazısına eklenmiş fotoğraflar, haber afişleri, ürün görselleri - bunların tamamı aynı özenle işlenmemiş olabilir. Medya kütüphanesi büyüdükçe içine karışan optimize edilmemiş görsellerin oranı artar.

Boyut kayması belli bir kırılma noktasında değil, kademeli olarak gerçekleşir. Bugün yüklenen 3 MB'lık bir fotoğraf LCP metriğini belirgin biçimde düşürür; ama bu tek dosya değil, bu tür düzinelerce dosyanın birikimidir. Sonunda görsel ağırlığı önemli bir sorun haline gelir ve bunu ilk yayın tarihiyle karşılaştırarak ölçmek güçleşir.

WebP veya AVIF dönüşümünü otomatize etmek, yükleme anında boyut sınırı getirmek ve LCP elemanı olarak kullanılan görsellere fetchpriority="high" eklemek bu kaymayı yavaşlatır. Ancak bu önlemler bile ileriye dönük yeni yüklemeleri kapsıyorsa faydalıdır; mevcut kütüphanedeki birikmiş sorunlar için ayrı bir toplu işlem gerekir.

Responsive görseller de zamanla karışabilir. Başlangıçta doğru boyutlar tanımlanmış olabilir; fakat tema güncellemesi veya yeni sayfa düzeni sonrası srcset değerleri eski kalıplarla çalışmaya devam edebilir, tarayıcı yanlış boyutlu görseli seçmeye başlar. Bu durum hem LCP hem de toplam yük üzerinde ölçülebilir bir etki yaratır.

Üçüncü taraf scriptlerin sessiz birikmesi

Her üçüncü taraf script bir karar sonucunda gelir: analitik eklediniz, canlı sohbet aracı entegre ettiniz, A/B test platformu yerleştirdiniz, ısı haritası servisi bağladınız. Bu kararların her biri ayrı ayrı mantıklıdır. Ama birlikte değerlendirildiğinde, sayfanızın kontrolünüzün dışındaki sunuculara bağımlı hale gelmesi anlamına gelir.

Ana tehlike yalnızca dosya boyutu değildir. Üçüncü taraf bir script yavaş yanıt veriyorsa tarayıcının ayrıştırma (parsing) süreci de etkilenebilir. async veya defer eklenmemiş scriptler ana iş parçacığını (main thread) doğrudan bloke eder. TTFB'yi doğrudan etkilemez, ama FCP ve LCP üzerindeki dolaylı etkisi ölçülür.

Üçüncü taraf kaynaklı gecikmelerin tespiti için tarayıcının geliştirici araçlarındaki Network sekmesi yeterli bir başlangıç noktasıdır. Kaynaklar yüklenme süresine göre sıralandığında hangi alan adlarının uzun sürdüğü görünür hale gelir. Artık kullanılmayan bir servise ait script sayfada kalmaya devam ediyorsa, kaldırmak en temiz çözümdür.

Bir script gerçekten gerekliyse, yükleme stratejisi önemlidir. Kritik olmayan araçların defer ile yüklenmesi veya kullanıcı etkileşiminden sonra başlatılması, birincil sayfa yükleme süresi üzerindeki etkiyi azaltır. Tag manager üzerinden yönetilen scriptlerde ise zaman içinde eklenen ama hiç kaldırılmayan etiketler birikebilir; düzenli denetim yapmadan bu birikimi fark etmek güçtür.

CLS'e yol açan yeni içerik blokları

Cumulative Layout Shift (CLS), sayfanın görsel kararlılığını ölçer. Yayın günündeki CLS skoru düşük olabilir; ama zamanla eklenen yeni içerik tipleri bu dengeyi bozar. Bunun en yaygın kaynakları şunlardır: boyutsuz görseller, geç yüklenen reklamlar veya promosyon bantları, sayfa yüklendikten sonra eklenen yazı tipleri.

Bir blog yazısına eklenen gömülü sosyal medya widget'ı, iframe içinde belirli bir yükseklik tanımlanmamışsa sayfanın geri kalan içeriğini aşağı itmesine neden olur. Bu blok tek bir sayfada olsa bile, aynı şablon kullanılan diğer sayfalarda da CLS oluşturabilir. Şablon kararları tek sayfa gibi görünür, etkisi ise yüzlerce sayfayı kapsar.

Yazı tipi kayması da CLS'in sessiz bir kaynağıdır. Sistem yazı tipiyle başlayan bir metin, web fontu yüklendiğinde yerinden oynar; bu, font-display: swap kullanımının getirdiği kaçınılmaz bir takas noktasıdır. Yayın döneminde tek bir yazı tipi varken sonradan eklenen ikincil bir font ailesi bu problemi yeniden gündeme getirebilir.

Reklamlar ve kişiselleştirme blokları ise en tahmin edilemez CLS kaynaklarıdır. İçerik sunucusundan gelen bir promosyon bandı, sayfanın ne zaman ve nasıl şekilleneceğini önceden tahmin edilemeyen bir değişkene bağlar. Bant için sayfada önceden yer ayırmak - boş bir placeholder - bu kaymayı büyük ölçüde önler.

Cache ve CDN yapılandırması nasıl kayar

İlk kurulumda cache headers doğru ayarlanmıştır, CDN kuralları yerli yerindedir. Sonra bir güncelleme gelir: tema değişikliği, yeni bir rota, farklı bir sunucu yapılandırması. Yanlış gitmiş. Cache kuralları artık bazı kaynaklar için çalışmıyor, CDN edge'inde bir şeyler her seferinde yeniden çekiliyor olabilir.

Bu tür kayma çok dikkat çekmeden gerçekleşir. TTFB aniden fırlamaz; yavaş yavaş artar. Bir gün fark edilir ki sık ziyaret edilen bir sayfanın ilk bayt süresi, cache varken olması gerekenin üç katına çıkmış. Nedeni araştırıldığında, yeni eklenen bir endpoint için cache bypass kuralı yanlış yazılmış ve orijin sunucuya trafik akıyor olduğu görülür.

CDN yapılandırmasının zamanla kaymaması için yapılan her sunucu tarafı değişikliğin cache davranışını kontrol etmesi gerekir. Response headerlarını izlemeye almak - özellikle Cache-Control, Age ve CDN'e özgü hit/miss başlıklarını - bu tür kaymaları erken yakalamanın pratik yoludur.

Performans borcunu tespit etmek ve önceliklendirmek

Teknik borca benzer bir kavramdır bu: her küçük kararın bedeli ileride ödenir. Ama teknik borçtan farkı, performans borcunun belirli metriklerle ölçülebilir olmasıdır. Sorun, bu ölçümün sürekli yapılmaması durumunda borcun ne kadar biriktiğinin görülememesidir.

Gerçek kullanıcı verisi toplamak bu noktada kritik öneme sahiptir. Alan verisi (RUM - Real User Monitoring) olmaksızın performans düşüşü yalnızca şikayet geldiğinde veya bir denetim sırasında fark edilir; oysa aylardır yavaş yavaş kötüleşiyor olabilir. Sürekli alan verisi, trendi erken gösterir.

Tespit yapıldıktan sonra önceliklendirme şu iki soruyla başlar: hangi metriği etkiliyor ve kaç sayfayı kapsıyor? LCP'yi etkileyen ve tüm ürün sayfalarını kapsayan bir görsel boyut problemi, yalnızca tek bir blog şablonundaki CLS sorununa göre daha acil bir önceliğe sahiptir. Bu kararı verebilmek için hangi sayfanın hangi metriğinin ne kadar etkilendiğini gösteren veriye ihtiyaç vardır.

Tek seferlik iyileştirmeler, erozyon hızından yavaş kalırsa kalıcı bir iyileşme sağlamaz. Performans borcunu geri ödemek kadar, yeni borcun birikmesini önleyen bir süreç oluşturmak da gereklidir: yükleme sürecinde görsel boyut kontrolü, her deploy sonrası otomatik bir Lighthouse çalıştırması veya ekip içinde yerleşik bir "bu bileşen ne kadar ağır?" alışkanlığı bunların somut örnekleridir.