Performansın sadece iyi niyetlerle değil, bütçelerle korunması\n\nPerformans bütçesi, inşa etmeden önce üzerinde anlaştığınız sınırların toplamıdır. Bu bir zaman sınırı (sayfanın ne kadar hızlı hissettirdiği), bir boyut sınırı (ne kadar kod gönderdiğiniz) veya istek sayısı, görseller veya üçüncü taraf scriptleri için bir üst limit olabilir. Limit aşıldığında, bunun "sonra düzeltilecek" bir mesele değil, bozulmuş bir gereksinim olarak ele alınması gerekir.\n\nHız genellikle kötüye gider çünkü yayınlama toplamsaldır. Her yeni widget JavaScript, CSS, fontlar, görseller, API çağrıları ve tarayıcı için daha fazla iş ekler. Küçük değişiklikler bile üst üste birikerek uygulamanın ağır hissetmesine neden olur; özellikle çoğu gerçek kullanıcının kullandığı orta sınıf telefonlar ve daha yavaş ağlarda.\n\nGörüşler burada sizi korumaz. Birisi "laptopumda iyi görünüyor" der, başkası "yavaş" der ve ekip tartışır. Bir bütçe tartışmayı sona erdirir: performansı ölçülebilir ve uygulaması yapılabilir bir ürün kısıtı haline getirir.\n\nBunu Addy Osmani'nin yaklaşımıyla benzetebilirsiniz: performansı tasarım kısıtları ve güvenlik kuralları gibi ele alın. Güvende kalmayı "denemez"siniz ya da düzenin iyi görünmesini "ummazsınız". Standartlar belirlersiniz, sürekli kontrol edersiniz ve bunları bozan değişiklikleri engellersiniz.\n\nBütçeler aynı anda birkaç pratik problemi çözer. Takasları açık hale getirirler (bir özellik eklemek başka bir yerde bedel ödemek demektir), regresyonları erken yakalarlar (düzeltmeler daha ucuzken), ve herkes için "yeterince hızlı"nın aynı tanımını verirler. Ayrıca lansman öncesi ortaya çıkan son dakikadaki panikleri azaltırlar.\n\nBütçelerin hedeflendiği tipik bir senaryo: tek bir pano görünümü için zengin bir grafik kütüphanesi eklersiniz. Bu herkesin paketine gider, ana bundle büyür ve ilk anlamlı ekran daha geç açılır. Bütçe yoksa, özellik "çalıştığı" için onaylanır. Bütçe varken ekip seçim yapmak zorunda kalır: grafiği lazy-load etmek, kütüphaneyi değiştirmek veya görünümü basitleştirmek gibi.\n\nBu, Koder.ai gibi sohbet tabanlı hızlı oluşturma iş akışlarıyla uygulamalar hızla üretilebildiğinde daha da önem kazanır. Hız harika ama aynı zamanda ekstra bağımlılıklar ve UI süslemelerini fark etmeden göndermeyi kolaylaştırır. Bütçeler hızlı iterasyonun yavaş ürünlere dönüşmesini engeller.\n\n## Basit bir hedefle başlayın: sayfa, cihaz ve ağ\n\nPerformans çalışmaları her şeyi ölçüp kimsenin sorumluluk almamasıyla başarısız olur. Gerçek kullanıcılar için önemli olan tek bir sayfa akışı seçin ve onu bütçelerinizin dayanağı olarak kabul edin.\n\nİyi bir başlangıç noktası, dönüşümü veya günlük işi etkileyen birincil yolculuktur: "ana sayfadan kayıt", "girişten sonra pano ilk yüklemesi" veya "ödeme onayı" gibi. Temsili ve sık olan bir şey seçin, uç durumları değil.\n\n### Kullanıcılarınıza uygun bir hedef seçin\n\nUygulamanız kendi laptopunuzda çalışmıyor. Hızlı bir cihazda iyi görünen bir bütçe, orta sınıf bir telefonda yavaş hissedilebilir.\n\nBaşlangıç için bir cihaz sınıfı ve bir ağ profili belirleyin. Basit tutun ve herkesin tekrar edebileceği bir cümleyle yazın.\n\nÖrnek olarak: son 2–3 yılın orta sınıf bir Android telefonu, hareket halindeyken 4G (ofis Wi‑Fi değil), soğuk yükleme ölçümü ve ardından bir ana navigasyon, aynı bölgedeki çoğu kullanıcının bulunduğu yerde.\n\nBu en kötü durumu seçmek değil; gerçekten optimize edebileceğiniz ortak bir durumu seçmekle ilgilidir.\n\n### Bir temel test kurulumunu kilitleyin\n\nSayılar ancak karşılaştırılabiliyorsa önemlidir. Bir koşu "Chrome uzantılarıyla MacBook" ve başka bir koşu "throttled mobile" ise trend hattınız gürültüdür.\n\nBütçe kontrolleri için bir temel ortam seçin ve ona sadık kalın: aynı tarayıcı sürümü, aynı throttling ayarları, aynı test yolu ve aynı cache durumu (soğuk veya sıcak). Gerçek cihaz kullanıyorsanız aynı cihaz modelini kullanın.\n\nŞimdi "yeterince hızlı"nın ne anlama geldiğini davranış bazlı tanımlayın, mükemmel demolar değil. Örneğin: "kullanıcılar içeriği hızlıca okumaya başlayabiliyor" veya "girişten sonra pano duyarlı hissediyor". Bunu bu yolculuk için bir veya iki metriğe çevirin ve etrafında bütçeler belirleyin.\n\n## Bütçe türleri: zaman, boyut, istek ve çalışma zamanı\n\nBütçeler hem kullanıcıların hissettiği hem de ekiplerin kontrol edebildiği şeyleri kapsadığında en iyi sonuç verir. İyi bir set, deneyim metriklerini ("hızlı mı hissettiriyor?") kaynak ve CPU limitleriyle ("neden yavaşladı?") harmanlar.\n\n### Zaman bütçeleri (kullanıcı deneyimi)\n\nBunlar sayfanın gerçek kullanıcılar için nasıl davrandığını izler. En kullanışlı olanlar doğrudan Core Web Vitals ile eşleşir:\n\n- LCP (Largest Contentful Paint): ana içeriğin ne kadar çabuk göründüğü.\n- INP (Interaction to Next Paint): biri dokunduğunda, tıkladığında veya yazdığında sayfanın ne kadar tepki verdiği.\n- CLS (Cumulative Layout Shift): düzenin ne kadar kaydığı.\n\nZaman bütçeleri kullanıcı hayal kırıklığıyla birebir örtüştüğü için kuzey yıldızınızdır. Ancak neyi düzeltmeniz gerektiğini her zaman söylemezler; bu yüzden aşağıdaki bütçe türlerine de ihtiyacınız var.\n\n### Boyut, istek ve çalışma zamanı bütçeleri (yavaşlığa neden olanlar)\n\nBunlar build aşamasında ve kod incelemelerinde uygulaması daha kolaydır çünkü somuttur.\n\nAğırlık bütçeleri toplam JavaScript, toplam CSS, görsel ağırlığı ve font ağırlığı gibi şeyleri sınırlar. İstek bütçeleri toplam istek sayısını ve üçüncü taraf scriptleri sınırlar; bu da ağ yükünü ve etiketlerden, widgetlardan ve takiplerden kaynaklanan "sürpriz" işleri azaltır. Çalışma zamanı bütçeleri uzun görevleri, ana iş parçacığı zamanını ve (özellikle React için) hydration süresini sınırlar; bu genelde bir sayfanın orta sınıf telefonlarda neden "ağır" hissettiğini açıklar.\n\nPratik bir React örneği: bundle boyutu iyi görünse bile yeni bir carousel ağır istemci tarafı renderı ekleyebilir. Sayfa yüklenir, fakat filtrelere dokunmak yapışkan hissettirir çünkü hydration ana iş parçacığını bloke eder. "Başlangıçta X ms'den uzun görev olmasın" veya "hydration orta sınıf bir cihazda Y saniye içinde tamamlansın" gibi bir çalışma zamanı bütçesi, ağırlık bütçeleriyle yakalanamayan bunu tespit edebilir.\n\nEn güçlü yaklaşım bunları bir sistem olarak ele almaktır: deneyim bütçeleri başarıyı tanımlar; boyut, istek ve çalışma zamanı bütçeleri sürümleri dürüst tutar ve "ne değişti?" sorusunu cevaplamayı kolaylaştırır.\n\n## Uygulanabilir başlangıç bütçeleri\n\nÇok fazla limit belirlerseniz, insanlar ilgilenmeyi bırakır. Kullanıcıların en çok hissettiği ve her pull request veya sürümde ölçebileceğiniz 3–5 bütçe seçin.\n\nPratik bir başlangıç seti (sayıları sonra ayarlayın):\n\n- LCP: uyarı 2.5s, başarısızlık 3.0s (mobil, soğuk yükleme).\n- INP: uyarı 200ms, başarısızlık 300ms (menü açma veya form gönderme gibi yaygın etkileşimler).\n- CLS: uyarı 0.10, başarısızlık 0.15.\n- JavaScript bundle boyutu (ilk rota): uyarı 170KB gzip, başarısızlık 220KB gzip (sadece uygulama kodu).\n- Görseller (ilk görünüm): uyarı 800KB, başarısızlık 1.2MB (ilk ekranda transfer edilen görsel toplam bayt).\n\nİki eşik işi makul kılar. "Uyarı" sapıyorsunuz demektir. "Başarısızlık" release'i engeller veya açık bir onay gerektirir. Bu, sınırı gerçek kılar ama sürekli yangın söndürmeyi önler.\n\nBütçeyi herkesin tartışmayacağı tek bir yerde yazın: hangi sayfalar/akışlar kapsanıyor, ölçümler nerede çalıştırılıyor (yerel denetim, CI, sahnelenmiş build), hangi cihaz ve ağ profili kullanılıyor ve metriklerin kesin tanımı (field vs lab, gzip vs raw, rota düzeyi vs tüm uygulama).\n\n## Mevcut uygulamanızdan adım adım bütçe belirleme\n\nTekrarlanabilir bir temel ile başlayın. Bir veya iki ana sayfa seçin ve her seferinde aynı cihaz profili ve ağda test edin. Testi en az üç kez çalıştırın ve medyanı kaydedin ki tek bir garip koşu yön belirlemesin.\n\nBasit bir temel tablo kullanın; hem kullanıcı metriği hem build metriği içersin. Örneğin: sayfa için LCP ve INP, ayrıca build için toplam JavaScript boyutu ve toplam görsel bayt. Bu, bütçelerin gerçek hissettirmesini sağlar çünkü sadece laboratuvar tahmini değil, gönderilen şeyi görürsünüz.\n\nBütçeleri bugünkü durumunuzdan biraz daha iyi olacak şekilde ayarlayın, hayali rakamlar koymayın. Sağlam bir kural, ilgilendiğiniz her metrikte mevcut medianınıza göre %5–10 iyileştirmedir. Eğer LCP temel kurulumda 3.2s ise doğrudan 2.0s'ye geçmeyin. Önce 3.0s ile başlayın, sonra tutabildiğinizi kanıtladıktan sonra sıkılaştırın.\n\nHer sürümden önce hızlı bir kontrol ekleyin. İnsanların atlamayacağı kadar hızlı olsun. Basit bir versiyon: kararlaştırılan sayfada tek bir sayfa denetimi çalıştırın, JavaScript veya görseller bütçeyi aşarsa build'i başarısız sayın, sonuçları commit başına saklayın ki ne zaman değiştiğini görün, ve her zaman aynı URL desenini test edin (rastgele veri yok).\n\nİhlalleri yalnızca birisi şikayet ettiğinde değil, haftalık olarak gözden geçirin. İhlali bir hata gibi ele alın: hangi değişiklikin sebep olduğunu belirleyin, şimdi ne düzeltileceğine ve neyin planlanacağına karar verin. Yavaşça sıkılaştırın; ancak birkaç sürüm boyunca hattı koruyabildiğinizde sınırları daraltın.\n\nÜrün kapsamı değiştiğinde bütçeleri bilinçli şekilde güncelleyin. Yeni bir analiz aracı veya ağır bir özellik eklerseniz, neyin büyüdüğünü (boyut, istekler, çalışma zamanı), bunu daha sonra nasıl telafi edeceğinizi ve bütçenin ne zaman geri geleceğini yazın.\n\n## Hızlı denetimler: ne değiştiğini görmek için hızlı bir yol\n\nBütçe ancak hızlıca kontrol edilebiliyorsa işe yarar. 10 dakikalık bir denetimin amacı mükemmel bir sayı kanıtlamak değil. Amaç, son iyi build'den bu yana ne değiştiğini görmek ve önce neyi düzeltmeniz gerektiğine karar vermektir.\n\n### 10 dakikalık denetim akışı\n\nGerçek kullanımı temsil eden bir sayfayla başlayın. Sonra her seferinde aynı hızlı kontrolleri çalıştırın:\n\n- LCP öğesini belirleyin (hero görseli, başlık bloğu, ürün galerisi). LCP öğesi değiştiyse sonuçlar atlar.\n- JavaScript ağırlığını ve en büyük parçaları kontrol edin. Yeni bir bağımlılık, kopyalanmış kütüphane veya herkese gönderilen büyük bir özellik arayın.\n\n- Üstteki görünümdeki görsellerdeki yaygın hataları tarayın (sıkıştırılmamış varlıklar, yanlış boyutlar, eksik responsive kaynaklar).\n- Üçüncü taraf etiketleri (analitik, sohbet, A/B testleri) gözden geçirin. Yeni bir etiket uzun görevler ekleyip ana iş parçacığını bloke edebilir.\n\n- Ağ ve CPU'yu birlikte inceleyin: yavaşlık byte artışından mı yoksa sayfanın çok fazla iş yapmasından mı kaynaklanıyor?\n\n### En büyük sorunları hızlıca nasıl bulursunuz\n\nİki görünüm genelde dakika içinde cevap verir: network waterfall ve main-thread zaman çizelgesi.\n\nWaterfall'da kritik yolu domine eden tek bir isteği arayın: devasa bir script, engelleyici bir font veya geç başlayan bir görsel. Eğer LCP kaynağı erken istek edilmemişse, sunucu ne kadar hızlı olursa olsun LCP bütçesine ulaşamazsınız.\n\nZaman çizelgesinde uzun görevleri (50 ms veya üzeri) arayın. Başlangıç etrafındaki uzun görev kümesi genellikle ilk yüklemede çok fazla JavaScript olduğunu gösterir. Tek bir devasa parça genelde rota sorunu veya zaman içinde büyüyen paylaşılan bundle anlamına gelir.\n\n### Bir sonraki testi karşılaştırılabilir kılan notlar\n\nHızlı denetimler her koşu farklıysa başarısız olur. Değişiklikler net olsun diye birkaç temel bilgiyi kaydedin: sayfa URL'si ve build/sürüm, test cihazı ve ağ profili, LCP öğesi tanımı, izlediğiniz ana sayılar (örneğin LCP, toplam JS bayt, istek sayısı) ve en büyük suçlu hakkında kısa not.\n\nHızlı geri bildirim ve PR kontrolleri için masaüstü testleri uygundur. Bütçeye yaklaştığınızda, sayfa takılmaya başladığında veya kullanıcılarınız mobil ağırlıklıysa gerçek cihaz kullanın. Mobil CPU'lar uzun görevleri belirgin kılar; birçok "laptopumda iyi görünüyor" sürümü burada çöker.\n\n## Öncelikle neyi düzeltmeli: zamandan kazandıran basit kurallar\n\nBütçe başarısız olduğunda en kötü hareket "her şeyi optimize et" olmaktır. Her düzeltinin net getirisi olduğu tekrarlanabilir bir öncelik sırası kullanın.\n\n### Pratik öncelik sırası\n\nKullanıcıların en çok fark ettiği şeyle başlayın, sonra daha ince ayara doğru ilerleyin:\n\n- Üstteki ana içerik öğesini hızlı yapın. En büyük içeriğin ne olduğuna bakın ve o kaynağı veya render yolunu ilk önce düzeltin. Görselleri yeniden boyutlandırın ve sıkıştırın, doğru formatı kullanın ve ilk görünümü engelleyen fontlardan kaçının.\n- CSS'i cilalamadan önce JavaScript'i kesin. Sayfa çok fazla JS gönderiyorsa diğer her şey bundan zarar görür: parsing yavaşlar, ana iş parçacığı daha uzun çalışır, render gecikir. Kullanılmayan kodu kaldırın, ağır rotaları bölün ve basit UI için sunucu taraflı veya statik içeriği tercih edin.\n- Üçüncü taraf scriptleri erken kontrol altına alın. Sohbet widgetları, analitik, etiket yöneticileri ve A/B araçları büyük indirmeler ve uzun görevler ekleyebilir. İlk görünümde gerekli değilse erteleyin; düşük değerliyse kaldırın.\n- Yerleşim kaymalarını tasarımla durdurun. Görseller, reklamlar ve embedler için alan ayırın. width/height ayarlayın, stabil placeholderlar kullanın ve yüklemeden sonra mevcut içeriğin üstüne UI eklemekten kaçının.\n- Etkileşim gecikiyorsa uzun görevleri ortadan kaldırın. INP kötü olduğunda ağır istemci işi arayın: büyük renderlar, pahalı state güncellemeleri ve büyük JSON işlemeleri. İşleri daha küçük parçalara bölün, yeniden renderları azaltın ve UI dışındaki işleri kritik yolun dışına taşıyın.\n\n### Hızlı bir örnek\n\nBir ekip yeni bir pano yayınlar ve aniden LCP bütçesini kaçırır. Önce cache başlıklarını düzeltmeye çalışmak yerine LCP öğesinin tam genişlikli bir grafik resmi olduğunu fark ederler. Resmi yeniden boyutlandırır, daha hafif bir format sunar ve yalnızca erken gerekenleri yüklerler. Sonra her rotada yüklenen büyük bir grafik kütüphanesinin olduğunu görürler. Sadece analiz sayfasında yüklerler ve üçüncü taraf destek widgetını ilk etkileşimden sonra erteleyip lazy-load yaparlar. Bir gün içinde pano bütçe içinde geri gelir ve bir sonraki sürümde "ne değişti" sorusunun net yanıtları vardır.\n\n## Performans bütçeleriyle ilgili ekiplerin sık yaptığı hatalar\n\nEn büyük başarısızlık modu bütçeleri tek seferlik bir belge gibi görmek. Bütçeler yalnızca kolayca kontrol edilebilir, görmezden gelinmesi zor ve gönderme sürecine bağlı olduğunda işe yarar.\n\n### Bütçeleri başarısız kılan hatalar\n\nÇoğu ekip birkaç tuzağa takılır:\n\n- İlk günden çok fazla bütçe belirlemek veya o kadar sıkı koymak ki her build başarısız olsun.\n- Her seferinde farklı ayarlarla ölçüm yapmak (cihaz, throttling, cache durumu, test sayfası).\n- Laboratuvar skorlarını kovalamak ama gerçek kullanıcı acısını kaçırmak.\n- Bir büyük bağımlılığın sessizce eklenmesine izin vermek.\n- Performansı bitirilecek bir proje gibi, değil de bir sürüm kuralı olarak ele almamak.\n\nYaygın bir desen, "küçük" bir özelliğin yeni bir kütüphane çekmesi. Bundle büyür, LCP daha yavaşlar ve destek biletleri gelene kadar kimse fark etmez. Bütçeler, bu değişikliği gözden geçirme zamanında görünür kılmak içindir.\n\n### Nasıl kaçınılır\n\nBasit başlayın ve kontrolleri tutarlı kılın. Kullanıcı deneyimine bağlanan 2–4 bütçe seçin ve yavaşça sıkılaştırın. Test kurulumunuzu kilitleyin ve yazın. Mümkünse en az bir gerçek kullanıcı sinyali izleyin, ve laboratuvar testlerini "nedenini" açıklamak için kullanın, tartışmaları kazanmak için değil. Bir bağımlılık anlamlı şekilde ağırlık ekliyorsa kısa bir not isteyin: maliyeti nedir, neyi değiştiriyor ve neden buna değer. En önemlisi, bütçe kontrolünü normal sürüm yoluna yerleştirin.\n\nBütçeler sürekli sürtüşme yaratıyorsa genellikle iki sebepten biridir: ya bugünkü duruma göre gerçekçi değillerdir, ya da gerçek kararlara bağlanmamışlardır. Önce bu iki şeyi düzeltin.\n\n## Örnek: yavaşlayan bir web uygulamasını bütçeli bir sürüm sürecine dönüştürmek\n\nKüçük bir ekip React ile bir analiz panosu bir haftada yayınladı. İlk başta hızlı hissediyordu, ama her Cuma sürümüyle biraz daha ağırlaştı. Bir ay sonra kullanıcılar ilk ekranın "takıldığını" ve filtrelerin gecikmeli olduğunu bildirmeye başladı.\n\n"Yeterince hızlı" hakkında tartışmayı bırakıp kullanıcıların algısına bağlı bütçeleri yazdılar:\n\n- LCP: orta sınıf telefonda 4G'de 2.5s\n- INP: yaygın eylemler için 200ms altında (menü açma, filtre uygulama)\n- JavaScript: ilk rota için 250KB gzip, her yeni özellik için net bir üst limit\n- Görseller: sıkıştırılmamış hero görsel olmasın ve bileşen başına maksimum piksel boyutu olsun\n\nİlk başarısızlık iki yerde ortaya çıktı. İlk JS bundle, grafikler, tarih kütüphaneleri ve bir UI kitinin eklenmesiyle büyümüştü. Aynı zamanda pano başlık resmi daha büyük bir dosyayla değiştirilmişti ve LCP limiti aşılıyordu. INP kötüleşmişti çünkü her filtre değişikliği ana iş parçacığında pahalı yeniden render ve hesaplamalar tetikliyoruydu.\n\nOnlar bunu hızlı kazanımlar sağlayacak ve tekrar eden regresyonları engelleyecek bir sırayla düzelttiler:\n\n1) LCP'yi yeniden limitin altına getirmek: görselleri yeniden boyutlandırma ve sıkıştırma, açık görsel boyutları ayarlama ve engelleyici font yüklemelerinden kaçınma.\n\n2) İlk JS'yi düşürme: kullanılmayan kütüphaneleri kaldırma, kritik olmayan rotaları bölme ve grafikleri lazy-load yapma.\n\n3) INP'yi iyileştirme: pahalı bileşenleri memoize etme, yazma filtrelerini debounce etme ve ağır işleri sıcak yoldan çıkarma.\n\n4) Her sürüme bir bütçe kontrolü ekleme ki bir metrik bozulursa sürüm beklesin.\n\nİki sürüm sonra LCP aynı test cihazında 3.4s'den 2.3s'ye düştü ve INP yaklaşık 350ms'den 180ms'in altına indi.\n\n## Kontrol listesi ve sonraki adımlar (hafif bir Koder.ai iş akışı dahil)\n\nBütçe, insanlar her seferinde aynı şekilde takip ederse yardımcı olur. Küçük tutun, yazın ve gönderme sürecinin bir parçası yapın.\n\nUygulamanıza uyan birkaç metriği seçin, "uyarı vs başarısızlık" eşiklerini belirleyin ve nasıl test edeceğinizi (cihaz, tarayıcı, ağ, sayfa/akış) tam olarak belgeleyin. Mevcut en iyi sürümden bir temel rapor kaydedin ve net bir etiket verin. Hangi istisnanın geçerli sayılacağını ve sayılmayacağını kararlaştırın.\n\nHer sürümden önce aynı denetimi çalıştırın ve bunu temel ile karşılaştırın. Bir şey gerileme gösteriyorsa, hataları takip ettiğiniz yere kaydedin ve bunu kırılmış bir ödeme adımı gibi ele alın, "sonra" işi değil. Bir istisna ile gönderirseniz, bir sahibi ve son kullanma tarihi kaydedin (genelde 1–2 sprint). İstisna sürekli uzatılıyorsa bütçe konusunda gerçek bir tartışma gereklidir.\n\nBütçeleri planlamaya ve tahminlere daha erken taşıyın: "Bu ekran bir grafik kütüphanesi ekliyor, bu yüzden bir şeyi kaldırmamız veya lazy-load yapmamız gerekiyor." Eğer Koder.ai ile (Koder.ai) inşa ediyorsanız, bu kısıtları Planlama Modu'nda baştan yazabilir, sonra daha küçük dilimlerde iterasyon yapabilir ve bir değişiklik sizi üst limite ittiğinde snapshota ve rollback'e başvurabilirsiniz. Araç önemli değil; alışkanlık önemlidir: her yeni özellik ağırlığı için ödeme yapmalı yoksa gönderilmemelidir.
