Tarayıcı temelleri: ağ, render ve önbellekleme efsanelerinden arınmış

Tarayıcı efsaneleri gerçek hatalara neden olmaya devam ediyor

Çok sayıda ön yüz hatası “gizemli tarayıcı davranışı” değildir. Bunlar, “tarayıcı her şeyi önbellekler” veya “React varsayılan olarak hızlıdır” gibi yarım hatırlanmış kuralların sonucudur. Bu fikirler kulağa mantıklı gelir, bu yüzden insanlar sloganla yetinir; hızlı derken neye göre ve hangi koşullar altında diye sormazlar.

Web, ödünleşmeler üzerine kurulu. Tarayıcı ağ gecikmesi, CPU, bellek, ana iş parçacığı, GPU işi ve depolama sınırlarını aynı anda idare eder. Zihinsel modeliniz bulanıksa, dizüstü bilgisayarınızda iyi hisseden bir kullanıcı arayüzünü gönderirsiniz ama orta segment bir telefonda, dalgalı Wi‑Fi üzerinde çöker.

Gerçek hataya dönüşen birkaç yaygın varsayım:

• “İlk yüklemeden sonra hızlı olmalı.” Sonra hiçbir şeyin önbelleğe alınmadığını fark edersiniz çünkü başlıklar eksik veya her build URL’leri değiştiriyor.
• “Tarayıcı her şeyi paralel indirir.” Sonra bir büyük script ana iş parçacığını bloke eder ve tıklamalar donuk hissedilir.
• “Görseller ucuzdur.” Sonra sıkıştırılmamış kahraman görselleri renderı geciktirir, düzeni kaydırır ve Core Web Vitals'ı düşürür.
• “Sadece benim kodum önemli.” Sonra üçüncü taraf widget'lar, fontlar ve uzun görevler zaman çizelgesini domine eder.

AI ile oluşturulmuş ön yüzler bu hataları büyütebilir. Bir model doğru görünen bir React sayfası üretebilir ama gecikmeyi hissetmez, bant genişliği faturasını ödemez ve her render'ın ekstra iş tetiklediğini fark etmez. Gerekirse diye büyük bağımlılıklar ekleyebilir, HTML içine devasa JSON koyabilir veya aynı veriyi iki kez çekebilir çünkü ikisi de makul görünen iki deseni birleştirmiştir.

Koder.ai gibi bir vibe-coding aracı kullanıyorsanız, bu daha da önem kazanır: çok sayıda UI hızla üretebilirsiniz, bu harika ama gizli tarayıcı maliyetleri kimse fark etmeden birikebilir.

Bu yazı günlük işte karşınıza çıkan temel konulara bağlı kalıyor: ağ, önbellekleme ve render hattı. Amaç, tarayıcının ne yapacağını tahmin etmenizi sağlayacak bir zihinsel model verip “hızlı olmalı” tuzaklarından kaçınmaktır.

Açık bir zihinsel model: URL'den piksele

Tarayıcıyı bir URL'i piksellere çeviren bir fabrika gibi düşünün. Hattaki istasyonları bilirseniz, zaman nerede kaybediliyor tahmin etmek kolaylaşır.

Çoğu sayfa şu akışı takip eder:

• Navigasyon başlar: bir URL girersiniz veya bir linke tıklarsınız ve tarayıcı isteğin nereye gideceğine karar verir.
• Baytlar gelir: önce HTML, sonra CSS, JS, görseller ve fontlar.
• Ayrıştırma gerçekleşir: HTML DOM olur, CSS tarayıcının uygulayabileceği kurallara dönüşür.
• Render işi başlar: layout (boyutlar ve pozisyonlar), paint (çizim), sonra compositing (katmanlama).
• Etkileşim JavaScript çalıştıkça ve event handler'lar bağlandıkça gelir.

Sunucu HTML, API cevapları ve varlıkları döner, ayrıca önbellekleme ve güvenlik kontrolü yapan başlıklar gönderir. Tarayıcının işi isteğin öncesinde (önbellek arama, DNS, bağlantı kurulumu) başlar ve yanıtın ardından da devam eder (ayrıştırma, render, script yürütme ve sonraki sefer için depolama).

Çokça karışıklık tarayıcının tek bir şeyi aynı anda yaptığı varsayımından gelir. Yapmaz. Bazı işler ana iş parçacığının dışında olur (ağ çağrıları, görsel decode etme, bazı compositing işleri), ana iş parçacığı ise “bunu engelleme” şerididir. Kullanıcı girdisini o işler işler, çoğu JavaScript orada çalışır ve layout ile paint'i koordine eder. Meşgul olduğunda tıklamalar görmezden gelinmiş hissedilir ve kaydırma takılır.

Çoğu gecikme aynı birkaç yerde saklıdır: ağ beklemeleri, önbellek hataları, CPU‑yoğun işler (JavaScript, layout, çok büyük DOM) veya GPU‑yoğun işler (çok fazla büyük katman ve efekt). Bu zihinsel model, AI aracı bir şey “güzel görünüyor” ama yavaş hissettiriyorsa nerede ekstra iş yarattığını tahmin etmeye de yardımcı olur.

Kullanıcı arayüzünüzü gerçekten etkileyen ağ temelleri

Sayfa, “gerçek içerik” indirilmeye başlamadan önce bile yavaş hissedebilir; çünkü tarayıcının önce sunucuya ulaşması gerekir.

Bir URL yazdığınızda tarayıcı genellikle DNS yapar (sunucuyu bulur), bir TCP bağlantısı açar, sonra TLS müzakeresi yapar (şifreleme ve doğrulama). Her adım bekleme süresi ekler, özellikle mobil ağlarda. Bu yüzden “bundle sadece 200 KB” olsa bile yavaş hissedebilir.

Bundan sonra tarayıcı bir HTTP isteği gönderir ve bir yanıt alır: durum kodu, başlıklar ve bir gövde. Başlıklar UI için önemlidir çünkü önbellekleme, sıkıştırma ve içerik tipini kontrol eder. İçerik tipi yanlışsa tarayıcı dosyayı beklenen şekilde ayrıştıramayabilir. Sıkıştırma etkin değilse “metin” varlıklar çok daha büyük indirmeler olur.

Yönlendirmeler (redirect) zaman israf etmenin başka kolay yoludur. Bir ekstra sıçrama başka bir istek ve yanıt anlamına gelir ve bazen başka bir bağlantı kurulumu daha gerekir. Ana sayfanız bir URL'ye yönlendiriyor, o da tekrar yönlendiriyorsa (http'den https'ye, sonra www'ye, sonra bir locale'e), kritik CSS ve JS'yi almadan önce birkaç bekleme eklemiş olursunuz.

Boyut sadece görseller değil. HTML, CSS, JS, JSON ve SVG genellikle sıkıştırılmalıdır. Ayrıca JavaScript'in neler çektiğine dikkat edin. “Küçük” bir JS dosyası bile hemen başka isteklerin patlamasına (chunk'lar, fontlar, üçüncü taraf script'ler) neden olabilir.

UI ile ilgili sorunların çoğunu yakalayan hızlı kontroller:

• İlk navigasyonda gereksiz yönlendirmeleri kaldırın.
• Metin varlıkları (CSS, JS, JSON, SVG) için sıkıştırmanın etkin olduğundan emin olun.
• Dosyaların doğru ayrıştırılması için içerik tiplerini doğrulayın.
• İstek patlamalarına dikkat: onlarca chunk, font, ikon ve takipçi.
• Önemli varlıkları mümkün olduğunca aynı origin'de tutun ki bağlantılar yeniden kullanılsın.

AI tarafından üretilmiş kod bu durumu kötüleştirebilir; çıktıyı birçok chunk'a bölebilir ve varsayılan olarak ekstra kütüphaneler çekebilir. Ağ “meşgul” görünür, her dosya küçük olsa bile başlangıç zamanı zarar görür.

Efsanelerden arınmış önbellekleme: ne yeniden kullanılır ve ne zaman

“Önbellek” tek bir sihirli kutu değildir. Tarayıcı verileri birden çok yerden yeniden kullanır ve her birinin farklı kuralları vardır. Bazı kaynaklar kısa süreli hafızada yaşar (hızlı ama yenilemede gider). Diğerleri diskte saklanır (yeniden başlatmalarda kalır). HTTP önbelleği bir yanıtın yeniden kullanılıp kullanılamayacağına karar verir.

Cache-Control sade diliyle

Çoğu önbellekleme davranışı yanıt başlıklarıyla kontrol edilir:

• max-age=...: süre dolana kadar yanıtı sunucuya danışmadan yeniden kullan.
• no-store: hafızada veya disk üzerinde tutma (hassas veriler için iyi).
• public: yalnızca kullanıcının tarayıcısı değil, paylaşılan önbellekler tarafından da saklanabilir.
• private: yalnızca kullanıcının tarayıcısında önbelleklensin.
• no-cache: kafa karıştırıcı isim. Genellikle “sakla ama yeniden kullanmadan önce doğrula” anlamına gelir.

Tarayıcı yeniden doğrulama yaptığında genellikle tam dosyayı indirmekten kaçınmaya çalışır. Sunucu bir ETag veya Last-Modified sağladıysa tarayıcı “değişti mi?” diye sorabilir ve sunucu “değişmedi” diye yanıtlayabilir. Bu round‑trip yine zaman maliyeti getirir ama genellikle tam indirmeden daha ucuzdur.

Yaygın bir hata (özellikle AI tarafından oluşturulmuş kurulumlarda) her build’te veya daha kötüsü her sayfa yüklemede app.js?cacheBust=1736 gibi rastgele sorgu dizeleri eklemektir. Güvenli hissettirir ama önbellekleme mekanizmasını bozar. Daha iyi bir desen, sabit URL'ler (sabit içerik için) ve versiyonlanmış varlıklar için içerik hash'li dosya isimleridir.

Geri tepen cache buster'lar birkaç öngörülebilir şekilde görünür: rastgele sorgu parametreleri, değişen JS/CSS için aynı dosya adını yeniden kullanma, deploy başına URL'leri değiştirme (içerik değişmediğinde bile) veya geliştirme sırasında önbellekleme devre dışı bırakıp buna geri dönmeyi unutma.

Service worker'lar çevrimdışı destek veya anında tekrar yüklemeler gerektiğinde yardımcı olabilir, ama yönetmeniz gereken başka bir önbellek katmanı eklerler. Uygulamanız “güncellenmiyor” ise sebeplerden biri genellikle eski bir service worker'dır. Service worker'ları sadece neyin önbellekleneceğini ve güncellemelerin nasıl yayılacağını net bir şekilde açıklayabileceğinizde kullanın.

Render hattı temelleri: parse, layout, paint, composite

“Mysterious” UI hatalarını azaltmak için tarayıcının baytları piksele nasıl çevirdiğini öğrenin.

HTML geldiğinde tarayıcı onu baştan sona ayrıştırır ve DOM'u (elemanlar ağacı) oluşturur. Ayrıştırma sırasında CSS, scriptler, görseller ve fontlar gibi sayıyı değiştirecek kaynakları keşfedebilir.

CSS özeldir çünkü tarayıcı gerçek stilleri bilmeden içeriği güvenli şekilde çizemeyebilir. Bu yüzden CSS renderı engelleyebilir: tarayıcı CSSOM'u (stil kuralları) oluşturur, sonra DOM + CSSOM'u render ağacında birleştirir. Kritik CSS gecikirse ilk boyama gecikir.

Stiller belirlendikten sonra ana adımlar şunlardır:

• Layout: boyutları ve pozisyonları hesapla.
• Paint: metin, kenarlıklar, gölgeler, görseller için pikselleri çiz.
• Composite: boyanan katmanları üst üste koy ve transform/opacity uygula.

Görseller ve fontlar genellikle kullanıcıların “yüklendi” olarak algıladığı şeyi belirler. Gecikmiş bir hero görsel Largest Contentful Paint'i geciktirir. Web fontları görünmez metne (FOIT) veya stil değişimine (FOUT) neden olabilir; bu da titreme gibi görünür. Scriptler, ayrıştırmayı bloke ederse veya ek stil yeniden hesaplamaları tetiklerse ilk boyamayı geciktirebilir.

Süregelen bir efsane “animasyon ücretsizdir.” Ne animasyon yaptığınıza bağlı. width, height, top veya left değiştirmek genellikle önce layout'u, sonra paint'i, sonra composite'i zorlar. transform veya opacity animasyonu çoğunlukla compositing'te kalır ve çok daha ucuzdur.

Gerçekçi bir AI hatası, birçok kartta background-position animasyonu yapan bir loading shimmer'ı ile bir timer'dan gelen sık DOM güncellemelerinin birleşimidir. Sonuç sürekli repaint olur. Çoğunlukla çözüm basittir: daha az eleman animasyonla hareket ettirin, hareket için transform/opacity tercih edin ve layout'u stabil tutun.

Hissedebileceğiniz JavaScript ve framework maliyetleri

Hızlı bir ağ olsa bile, sayfa JavaScript çalışırken boyayamıyor ve cevap veremiyorsa yavaş hissedilir. Bir bundle'ı indirmek sadece ilk adımdır. Daha büyük gecikme genellikle parse ve compile zamanı ile ana iş parçacığında çalıştırdığınız işten gelir.

Framework'ler kendi maliyetlerini ekler. React'te “render” UI'nın nasıl görünmesi gerektiğini hesaplamaktır. İlk yüklemede, client-side uygulamalar genellikle hydration yapar: event handler'ları bağlar ve zaten sayfada olanla uzlaşır. Hydration ağırsa, sayfa hazır görünür ama bir süre dokunmaları göz ardı edebilir.

Sorun genellikle uzun görevler olarak görülür: tarayıcının arada ekran güncelleyemeyecek kadar uzun (çoğunlukla 50ms veya daha fazla) JavaScript çalıştırması. Bunu gecikmiş girdi, düşen kareler ve takılma animasyonları olarak hissedersiniz.

Yaygın suçlular basittir:

• Başlangıçta çok fazla kod çalışması
• Ayrıştırılması ve dönüştürülmesi zaman alan büyük JSON yükleri
• Bir seferde çok fazla iş yapan bileşenler
• Mount sırasında tetiklenen ve ekstra render'lara yol açan çok sayıda effect
• Kararsız prop, state veya context yüzünden sık yeniden render'lar

Düzeltmeler ana iş parçacığı işine odaklanınca daha net olur, sadece byte'lara bakmayın:

• Route veya özellik bazında kodu bölün ki ilk görünümde daha az yük olsun.
• Kritik olmayan işleri ilk boyamadan veya etkileşimden sonrasına erteleyin.
• Hydration'ı hafif tutun ve ilk renderlarda ağır dönüşümlerden kaçının.
• Ölçmeden karmaşıklık eklemeyin: memoize edin ama dikkatli ve ölçümlü yapın.
• Mümkünse pahalı ayrıştırma/formatlama işlerini ana iş parçacığından çıkarın.

Sohbet güdümlü bir araçla (ör. Koder.ai) geliştiriyorsanız, bu kısıtları doğrudan istemek yardımcı olur: ilk JS küçük olsun, mount‑zamanlı effect'lerden kaçının ve ilk ekranı basit tutun.

Adım adım: yavaş bir sayfayı nasıl debug edersiniz

Belirtileni basitçe adlandırarak başlayın: “ilk yük 8 saniye sürüyor”, “kaydırma takılıyor” veya “yenilemeden sonra veri eski görünüyor”. Farklı semptomlar farklı nedenlere işaret eder.

Pratik bir iş akışı

İlk olarak ağ mı beklemeyle ilgili yoksa CPU mu yaktığına karar verin. Basit bir kontrol: yeniden yükleyin ve yüklenirken neler yapabildiğinize bakın. Sayfa boşsa ve hiçbir şey yanıt vermiyorsa genellikle ağ odaklısınızdır. Sayfa görünüyorsa ama tıklamalar gecikiyor veya kaydırma takılıyorsa genellikle CPU odaklısınızdır.

Her şeyi aynı anda düzeltmenizi engelleyecek bir iş akışı:

• Neyin yavaş olduğunu (ilk yük, etkileşim veya veri yenileme) ve kabaca süresini yazın.
• Ağ ve CPU'yu ayırın: bağlantınızı sınırlayın (throttle) ve karşılaştırın. Çok daha kötü oluyorsa ağ büyük rol oynuyor. Neredeyse değişmiyorsa CPU işine odaklanın.
• En büyük isteği ve en büyük uzun görevi (long task) bulun. Tek bir dev JS bundle, büyük bir görsel veya uzun bir "script" görevi genellikle en büyük suçludur.
• Bir nedeni aynı anda değil, tek tek kaldırın (bir bundle'ı bölün, bir görseli yeniden boyutlandırın, bir üçüncü taraf script'i erteleyin) ve tekrar test edin.
• Gerçekçi bir cihaz ve bağlantıda tekrar test edin. Hızlı bir dizüstü gizlenen sorunları orta segment telefonlarda ortaya çıkarır.

Somut bir örnek: AI tarafından üretilen bir React sayfası tek bir 2 MB JavaScript dosyası ve büyük bir hero görsel gönderir. Kendi makinenizde iyi hisseder. Bir telefonda JS'yi ayrıştırana kadar saniyeler harcar ve tepki veremez. İlk görünüm JS'ini küçültün ve hero görseli yeniden boyutlandırın; genellikle ilk etkileşim süresinde belirgin bir düşüş görürsünüz.

Kazancı sabitleme

Ölçülebilir bir iyileşme elde ettikten sonra, geri dönüşü zorlaştırın.

Bütçeler belirleyin (maks paket boyutu, maks görsel boyutu) ve sınırı aştığınızda build'in başarısız olmasını sağlayın. Depoda kısa bir performans notu tutun: ne yavaştı, ne düzeltti, neye dikkat etmeli. Büyük UI değişiklikleri veya yeni bağımlılıklar sonrası (özellikle AI hızlı bileşen üretiyorsa) tekrar kontrol edin.

AI ile oluşturulmuş ön yüzlerde yaygın hatalar (ve neden ortaya çıkarlar)

AI hızlıca çalışan bir UI yazabilir, ama sayfaları hızlı ve güvenilir yapan sıkıcı parçaları sıklıkla kaçırır. Tarayıcı temellerini bilmek sorunları erken fark etmenize yardımcı olur; yavaş yüklemeler, takılan kaydırmalar veya sürpriz API faturaları ortaya çıkmadan önce.

Aşırı fetch etmek yaygındır. AI tarafından üretilmiş bir sayfa aynı ekran için birden fazla endpoint çağırabilir, küçük state değişikliklerinde tekrar çekebilir veya sadece ilk 20 öğeye ihtiyacınız varken tüm veri setini alabilir. İstemler UI'yı şekillendirmeyi daha sık yapar, veri yapısını daha az tarif eder; model boşlukları fazladan çağrılar ve sayfalandırma/batching olmadan doldurur.

Render engelleyen kaynaklar başka bir yineleyen suçludur. Fontlar, büyük CSS dosyaları ve üçüncü taraf script'ler head'e eklenir çünkü “doğruymuş gibi” hissettirir, ama bunlar ilk boyamayı geciktirebilir. Boş bir sayfaya bakarken tarayıcı gerekli olmayan kaynakları bekliyor olur.

Önbellekleme hataları genellikle iyi niyetlidir. AI bazen başlıklar veya fetch seçenekleri ekleyerek “hiçbir şeyi yeniden kullanma” demiş olur çünkü daha güvenli görünür. Sonuç gereksiz indirmeler, daha yavaş tekrar ziyaretler ve backend üzerinde ekstra yük olur.

Hydration uyuşmazlıkları aceleyle üretilen React çıktılarında sık görülür. Sunucuda (veya pre-render adımında) oluşturulan markup istemcinin render ettiğiyle eşleşmez, React uyarır, yeniden render yapar veya event'ları tuhaf bağlar. Bu genellikle başlangıç render'ına rastgele değerler (tarihler, ID'ler) karıştırmak ya da yalnızca istemci durumuna bağlı koşullar kullanmaktan kaynaklanır.

Bu sinyalleri görürseniz, sayfanın performans korumaları olmadan monte edildiğini varsayın: tek ekran için çoğaltılmış istekler, kullanılmayan bir UI kütüphanesinin çektiği devasa JS bundle, effect'lerin kararsız değerlere bağlı olarak yeniden fetch tetiklemesi, fontlar veya üçüncü taraf script'lerin kritik CSS'den önce yüklenmesi veya önbelleklemenin tüm isteklerde global olarak devre dışı bırakılması gibi.

Koder.ai gibi bir vibe-coding aracı kullanıyorsanız, üretilen çıktıyı bir ilk taslak olarak ele alın. Sayfalandırma, açık önbellekleme kuralları ve ilk boyama öncesinde neyin yüklenmesi gerektiğine dair bir plan isteyin.

Gerçekçi bir örnek: AI ile oluşturulmuş bir React sayfasını düzeltmek

AI ile oluşturulmuş bir React pazarlama sayfası ekran görüntüsünde mükemmel görünebilir ama elde yavaş hissedebilir. Yaygın bir kurulum: bir hero bölümü, referanslar, fiyat tablosu ve bir "son güncellemeler" widget'ı API'ye vuran.

Belirtiler tanıdık: metin geç gösterilir, fontlar yüklendiğinde düzen sıçrar, fiyat kartları görseller geldikçe kayar, API çağrısı birden çok kez tetiklenir ve bazı varlıklar deploy sonrası eski kalır. Bunların hiçbiri gizemli değil. Temel tarayıcı davranışı UI'da kendini gösterir.

İki görünümle başlayın.

İlk olarak, DevTools'u açın ve Network waterfall'ını inceleyin. Her şeyi bloke eden büyük bir JS bundle, geç yüklenen fontlar, boyut ipucu olmayan görseller ve aynı endpoint'e tekrar eden çağrılar (çoğunlukla hafifçe farklı sorgu dizeleriyle) arayın.

İkinci olarak, yeniden yüklerken bir Performance trace kaydedin. Uzun görevler (ana iş parçacığını bloke eden JavaScript) ve Layout Shift olaylarına odaklanın (içerik geldikten sonra sayfanın yeniden akışa girmesi).

Bu senaryoda, küçük bir dizi düzeltme genellikle kazancın çoğunu verir:

• Önbellek başlıkları: versiyonlanmış varlıklar (ör. app.abc123.js) için uzun önbellek verin, HTML'in sonsuza kadar önbelleğe alınmadığından emin olun ki en yeni dosyalara işaret edebilsin.
• Font stratejisi: sistem yedeği kullanın, gerçekten ihtiyacınız olan bir iki fontu preload edin ve çok sayıda ağırlık yüklemekten kaçının.
• Kod bölme: “son güncellemeler” widget'ı ve ağır animasyon kütüphanelerini ilk boyamada değil, ihtiyaç olduğunda yükleyin.
• İstek temizliği: API çağrılarının bir kez çalıştığından emin olun (dev'de React Strict Mode effect'leri çift çağırabilir), fetch'leri dedupe edin ve bir pazarlama sayfasında polling'den kaçının.
• Görsel stabilitesi: tarayıcının alan ayırabilmesi ve düzen kaymasını önlemek için genişlik ve yükseklik (veya aspect-ratio) ayarlayın.

Fancy araçlar olmadan iyileşmeyi doğrulayın. Önce önbellek devre dışı üç kez yeniden yükleyin, sonra önbellek etkin üç kez yapın ve waterfall'ı karşılaştırın. Metin daha erken renderlanmalı, API çağrıları bire inmeli ve düzen sabit kalmalı. Son olarak bir deploy sonrası hard refresh yapın. Eğer hâlâ eski CSS veya JS görüyorsanız, önbellekleme kuralları nasıl build gönderdiğinizle uyumlu değil demektir.

Koder.ai ile sayfayı yarattıysanız aynı döngüyü koruyun: bir waterfall inceleyin, bir şeyi değiştirin, tekrar doğrulayın. Küçük yinelemeler AI ile oluşturulmuş ön yüzlerin “AI‑yapımı sürprizler” haline gelmesini önler.

Hızlı kontrol listesi ve sonraki adımlar

Bir sayfa yavaş veya takılı hissediyorsa, efsaneye gerek yok. Bir avuç kontrol çoğu gerçek dünya sorununu açıklar; AI tarafından üretilen UI'larda görülenleri de dahil.

Buradan başlayın:

• Ek yönlendirmeleri ortadan kaldırın (özellikle http'den https'ye veya www'den non‑www'ye). Her sıçrama gecikme ekler ve ilk boyamayı geciktirebilir.
• Önbellek başlıklarının varlık stratejinizle eşleştiğini doğrulayın. Büyük bir paket hiç önbelleğe alınmıyorsa, her ziyaret tam yeniden indirme olur.
• Render engelleyen CSS'i bulun. Head'teki büyük stil sayfaları renderı geciktirebilir ve üretilen çıktılar genellikle fazla CSS içerir.
• En büyük JavaScript dosyasını belirleyin ve neden ilk ekranda yüklenmesi gerektiğine karar verin.
• Aynı kaynağa tekrarlanan istekleri izleyin (çoğunlukla kararsız URL'ler veya eşleşmeyen önbellek kuralları nedeniyle).

Sayfa takılıysa, sadece yavaş olmaktan ziyade hareket ve ana iş parçacığı işine odaklanın. Düzen kaymaları genellikle boyutsuz görseller, geç yüklenen fontlar veya veri geldikten sonra boyutu değişen bileşenlerden gelir. Uzun görevler genellikle bir kerede çok fazla JavaScript çalıştırmaktan (ağır hydration, ağır kütüphaneler veya çok fazla düğüm render etme) kaynaklanır.

AI'ye prompt verirken, gerçek kısıtlara işaret eden tarayıcı kelimeleri kullanın:

• “Render engelleyen CSS'den kaçının; sadece üstte görünen kritik stilleri inline edin.”
• “Ana bundle'ı bölün; kritik olmayan kodu ilk etkileşimden sonra yükleyin.”
• “Statik varlıklar için Cache‑Control ayarla; dosya isimlerini fingerprint'le.”
• “Düzen kaymasını önle: görseller, reklamlar ve async bileşenler için alan ayır.”
• “Tekrarlanan fetch'lerden kaçın: istekleri dedupe et ve URL'leri stabil tut.”

Koder.ai üzerinde çalışıyorsanız, Planning Mode başta bu kısıtları yazmak için iyi bir yerdir. Sonra küçük değişikliklerle yineleyin, snapshot'lar ve rollback ile güvenli test yapın deploy öncesi.