Performans Bütçesi Nedir? Sitenin Hızlı Kalması İçin Sınırlar Nasıl Konur?

Kısacası performans bütçesi, hızı bir kerelik proje olmaktan çıkarıp kalıcı bir kurala dönüştürür. Biz Talha Aslan ve ekibi olarak sahada sık gördüğümüz tabloyu şöyle özetleyebiliriz: site yayına hızlı çıkar, ardından ekipler her ay bir slider, bir sohbet eklentisi, yeni bir izleme kodu ekler ve bir yıl sonra kimse sayfanın neden ağırlaştığını hatırlamaz. Bütçe bu yavaş birikimi durdurmak için var.

Bu rehberde bütçenin hangi metriklerden oluştuğunu, ilk sınırları nasıl belirleyeceğinizi, bütçeyi ekipte nasıl uygulatacağınızı ve Search Console ile nasıl izleyeceğinizi adım adım anlatıyoruz. Örnek rakamlar "örnek senaryo" olarak işaretli; kesin hedef sizin sitenize ve kullanıcılarınıza göre değişir.

Performans bütçesi hangi sorunları çözer?

Hız sorunlarının çoğu tek bir büyük hatadan değil, küçük kararların toplamından doğar. Örneğin pazarlama ekibi yeni bir etiket ister, tasarımcı daha büyük bir kahraman görseli önerir, geliştirici bir kütüphane ekler. Her karar tek başına makul durur; ancak toplamı sayfayı yavaşlatır.

Bütçe bu durumda ortak bir dil sağlar. Tartışma "bence site yavaş" düzeyinden "ana sayfa JavaScript sınırını aştı" düzeyine iner. Böylece karar kişisel zevke değil, ekibin önceden kabul ettiği bir sınıra dayanır. web.dev'deki Performance Budgets 101 yazısı da bütçeyi tasarım, teknoloji ve özellik kararları için bir referans noktası olarak tanımlar.

• Yeni özellik eklerken hızın gözden kaçmasını önler.
• Tasarım, yazılım ve pazarlama ekiplerine aynı hedefi verir.
• Gerilemeyi kullanıcılar fark etmeden, yayın öncesinde yakalar.
• Hız çalışmasını tek seferlik bir projeden sürekli bir disipline çevirir.

Performans bütçesinde hangi metrik türlerini kullanırsınız?

web.dev bütçe metriklerini üç gruba ayırır. Bu ayrım, hangi sınırı nerede kontrol edeceğinizi belirlediği için önemlidir. Dolayısıyla ilk adım, her gruptan en az bir metrik seçmektir.

Pratikte en sağlam bütçe üçünü birleştirir. Miktar sınırları geliştiricinin günlük işini yönlendirir; zaman sınırları kullanıcı deneyimini korur; kural temelli puan ise hızlı bir sağlık göstergesi olur.

Sayfa ağırlığı ve istek sayısı için sınır nasıl konur?

Miktar temelli sınırlar, bütçenin en somut parçasıdır. Önce sayfadaki kaynakları türlerine göre ayırın: görseller, JavaScript, CSS, fontlar, üçüncü taraf kaynaklar ve toplam. Ardından her tür için ayrı bir tavan belirleyin.

web.dev, rakip analizi yapacak zamanı olmayanlar için başlangıç noktası olarak kritik yoldaki kaynakların sıkıştırma sonrası 170 KB altında kalmasını önerir. Bu değer yavaş mobil ağ ve orta seviye cihaz varsayımına dayanır; yani bir kural değil, bir çıkış noktasıdır. Görsel ağırlıklı bir katalog sitesi farklı, metin ağırlıklı bir blog farklı sınır ister.

İstek sayısı da ayrı bir kalemdir. Özellikle üçüncü taraf istekleri (reklam, analiz, sohbet, harita) zamanla artar. Bu nedenle "üçüncü taraf istek sayısı" için ayrı bir sınır koymanızı öneririz. Görsellerin ağırlığını düşürmek için web sitesi görsel optimizasyonu rehberimize ve hızlı bir deneme için resim küçültme aracımıza bakabilirsiniz.

JavaScript bütçesini neden ayrı tutmalısınız?

JavaScript, aynı boyuttaki bir görselden daha pahalıdır; çünkü tarayıcı onu indirdikten sonra ayrıştırır, derler ve çalıştırır. Bu iş ana iş parçacığını (main thread) meşgul eder ve kullanıcının tıklamasına geç yanıt vermenize yol açar. Bu yüzden JavaScript için toplam ağırlıktan bağımsız, ayrı bir sınır koymak mantıklıdır.

web.dev'in örnek bütçeleri arasında "ürün sayfası mobilde 170 KB'tan az JavaScript gönderir" gibi bir kural da yer alır. Ayrıca aynı kaynak, görsel ağırlıklı sitelerin JavaScript sınırını daha sıkı tutmasını önerir; çünkü toplam bütçenin büyük kısmını görseller tüketir.

JavaScript'in hızı nasıl etkilediğini ayrıntılı görmek isterseniz JavaScript ve site hızı yazımızı okuyabilirsiniz. Bütçe açısından asıl soru şudur: yeni eklenen her kütüphane, kullanıcıya bu maliyete değecek bir fayda veriyor mu?

Performans bütçesinde LCP, INP ve CLS hedefleri ne olmalı?

Zaman temelli bütçenin omurgası Core Web Vitals metrikleridir. web.dev Web Vitals sayfasına göre iyi bir deneyim için LCP (en büyük içerikli boyama) 2,5 saniye veya altında, INP (bir sonraki boyamaya etkileşim) 200 milisaniye veya altında, CLS (kümülatif düzen kayması) 0,1 veya altında olmalıdır.

Bu eşikleri tek bir ziyaretle değil, sayfa yüklemelerinin 75. yüzdelik dilimiyle, mobil ve masaüstü için ayrı ayrı değerlendirirsiniz. Yani kullanıcılarınızın büyük çoğunluğu hedefin içinde kalmalıdır. Üç metrik de hedefi karşılarsa sayfa bu değerlendirmeden geçer.

Metriklerin ne anlama geldiğini Core Web Vitals nedir yazımızda anlattık. Bütçe tarafında ise öneri basit: resmi eşikleri tavan olarak alın, kendi hedefinizi biraz daha sıkı koyun ki küçük bir gerileme hemen "kötü" bölgeye düşmesin.

LCP bütçesini hangi kalemler tüketir?

LCP genellikle sayfanın en büyük görseli ya da en büyük metin bloğudur. Dolayısıyla LCP bütçesini en çok sunucu yanıt süresi, kahraman görselinin boyutu, oluşturmayı engelleyen CSS ve geç keşfedilen kaynaklar tüketir.

1. Sunucunun ilk baytı ne kadar sürede gönderdiğini ölçün.
2. LCP öğesinin ne olduğunu belirleyin; çoğu zaman bir görseldir.
3. Bu görselin boyutunu ve formatını kontrol edin.
4. Görselin geç yüklenip yüklenmediğine bakın; ilk ekrandaki görsele tembel yükleme uygulamayın.
5. Oluşturmayı engelleyen CSS ve font dosyalarını azaltın.

Örneğin bir ana sayfada LCP hedefiniz 2 saniye ise bu süreyi parçalara ayırabilirsiniz: sunucu yanıtına, kaynak keşfine, indirmeye ve çizime ayrı paylar. Bu bir örnek hesap; amacı, hangi parçanın bütçeyi aştığını görmenizi sağlamaktır. Ayrıntılı teknikler için LCP optimizasyonu rehberimize göz atın.

INP bütçesi neden laboratuvarda ölçülemez?

INP gerçek kullanıcı etkileşimine dayanır: tıklama, dokunma ya da tuş basımı ile tarayıcının bir sonraki çizimi arasındaki süre. web.dev'e göre 200 milisaniye ve altı iyi, 200 ile 500 milisaniye arası iyileştirme gerektirir, 500 milisaniyenin üstü ise zayıf bölgededir.

Ancak Lighthouse gibi laboratuvar araçları INP ölçemez; çünkü ortada gerçek bir kullanıcı yoktur. web.dev bu nedenle laboratuvarda Total Blocking Time (toplam engelleme süresi) metriğini yaklaşık gösterge olarak kullanmayı önerir. Bütçenizde bu yüzden iki ayrı satır olmalı: laboratuvar için TBT sınırı, sahada ise INP hedefi.

INP'yi düşürmenin yöntemlerini INP iyileştirme yazımızda topladık. Bütçe açısından en etkili adım, ana iş parçacığını uzun süre meşgul eden betikleri sınırlamaktır.

İlk performans bütçesini adım adım nasıl belirlersiniz?

web.dev'in ilk performans bütçesi rehberi, işe ölçüm ve kıyaslama ile başlamayı önerir. Biz de müşteri sitelerinde benzer bir sıra izliyoruz.

1. Önemli sayfaları seçin: ana sayfa, en çok trafik alan kategori ya da ürün sayfası, en çok dönüşüm getiren açılış sayfası.
2. Bugünkü değerleri ölçün: mobil ve masaüstü için ayrı ayrı.
3. Benzer siteleri kıyaslayın: sektörünüzdeki birkaç rakibin aynı tür sayfasını aynı koşullarda test edin.
4. Uzun vadeli hedef koyun: web.dev, en hızlı rakipten en az yüzde 20 daha hızlı olmayı önerir.
5. Gerçekçi bir ilk bütçe belirleyin: hedef uzaksa, bugünkü değerden yüzde 20 daha iyi bir ara hedefle başlayın.
6. Miktar ve kural sınırlarını ekleyin: JavaScript, görsel, istek sayısı ve Lighthouse puanı.

Örnek senaryo: example.com ana sayfasının mobil LCP değeri bugün 4 saniye. Uzun vadeli hedef 2,5 saniyenin altı; ilk bütçe ise yaklaşık 3,2 saniye. Ekip bu ara hedefe ulaşınca bütçeyi bir sonraki adıma sıkılaştırır.

Farklı sayfa türleri için ayrı bütçe gerekir mi?

Evet, gerekir. Bir blog yazısı ile bir ürün listeleme sayfasının içeriği birbirinden çok farklıdır; dolayısıyla tek bir sınır ya biri için gereksiz sıkı ya da diğeri için fazla gevşek olur. web.dev de sayfa türüne göre ayrı bütçe kurmayı önerir.

Tablodaki sınırlar örnek senaryodur; değerleri kendi ölçümlerinize göre doldurun. Önemli olan, her sayfa türünün en kritik kalemini bilmenizdir.

Performans bütçesini Lighthouse ile nasıl kontrol edersiniz?

Lighthouse, bütçeyi bir dosya üzerinden okuyabilir. web.dev'in Lighthouse bütçe rehberine göre bu dosya genelde budget.json adını taşır ve üç tür sınır içerebilir: timings (milisaniye cinsinden süreler), resourceSizes (kaynak türüne göre KB cinsinden boyutlar) ve resourceCounts (kaynak türüne göre istek sayıları).

Lighthouse'u komut satırından bu dosyayla çalıştırdığınızda HTML raporunda Performance kategorisinin altında Budgets bölümünü bulursunuz. Böylece hangi kaynak türünün sınırı ne kadar aştığını tek bakışta görürsünüz. Aynı rehber önemli bir uyarı da yapar: Lighthouse laboratuvar verisi üretir, bu yüzden sonuçları gerçek kullanıcı verisiyle karşılaştırmanız gerekir.

Lighthouse raporunu okumayı bilmiyorsanız Lighthouse ile performans testi yazımız iyi bir başlangıçtır. Bütçe için web.dev, performans puanı tarafında 100 üzerinden en az 85 gibi bir kural temelli sınırı örnek olarak verir.

Bütçeyi geliştirme sürecine nasıl bağlarsınız?

Bütçe yalnız bir belgede yaşarsa birkaç hafta içinde herkes onu unutur. Asıl değer, onu derleme ve yayın sürecine bağladığınızda ortaya çıkar. web.dev bu iş için açık kaynak üç seçenek sayar: webpack'in yerleşik performans uyarıları, paket boyutunu kontrol eden bundlesize ve Lighthouse sonuçlarını bütçeyle karşılaştıran Lighthouse CI.

Örneğin Lighthouse CI'ı her çekme isteğinde (pull request) çalıştırırsanız, sınırı aşan değişiklik birleşmeden önce ortaya çıkar. Ardından ekip üç seçenekten birini seçer: mevcut özelliği optimize eder, başka bir şeyi kaldırır ya da yeni özelliği eklemekten vazgeçer. web.dev de sınır aşıldığında bu üç yolu önerir.

Kod tarafında otomatik kontrol kuramıyorsanız bile haftalık manuel ölçüm ve basit bir tablo, hiç bütçe olmamasından çok daha iyidir.

Performans bütçesini ekipte nasıl uygularsınız?

Bütçenin teknik kısmı kolaydır; zor olan, insanların ona uymasıdır. Bu yüzden bütçeyi baştan "geliştiricinin işi" olarak değil, ortak bir sözleşme olarak konumlandırın.

• Bir sahip belirleyin: bütçeyi kim günceller, aşımı kim onaylar?
• Pazarlama ekibine izleme kodu eklerken soracağı soruyu öğretin: bu kod hangi kalemden harcıyor?
• Tasarım aşamasında görsel ve font sınırlarını paylaşın; böylece tasarımcı en baştan sınır içinde çalışır.
• Aşımları istisna olarak kaydedin; tarih, sebep ve geri alma planı yazın.
• Bütçeyi üç ayda bir gözden geçirin; ulaşılan hedefi sıkılaştırın.

Sahada gördüğümüz en yaygın hata, bütçeyi tek kişinin bilmesidir. O kişi işten ayrıldığında bütçe de kaybolur. Bu nedenle sınırları proje belgelerine, tasarım dosyalarına ve yayın kontrol listesine yazmanızı öneririz.

Üçüncü taraf betikleri bütçeyi nasıl aşar?

Üçüncü taraf betikler bütçenin en sinsi tüketicisidir; çünkü biri onları siteye bir kez ekler, sonra kimse sorgulamaz. Üstelik bu betikler kendi başına yeni istekler başlatabilir ve siz fark etmeden ağırlığı artırabilir.

web.dev'in Lighthouse bütçe örneğinde üçüncü taraf istek sayısı için ayrı bir sınır yer alır. Biz de her projede bunu öneriyoruz. Ayrıca yılda en az bir kez etiket envanteri çıkarın: hangi etiket aktif, kim istedi, hâlâ işe yarıyor mu?

Öte yandan bazı betikler gerçekten gereklidir. Amaç onları tamamen kaldırmak değil, yükleme zamanını ve önceliğini bilinçli seçmektir. Örneğin sohbet aracını kullanıcı etkileşiminden sonra yüklemek, ilk yükleme bütçesini rahatlatabilir.

Performans bütçesi ile hız optimizasyonu arasındaki fark nedir?

Hız optimizasyonu, var olan bir sorunu çözmek için yaptığınız işlerin bütünüdür: görselleri küçültmek, kullanılmayan kodu kaldırmak, önbellek ayarlarını düzenlemek gibi. Performans bütçesi ise bu kazanımların zamanla geri gitmesini önleyen kuraldır. Biri tedavi, diğeri korunma gibi düşünülebilir.

Sahada sık rastladığımız örnek senaryo şöyle: bir site kapsamlı bir hız çalışmasından sonra iyi değerlere ulaşır, ekip rahatlar ve birkaç ay içinde yeni eklemelerle değerler eski hâline döner. Bu durumda sorun optimizasyonun kalitesi değil, ardından bir bütçe kurulmamasıdır.

Bu yüzden her hız çalışmasının son adımı, ulaşılan değerleri bütçe olarak kayda geçirmek olmalıdır. Örneğin optimizasyon sonrası ana sayfanın JavaScript boyutunu ölçün ve bunu küçük bir pay ekleyerek tavan yapın. Böylece kazandığınız hızı korursunuz ve bir sonraki değişiklikte neyi feda ettiğinizi bilirsiniz. Ayrıca teknik SEO kontrollerinin geri kalanı için teknik SEO ipuçları yazımıza göz atabilirsiniz.

Performans bütçesini Search Console ile nasıl izlersiniz?

Bütçeyi laboratuvarda tutmak yetmez; gerçek kullanıcıların ne yaşadığını da izlemeniz gerekir. Search Console'daki Core Web Vitals raporu bunun için en pratik yerdir. Search Console Yardım sayfasına göre rapor, CrUX (Chrome Kullanıcı Deneyimi Raporu) kaynaklı gerçek kullanıcı verisini kullanır ve URL gruplarını Poor (zayıf), Need improvement (iyileştirme gerekli) ve Good (iyi) olarak sınıflandırır.

Bir grubun durumu, o gruptaki en kötü metriğe bağlıdır. Yani LCP ve CLS iyi olsa bile INP zayıfsa grup da zayıf durumda kalır. Düzeltme yaptıktan sonra sorun ayrıntı sayfasındaki Start Tracking ile doğrulamayı başlatırsınız; Google 28 günlük bir izleme penceresinde sorunun tekrar edip etmediğine bakar.

Search Console'a yeniyseniz Google Search Console nedir yazımızla başlayabilirsiniz. Bütçe takibinde bu raporu ayda en az bir kez kontrol etmenizi öneririz.

Laboratuvar ve saha verisi bütçede nasıl birlikte işe yarar?

Laboratuvar verisini kontrollü bir ortamda, sabit cihaz ve ağ koşuluyla üretirsiniz. Bu yüzden geliştirme sırasında gerilemeyi yakalamak için idealdir. Saha verisi ise gerçek kullanıcıların farklı cihaz ve bağlantılarla yaşadığı deneyimi gösterir; ancak birikmesi zaman alır.

İyi bir bütçe ikisini birbirine bağlar. Laboratuvar sınırlarını her çekme isteğinde kontrol edersiniz; saha hedeflerini ise aylık raporda takip edersiniz. İkisi arasında tutarsızlık görürseniz, laboratuvar koşullarınızın gerçek kullanıcılarınızı temsil etmediğini düşünün. Örneğin kullanıcılarınızın çoğu orta seviye telefonla geliyorsa, testleri güçlü bir masaüstünde yapmak yanıltıcı olur.

web.dev, kendi saha verinizi toplamak için web-vitals JavaScript kütüphanesini de anar. Bu sayede CrUX verisi yetersiz olan küçük sitelerde bile kendi ölçümünüzü yapabilirsiniz.

Performans bütçesi sıralamayı garanti eder mi?

Hayır, garanti etmez. Google'ın sayfa deneyimi belgesi, raporlarda iyi sonuç almanın sayfalarınızın en üst sırada çıkacağını garanti etmediğini açıkça yazar. Aynı belgeye göre Google, sayfa deneyimi zayıf olsa bile en alakalı içeriği göstermeye çalışır.

Peki bütçe neden önemli? Çünkü aynı sorguda birçok faydalı sayfa yarıştığında iyi sayfa deneyimi fark yaratabilir. Ayrıca hız doğrudan kullanıcı davranışını etkiler: yavaş sayfadan çıkan ziyaretçi ne okur ne de form doldurur. Yani bütçe, sıralama için tek başına bir kaldıraç değil, içeriğinizin değerini kullanıcıya ulaştıran altyapıdır.

Biz SEO çalışmalarında hızı içerik, teknik yapı ve bağlantı çalışmasıyla birlikte ele alıyoruz. SEO danışmanlığı hizmetimizde performans bütçesini sitenize özel kurar, aşımları ekiplerinizle birlikte takip ederiz.

Görsel ve font bütçesini nasıl hesaplarsınız?

Görseller çoğu sitede toplam ağırlığın en büyük kalemidir. Bu yüzden görsel bütçesini sayfa başına değil, ilk ekran ve sayfanın geri kalanı olarak ikiye ayırmanızı öneririz. İlk ekrandaki görseller LCP'yi doğrudan etkiler; aşağıdaki görseller ise tembel yüklemeyle sonradan gelebilir.

Örnek hesap: bir hizmet sayfasında ilk ekran için tek bir kahraman görseli ve küçük bir logo var. Ekip kahraman görseline belirli bir KB tavanı, logoya ise çok daha küçük bir tavan verir. Sayfanın alt kısmındaki referans görsellerini ise ayrı bir toplam sınırla takip eder. Böylece tasarımcı yeni bir görsel eklemek istediğinde hangi paydan harcadığını bilir.

Fontlar da sessiz bir maliyet üretir. Her yeni ağırlık (ince, kalın, italik) ayrı bir dosya demektir. web.dev'in miktar temelli örnekleri arasında web fontu sayısı da yer alır. Pratikte bir ya da iki font ailesi ve sınırlı sayıda ağırlıkla çalışmak hem bütçeyi hem de tasarım tutarlılığını korur. Ayrıca fontun yüklenmesini beklerken metnin görünmez kalmaması için yükleme davranışını bilinçli seçin; aksi hâlde LCP ve CLS birlikte bozulabilir.

Kısacası görsel ve font kararlarını tasarım aşamasında bütçeyle birlikte verin. Sonradan küçültmeye çalışmak, baştan sınırla tasarlamaktan her zaman daha pahalıdır.

Mobil kullanıcılar için bütçe neden daha sıkı olmalı?

Mobil cihazlar hem işlemci hem de ağ açısından masaüstüne göre daha kısıtlı koşullarda çalışır. Aynı JavaScript dosyası güçlü bir bilgisayarda kısa sürede çalışırken orta seviye bir telefonda ana iş parçacığını çok daha uzun süre meşgul edebilir. Dolayısıyla mobil için ayrı ve daha sıkı bir bütçe mantıklıdır.

web.dev'in ilk bütçe rehberi de bu farkı örnekler: yavaş mobil ağda kritik kaynaklar için daha küçük bir sınır, masaüstü ve Wi-Fi koşulunda ise daha geniş bir sınır önerir. Ayrıca Core Web Vitals eşiklerini mobil ve masaüstü için ayrı ayrı değerlendirirsiniz; yani masaüstündeki iyi sonuç mobil sorunu gizleyemez.

Peki kullanıcılarınızın hangi cihazlarla geldiğini nereden bileceksiniz? web.dev, kitlenizin cihaz dağılımını görmek için Chrome Kullanıcı Deneyimi Raporu'nu kullanmayı önerir. Analiz aracınızdaki cihaz kırılımı da iyi bir ipucudur. Ziyaretlerin çoğu mobilden geliyorsa, testlerinizi de mobil profil ve yavaş ağ ayarıyla yapın.

Aylık performans bütçesi raporunda neler olmalı?

İzleme ancak düzenli bir raporla anlam kazanır. Biz müşterilerimize kısa ve tekrar edilebilir bir rapor formatı öneriyoruz; amaç, herkesin iki dakikada durumu anlamasıdır.

• Sayfa türü bazında bütçe ve gerçekleşen değer: ağırlık, JavaScript, istek sayısı.
• Laboratuvar sonuçları: Lighthouse performans puanı ve TBT.
• Saha sonuçları: Search Console Core Web Vitals raporundaki Good, Need improvement ve Poor dağılımı.
• Önceki aya göre değişim ve bu değişime yol açan yayınlar.
• Açık aşımlar, sorumlu kişi ve hedef tarih.

Bu raporu teknik olmayan paydaşlarla da paylaşın. Böylece pazarlama ya da yönetim ekibi yeni bir istek getirdiğinde bütçenin bugünkü durumunu bilir ve kararı birlikte verirsiniz. Üstelik rapor geçmişi, hangi değişikliğin hızı ne kadar etkilediğini gösteren değerli bir arşive dönüşür.

Bütçe aşıldığında hangi sırayla hareket etmelisiniz?

Aşım bir felaket değil, bir sinyaldir. Önemli olan, panik içinde rastgele eklenti kurmak yerine sakin bir sıra izlemektir.

1. Hangi kalemin aştığını belirleyin: görsel mi, JavaScript mi, üçüncü taraf mı, sunucu süresi mi?
2. Aşımın ne zaman başladığını bulun; son yayınlar ve eklenen etiketler genellikle ipucu verir.
3. Kolay kazanımlara bakın: sıkıştırma görmemiş görseller, kullanılmayan kodlar, gereksiz fontlar.
4. Kazanım yetmiyorsa özelliğin değerini tartın; gerekirse kaldırın ya da sonradan yükleyin.
5. Düzeltmeyi laboratuvarda doğrulayın, ardından saha verisinin oturmasını bekleyin.

Bu sırayı izlerseniz aynı sorunla birkaç ay sonra tekrar karşılaşma ihtimaliniz azalır; çünkü kök nedeni kayda geçirmiş olursunuz.

Performans bütçesinde sık yapılan hatalar nelerdir?

Bütçe kuran ekiplerin önemli bir kısmı aynı tuzaklara düşer. Bunları baştan bilmek zaman kazandırır.

• Yalnız Lighthouse puanına bakmak; puan yükselirken gerçek kullanıcı deneyimi gerileyebilir.
• Tüm site için tek bir sınır koymak; sayfa türü farklarını görmezden gelmek.
• Hedefi ilk günden ulaşılamayacak kadar sıkı koymak; ekip kısa sürede bütçeyi ciddiye almayı bırakır.
• Ölçümü yalnız masaüstünde yapmak; mobil kullanıcıların deneyimini kaçırmak.
• Yayından sonra izlemeyi bırakmak; web.dev de lansmandan sonra ölçüme devam etmeyi önerir.

Kısacası bütçe yaşayan bir belgedir. Ölçmeden yazılan ya da yazıldıktan sonra hiç açılmayan bir bütçe, hiç olmamasından farksızdır.

Performans bütçesi için kimden destek almalısınız?

Küçük bir site için temel bütçeyi kendi ekibiniz de kurabilir: birkaç sayfa seçer, ölçer ve basit sınırlar koyarsınız. Ancak birden çok ekibin dokunduğu, sık güncellenen ya da e-ticaret gibi karmaşık sitelerde bütçeyi süreçlere oturtmak daha fazla deneyim ister.

Bu noktada dışarıdan destek almak mantıklı olabilir. SEO danışmanlığı sayfamızdan teklif isteyebilirsiniz; sitenizin bugünkü değerlerini ölçer, sayfa türlerine göre bütçe önerir ve aylık izleme raporuyla aşımları birlikte takip ederiz. Sıralama garantisi vermeyiz; hızın içeriğinizi kullanıcıya engelsiz ulaştırmasını hedefleriz.

Hangi yolu seçerseniz seçin, ilk adım aynıdır: bugünkü değerlerinizi ölçün, en önemli üç sayfanızı seçin ve her biri için yazılı bir sınır koyun. Bütçe küçük başlasa bile düzenli takip ettiğinizde sitenizin hızını yıllarca korumanıza yardım eder.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.