Site hızı ve performans bütçesi: premium tasarımı hızdan ödün vermeden yönetmek

Site hızı, kullanıcının bir sayfada üç anı ne kadar çabuk yaşadığıdır: ana içeriğin görünmesi, ilk dokunuşa yanıt ve yerleşimin kaymadan sabit kalması. Google bu üç anı Önemli Web Verileri ile ölçer: yükleme için LCP, etkileşim için INP, görsel kararlılık için CLS; üçü birlikte sayfa deneyiminin hız tarafını oluşturur.

Kurumsal sitede hız tek seferlik bir düzeltme değildir. Her kampanya görseli, yeni pazarlama etiketi ve animasyon sayfaya ağırlık ekler. Lansmanda hızlı açılan site, sınırın sahibi olmadığı için zamanla yavaşlar; kimse tek başına hata yapmaz, ağırlık parça parça birikir.

Performans bütçesi (performance budget) bu sahipsizliği çözer. web.dev'in tanımıyla bütçe, site performansını etkileyen metriklere konan sınırlar dizisidir: sayfanın toplam boyutu, yüklenme süresi ya da istek sayısı. Biz bütçeyi tasarım, geliştirme ve pazarlama ekiplerinin ortak kabul kriteri olarak yazarız. Yeni bir öğe sayfaya girmeden önce bütçede yer bulur; yer yoksa başka bir öğe çıkar ya da yeni öğe hafifletilir.

Performans bütçesi üç tür sınırdan oluşur: miktar sınırları, kullanıcı odaklı zamanlama sınırları ve kural tabanlı puan sınırları. web.dev'in "Performans bütçeleri 101" rehberi bu türleri ayırır ve miktar ile kullanıcı odaklı metriklerin birlikte izlenmesini önerir, çünkü ikisi farklı riskleri yakalar.

Miktar bütçesi

Görsel boyutu, web yazı tipi sayısı, JavaScript boyutu ve üçüncü taraf istek sayısı gibi ölçülebilir ağırlıklara sınır koyar. Tasarımcı ile geliştirici aynı dili konuşur; bir kampanya görselinin sınırı aşıp aşmadığı tasarım dosyasında görülür.

Zamanlama bütçesi

LCP ve INP ile kullanıcının beklediği anlara sınır koyar; görsel kararlılık (CLS) da aynı bütçede tavanla izlenir. Aynı ağırlıktaki iki sayfa, kaynakların yüklenme sırasına göre farklı hızda algılanır. Ağırlık tek başına deneyimi anlatmaz.

Kural tabanlı bütçe

Lighthouse gibi araçların denetim kurallarından ürettiği puana alt sınır koyar. Hızlı uyarı verir ama gerçek kullanıcıyı temsil etmez. Aşağıdaki tabloda üç türün nerede kontrol edildiğini ve karar gücünü gösteriyoruz.

Site hızı iki kaynaktan ölçülür: gerçek ziyaretlerden gelen saha verisi ve sabit cihaz ve ağ koşullarında yapılan kontrollü testten gelen laboratuvar verisi. Saha verisi kullanıcının son 28 günde ne yaşadığını, laboratuvar verisi yavaşlığın nedenini gösterir; bütçe ilkini aylık değerlendirmede, ikincisini sürüm kapısında kullanır.

Saha verisinin ana kaynağı Chrome Kullanıcı Deneyimi Raporu'dur (CrUX). Search Console'daki Core Web Vitals raporu bu veriyi kullanır, benzer sayfaları URL grupları halinde toplar ve grubun durumunu en zayıf metriğe göre belirler. Rapordaki değer, son 28 gündeki sayfa isteklerinin yüzde 75'inin ulaştığı süredir. PageSpeed Insights aynı saha verisini üst bölümde, laboratuvar teşhisini alt bölümde gösterir; web.dev saha verisi varsa önce ona bakılmasını önerir.

Laboratuvar verisi Lighthouse, Chrome Geliştirici Araçları ya da WebPageTest gibi araçlarla üretilir. Yayına çıkmamış bir sürümü ölçmenin yolu budur. CrUX yalnız yeterli ziyaret alan sayfaların verisini yayımlar. Trafiği düşük sayfalar için web-vitals kütüphanesiyle kendi gerçek kullanıcı ölçümünüzü kurarsınız.

Zamanlama bütçesinin tavanı Önemli Web Verileri'nin "iyi" eşikleridir: LCP için 2,5 saniye, INP için 200 milisaniye, CLS için 0,1. Eşik mobil ve masaüstü için ayrı ayrı, sayfa yüklemelerinin 75. yüzdeliğinde karşılanır; dört ziyaretten en az üçü hedefin içinde kalır, kalan ziyaretlerdeki aykırı değerler sınıflandırmayı tek başına değiştirmez.

web.dev bu yüzdeliği bilerek seçtiğini anlatır: daha yüksek bir yüzdelik, kararsız bağlantılardan gelen birkaç aykırı ziyaretle bozulur. Eşikler cihaza göre değişmez, çünkü kullanıcının iyi deneyim beklentisi cihazdan bağımsızdır. Aynı kaynak, sitelerin iyi eşiğin ötesinde kendi iş metrikleriyle ilişkili hedefler arayabileceğini de yazar.

Biz eşikleri hedef değil tavan olarak kullanırız. Bütçe mevcut ölçümden başlar ve eşiğin altında pay bırakır; tek bir yeni etiket sayfayı "iyileştirme gerektiriyor" bandına itemez. LCP payını alt bölümlere de dağıtırız. web.dev'e göre iyi optimize edilmiş sayfada sürenin yaklaşık yüzde 40'ı ilk bayta kadar geçen süreye (TTFB), yaklaşık yüzde 40'ı LCP kaynağının indirilmesine gider. Kaynak yükleme gecikmesi ile öğe oluşturma gecikmesi ise yüzde 10'un altında kalır.

Her sayfa türü kendi bütçesini alır, çünkü ilk ekranda yüklenen en büyük öğe ve en riskli bileşen sayfa türüne göre değişir. web.dev de içeriği farklı olan sayfa türleri için ayrı bütçe tutulmasını önerir; ürün, arama ve ana sayfa için ayrı örnek sınırlar verir. Ana sayfada LCP öğesi genellikle kampanya görselidir, blog yazısında başlık metni, kategori sayfasında ilk satırdaki ürün görselleri. Tek bir site geneli sınır bu farkı göremez.

Sayfa türü bütçesi karar tartışmasını kısaltır. Ürün ekibi yeni bir filtre bileşeni istediğinde kategori sayfasının INP payına, pazarlama yeni bir etiket istediğinde açılış sayfasının bütçesine bakılır. Reklam trafiği alan sayfada hız, mesaj eşleşmesiyle birlikte değerlendirilir; Google Ads landing page kurgusu yazımız iki işi aynı sayfada ele alır. Büyük kataloglarda filtrelerin ürettiği sayfalar hem hız hem tarama yükü getirir. Hangilerinin açık kalacağına filtreli gezinme (faceted navigation) mimarisi karar verir.

Tablodaki karar kuralları, yeni bir şablon tasarlanırken ilk bakılan yerdir.

Premium tasarım ile site hızı arasındaki çatışma çoğunlukla öğenin kendisinden değil, öğenin ne zaman ve nasıl yüklendiğinden doğar. Büyük bir hero görseli LCP bütçesine sığabilir; aynı görsel JavaScript ile sonradan eklenirse ya da geç yüklemeye (lazy loading) bırakılırsa aynı bütçeyi aşar. Her premium öğe için iki soru sorarız: markaya ve dönüşüme ne katıyor, bütçeden ne alıyor?

Hero görseli ve video

İlk ekran görseli HTML içinde src ya da srcset ile doğrudan yer alır ve fetchpriority="high" ile işaretlenir; dosya AVIF ya da WebP biçiminde, ekran boyutuna uygun sunulur. web.dev'in uyarısı nettir: LCP görseli asla geç yüklenmez. Yüksek öncelik tek görsele verilir; kayan galerinin görünmeyen kareleri düşük önceliğe alınır. Videoda LCP, poster görseli ya da ilk kareden hangisi önce gelirse onunla ölçülür; hafif bir poster videoyu bütçeye sokar.

Animasyon ve yazı tipi

Animasyonlar transform ve opacity özellikleriyle kurulur; düzeni ya da boyamayı tetikleyen özellikler kesin gerekmedikçe kullanılmaz. Görsel ve videolara width ve height verilir ya da aspect-ratio ile alan ayrılır; CLS payı böyle korunur. Web yazı tipi sayısı miktar bütçesine yazılır. LCP öğesi metinse o yazı tipi önceden yüklenir.

Üçüncü taraf scriptler için kuralımız şudur: her etiketin bir sahibi, yazılı bir amacı ve ölçülmüş bir maliyeti olur; biri eksik olan etiket sayfaya girmez. Analiz, reklam, canlı destek, A/B testi ve gömülü video araçları site sahibinin kontrolü dışındaki sunuculardan gelir. web.dev bu scriptleri yavaşlamanın yaygın nedenleri arasında sayar: fazla ağ isteği ve ana iş parçacığını meşgul eden JavaScript.

INP payı en çok burada zorlanır. 50 milisaniyeden uzun süren her görev uzun görev sayılır ve tarayıcı görev sürerken etkileşimi bekletir. A/B testi kütüphaneleri ayrıca içeriği, kullanıcının hangi deneyde olacağına karar verene kadar gizleyerek LCP'yi geciktirebilir. Dönüşüm optimizasyonu programlarında test aracını LCP ve INP üzerindeki etkisini ölçerek seçeriz.

Etiket kaydı tek tabloda tutulur: etiket adı, sahibi, amacı, yüklendiği sayfalar, yükleme biçimi (hemen, ertelenmiş ya da etkileşimle), ölçülen maliyet ve gözden geçirme tarihi. Google Etiket Yöneticisi (Google Tag Manager) etiketleri tek yerden yönetmeyi kolaylaştırır ama maliyeti ortadan kaldırmaz. Kapsayıcıdaki her etiket aynı kayda girer.

Bütçe her sürümden önce derleme hattındaki otomatik bir kontrolle denetlenir ve sınırı aşan değişiklik yayına çıkmaz. Kontrol hatta bağlı olduğu için kural kişilere değil sürece aittir; web.dev bu iş için webpack performans uyarılarını, bundlesize'ı ve Lighthouse CI'ı örnek verir.

Lighthouse CI, kaynak türüne göre boyut ve istek sayısı sınırlarını doğrudan denetleyebilir. Bütçe dosyası sürüm kontrolünde, kodla birlikte durur. Kontrol öncelikli şablonların her birinde birden fazla ölçüm alır, çünkü tek laboratuvar ölçümü dalgalanır. Sonuç sürüm notuna bütçe satırı olarak yazılır: şablon, metrik, önceki değer ve yeni değer.

Sınır aşıldığında web.dev'in saydığı üç yol vardır: mevcut bir öğeyi optimize etmek, mevcut bir öğeyi kaldırmak ya da yeni öğeyi eklememek. Bütçeyi sessizce büyütmek dördüncü bir yol değildir; sınır ancak çeyreklik gözden geçirmede gerekçesiyle değişir. Sürüm öncesi denetimin hız dışındaki maddelerini teknik SEO kontrol listesi yazısında topladık.

Site hızı, Google'ın sayfa deneyimi değerlendirmesinin bir parçasıdır ama sıralamayı tek başına belirlemez. Google Arama Merkezi, Önemli Web Verileri'nin sıralama sistemlerinde kullanıldığını yazar; aynı belgeye göre tek bir "sayfa deneyimi sinyali" yoktur ve deneyim zayıf olsa bile en alakalı içerik gösterilmeye çalışılır.

Belgenin pratik sonucu açıktır: aynı soruya faydalı cevap veren çok sayıda sayfa olduğunda iyi sayfa deneyimi fark yaratır. Google, raporlarda iyi sonuç almanın üst sıra anlamına gelmediğini ve yalnız SEO için kusursuz puan peşinde koşmanın zaman kaybı olabileceğini de yazar. Bütçeyi puan için değil, kullanıcı için kurarız. Sıralamada önce içeriğin alakası ve güvenilirliği gelir; uzman içerikte E-E-A-T sinyalleri bu tarafı kurar.

İş etkisini görmek için hız verisi dönüşüm verisiyle aynı raporda okunur. Şablonlar hız bantlarına ayrılır ve her bantta talep ya da satış oranı izlenir. Ön koşul, dönüşümün doğru sayılmasıdır; GA4'te önemli etkinlik (key event) kurulumu bu karşılaştırmanın temelidir. Kurumsal web tasarım projelerimizde bu ölçüm noktasını yayından önce kurarız.

Performans bütçesi, her sınırın bir sahibi ve her kontrolün bir takvimi olduğunda çalışır. Biz sorumluluğu beş rol arasında paylaştırırız (tasarım, ön yüz geliştirme ve BT, pazarlama, finans ve yönetim, ajans) ve kontrolü her sürüm, her ay ve her çeyrek olmak üzere üç ritme bağlarız. Rollerin işi şöyledir:

1. Tasarım: şablonun ilk ekran öğesini ve yazı tipi sayısını bütçeye göre seçer, ağır öğe için hafif bir alternatif hazırlar.
2. Ön yüz geliştirme ve BT: bütçe dosyasını derleme hattına bağlar, her sürümde laboratuvar ölçümünü çalıştırır.
3. Pazarlama: etiket kaydının sahibidir; yeni etiket için amaç ve kaldırma tarihi yazar.
4. Finans ve yönetim: karar kaydından hız yatırımının hangi şablonda hangi iş sonucuyla yapıldığını izler.
5. Ajans (Dijital.co): bütçeyi yazar, saha verisini yorumlar ve çeyreklik gözden geçirmeyi yürütür.

Karar kaydı, değişen her sınırı tarih ve gerekçesiyle tutar. Tasarım ile geliştirmeyi tek döngüde isteyen ekipler için web geliştirme hizmetimiz bu ritmi platformun bakım düzenine bağlar.

Performans bütçesi var olan hızı korur ve yeni ağırlığı sınırlar; yavaş bir sunucuyu ya da hantal bir altyapıyı tek başına hızlandırmaz. Sunucu yanıtı yavaşsa ilk bayta kadar geçen süre yüksek kalır ve web.dev'e göre 2,5 saniyelik LCP hedefine ulaşmak zorlaşır, hatta imkansızlaşabilir. Böyle bir sitede önce sunucu, önbellek, içerik dağıtım ağı (CDN) ve yönlendirme zinciri ele alınır, bütçe sonra yazılır.

Dört durumda bütçe ikinci plandadır. Birincisi, CrUX'un popülerlik eşiğine ulaşmayan düşük trafikli sitelerdir. Saha verisi olmadan zamanlama bütçesi yalnız laboratuvarla izlenir; gerçek kullanıcı ölçümü kurulana kadar karar gücü sınırlı kalır. İkincisi, kısa ömürlü kampanya sayfalarıdır; 28 günlük saha verisi oluşmadan kampanya biter, yalnız sürüm kapısı uygulanır.

Üçüncüsü, trafiğin önemli bir kısmının yavaş bağlantılı ülkelerden geldiği sitelerdir. Search Console verisi tüm konumları birleştirdiği için ülke kırılımı ayrıca okunur. Dördüncüsü, içerik soruya cevap vermiyorsa hız bunu telafi etmez; Google deneyim zayıf olsa bile en alakalı içeriği öne çıkarmaya çalışır.