Chat Sitesi Sayfa Hızını Artırma Rehberi: WebP/AVIF, Lazy-Load ve Preconnect ile Sohbet Performansı

Chat sayfalarında hız problemi çoğu zaman “tek bir görsel yavaş” gibi tek hamleyle açıklanacak bir durumdan çıkmaz. Mesaj akışının kendisi, avatarlar, emoji/medya ekleri, bağlantıların kurulma maliyeti ve üçüncü parti script’ler birlikte LCP/INP/CLS değerlerini zorlayabilir. Bu yüzden chat sitesi için sayfa hızını artırma: WebP/AVIF, lazy-load ve preconnect stratejisi yaklaşımını sadece teknik bir liste gibi değil; sohbet UI/UX akışına uyarlayarak düşünmek gerekir.

Bu rehber; liste ekranı, sohbet odası ve mesaj akışı gibi farklı yüzeylerde görsel/bağlantı yüklerini azaltmayı, ölçülebilir iyileştirmeler hedeflemeyi ve ekiplerin uygulayabileceği adım adım bir plan sunmayı amaçlar. Hedefimiz yalnızca “hız testini geçmek” değil; kullanıcı etkileşimi sırasında takılma (INP) ve düzen kayması (CLS) riskini de daha sistemli biçimde düşürmek.

Chat sayfalarında hız darboğazları: LCP/INP/CLS ve mesaj akışı

Chat uygulamalarında LCP (Largest Contentful Paint) genellikle ilk ekranda gözüken en büyük unsur üzerinden ölçülür. Çoğu senaryoda bu, üst alandaki avatar veya başlık bölümü olur; bazen de hero görseli LCP’yi sahiplenir. Sohbet odası açıldığında kullanıcı “sohbet başladı” hissini genellikle ilk mesaj/ilk avatar ile alır. Eğer bu bileşenler geç gelirse LCP doğal olarak düşer.

INP (Interaction to Next Paint) ise gönder butonuna basma, emoji panelini açma, mesajı düzenleme/reaksiyona verme gibi etkileşimlerin yanıt süresine odaklanır. Mesaj akışında çok sayıda resim ve DOM düğümü varsa, kullanıcı bir şey yaptığında tarayıcı yeniden yerleşim/hareket (reflow/repaint) yapmak zorunda kalabilir. Bu da INP’yi olumsuz etkiler.

CLS (Cumulative Layout Shift) ise genellikle “image yüklenirken alanın sonradan değişmesi” veya font/ikonların geç gelmesiyle tetiklenir. Mesaj listesinde farklı boyutlarda medya/emoji resimleri yer aldığında ve ölçü tanımı olmadan lazy-load devreye girerse CLS riski artar.

Hız hedefleri ve metrikler: Core Web Vitals neden kritik?

Sohbet sayfası, “tek seferlik sayfa yükü” gibi davranmaz; sürekli veri akışı ve kullanıcı etkileşimi olan bir arayüzdür. Bu yüzden Core Web Vitals’ı yalnızca rapor okunan bir metrik seti gibi değil, ürün kararlarıyla ilişkilendirerek yönetmek gerekir. LCP, ilk izlenim ve sohbetin “hazır” hissini; INP gün içi kullanımda takılma deneyimini; CLS de düzen stabilitesini ölçer.

Pratik bir çerçeveyle hedeflerinizi şöyle konumlandırın: LCP’yi ilk görsel bileşenlerin mümkün olan en erken zamanda render edilmesini kolaylaştırarak iyileştirin; INP’yi etkileşim anında çalışan JS iş yükünü azaltarak ve görsellerin yükleme/çözümleme maliyetini yayarak düşürün; CLS’yi resimlere boyut/placeholder vererek ve font/ikon stratejisiyle sabitleyin.

Özellikle mesaj akışında “çok sayıda resim yükleniyor” gerçeği vardır. Bu resimlerin tamamını aynı anda çözmek, hem ağ hem CPU hem de bellek baskısı oluşturur. WebP/AVIF + lazy-load + bağlantı ön hazırlığı (preconnect) bu baskıyı kontrollü hale getirir.

Görsel optimizasyonu: WebP/AVIF seçimi, kalite ve boyut dengesi

Sohbet UI’sinde görseller; avatar, thumbnail, medya önizleme (image attachments) ve hatta emoji sprite/ikon parçaları gibi farklı noktalarda karşınıza çıkar. Bu noktada “dosya boyutu” kadar “kod çözme (decode) maliyeti” ve “kalite yeterliliği” de önemlidir. AVIF genellikle daha iyi sıkıştırma sunar; WebP ise daha geniş ve tutarlı destekle hızlı bir başlangıç sağlar.

Örnek bir hedef seti düşünün: Avatar/thumbnail için görselin ekranda görünen boyutuna yakın bir piksel ölçüsü kullanın (ör. 64–128px UI için 256px’den fazlasını çoğu zaman boşa indirirsiniz). Kaliteyi körlemesine yükseltmeyin; sohbet deneyiminde çok yüksek kalite çoğu senaryoda şart değildir. Odak “net ama hafif” olmalıdır. Çünkü kullanıcı avatarı küçüktür; yüzde 90+ kalite, kullanıcı için belirgin fayda üretmeyebilir, maliyet üretir.

Bileşen	Önerilen Format	Hedef Boyut	Not
Avatar (64–80px)	AVIF (modern), fallback WebP	< 15–25 KB	Döndürme/yeniden boyutlandırma yerine UI ölçüsüne yakın çıkarım
Mesaj thumbnail (ör. 320–480px)	AVIF (modern), fallback WebP	ortalama 40–120 KB	Kalite/width varyantlarıyla CDN cache’i etkin kullan

Dönüşüm stratejinizi otomatikleştirin: sunucu tarafında ya da CDN image transform ile aynı URL için farklı format ve boyut varyantları sunun. Böylece tarayıcı Accept header ile AVIF/WebP’yi seçer. Dönüştürme süreciniz yoksa bile en azından statik avatar/thumbnail pipeline’ı kurun: orijinali kaybetmeden AVIF+WebP varyantlarını üretin.

Lazy-load stratejisi: Mesaj içeriği, ekler ve emoji görselleri

Lazy-load, sohbet akışında “ağır” görsellerin tamamını ilk anda indirmeyi engeller; ancak sohbet UX’ine uygun uygulanmazsa kullanıcı “eksik görseller” ile karşılaşır. Bu yüzden tetikleyici mantığı (hangi resim ne zaman yüklenir) belirleyicidir. Basit yaklaşım: mesaj listesinde kullanıcı yaklaşınca yüklemek.

IntersectionObserver ile doğru bir tetikleyici kurun. Mesajlar kaydıkça viewport’a yaklaşan görseller erken başlayacak; uzak tarafta kalanlar bekleyecek. Ayrıca lazy-load edilen öğelerde boyut tanımı bırakın (width/height veya CSS aspect-ratio). Böylece CLS yükselmesinin önüne geçersiniz.

1. Mesaj içeriğine giren her görselde loading="lazy" kullanmayı düşünün; ancak kontrolü IntersectionObserver ile sizde tutun.
2. IntersectionObserver rootMargin ile “biraz önce” yükleme yapın (ör. 200–600px).
3. Emoji/medya gibi küçük ama çok sayıda görseller için eşik değerlerini farklılaştırın: kullanıcı hızla kaydırıyorsa emoji yükleri daha erken başlayabilir.

IntersectionObserver örneği (mesaj içindeki görseller için):

// HTML: data-src ile gerçek kaynağı saklayın, src yerine placeholder kullanın
// <img class="chat-img" src="/img/placeholder-1x1.png" data-src="...avif" data-src-webp="...webp" width="64" height="64" />

const supportsAvif = window.matchMedia?.('(min-width:0)') && (() => {
  const c = document.createElement('canvas');
  return c.toDataURL('image/avif').indexOf('data:image') === 0;
})();

const toRealSrc = (img) => {
  // Uygulamanıza göre en iyi varyantı seçin
  // data-src: avif, data-src-webp: webp olabilir
  return supportsAvif ? img.dataset.src : (img.dataset.srcWebp || img.dataset.src);
};

const io = new IntersectionObserver((entries, observer) => {
  for (const entry of entries) {
    if (!entry.isIntersecting) continue;
    const img = entry.target;
    const realSrc = toRealSrc(img);

    img.src = realSrc;
    img.classList.add('is-loaded');

    observer.unobserve(img);
  }
}, {
  root: null,
  rootMargin: '400px 0px', // kullanıcı yaklaşırken başlasın
  threshold: 0.01
});

document.querySelectorAll('.chat-img').forEach((img) => io.observe(img));

Bu yaklaşımı güçlendirmek için mesaj listesi “infinite scroll” kullanıyorsa, yeni eklenen DOM öğeleri için de observer’a ekleme yapın. Böylece sadece ilk yük değil; sonradan gelen sayfalarda da aynı performans modeli korunur.

Preconnect ve DNS/TLS maliyeti: Hangi domainlere uygulanmalı?

Preconnect, tarayıcının bir domainle bağlantı kurma sürecini (DNS çözümleme, TCP/TLS handshake) daha erken başlatmasına yardımcı olur. Sohbet sayfalarında kritik olan yalnızca ana site domaini değildir; avatar/CDN, resim dönüştürme sağlayıcısı, analytics ve bazı durumlarda WebSocket fallback endpoint’leri gibi birden fazla domainin sürece girmesidir.

Genel kural: Sık kullanılan, ilk yükte yüksek öneme sahip ve bağlantı kurma maliyeti hissedilir olan domainleri preconnect’leyin. Aksi halde çok fazla preconnect, özellikle mobil ağlarda gereksiz kaynak tüketebilir.

Aşağıdaki preconnect örneğini, görsellerin servis edildiği CDN ve asset domainleri için kullanın:

<link rel="preconnect" href="https://cdn.ornek.com" crossorigin>
<link rel="preconnect" href="https://img.ornek.com" crossorigin>
<link rel="preconnect" href="https://analytics.ornek.com" crossorigin>
<!-- Eğer websocket fallback veya long-polling endpoint'in ayrı domain ise ekleyin -->
<link rel="preconnect" href="https://api.ornek.com" crossorigin>

crossorigin kullanımı, görsel/CORS devreye girecekse doğru ön hazırlığı destekler. CDN/asset domainleri için preconnect genellikle kazanım sağlar; analytics için ise hangi senaryoda gerçekten bloklayıcı olduğuna bakmak gerekir.

Kaynak önceliklendirme: fetch/preload/prefetch mantığı

Önceliklendirme (priority) sohbet sayfalarında “tam olarak neyi ilk render’da istiyorum?” sorusunun cevabıdır. Kritik olansa sadece en büyük görsel değil; kullanıcı etkileşimi için gereken minimum veri (ilk mesaj batch’i, ilk avatarlar, mesaj giriş alanı ikonları) olmalıdır.

Özellikle LCP’yi etkileyen öğe için preload iyi bir araçtır. Sohbet odası açılırken üst alanda büyük bir avatar/hero görsel kullanıyorsanız, bunu erken getirerek LCP’yi düşürebilirsiniz.

Kritik görseller için preload örneği:

<link rel="preload" as="image"
  href="https://cdn.ornek.com/avatars/user123-128.avif"
  imagesrcset="https://cdn.ornek.com/avatars/user123-128.avif 128w, https://cdn.ornek.com/avatars/user123-256.avif 256w"
  imagesizes="64px"
  type="image/avif" crossorigin>

<!-- WebP fallback -->
<link rel="preload" as="image"
  href="https://cdn.ornek.com/avatars/user123-128.webp"
  imagesrcset="https://cdn.ornek.com/avatars/user123-128.webp 128w, https://cdn.ornek.com/avatars/user123-256.webp 256w"
  imagesizes="64px"
  type="image/webp" crossorigin>

Prefetch’i ise “kesin lazım olacak” değil “yüklenmeye değer” olduğu durumlarda kullanın. Örneğin kullanıcı profil sekmesine veya medya önizleme ekranına geçeceğini bekliyorsanız, bir sonraki adım için düşük maliyetli ön yükleme yapılabilir.

Önbellekleme ve varyantlar: Cache-Control, ETag ve Accept header

Sohbet sayfalarında aynı avatarlar ve sık kullanılan ikonlar defalarca görünür. Bu yüzden cache stratejisi en az görsel format seçimi kadar önemlidir. Cache-Control başlıklarını doğru ayarlarsanız hem tarayıcı hem CDN tarafında tekrar indirme maliyetini düşürürsünüz.

Varyant yönetiminde iki eksen düşünün: format (AVIF/WebP) ve boyut (thumbnail/normal). HTTP tarafında Vary: Accept ve doğru Content-Type ile tarayıcıdan gelen Accept header’a göre en uygun varyant sunun. Ayrıca ETag/Last-Modified ile tekrar doğrulama maliyetini de azaltabilirsiniz.

Örnek kavramsal konfigürasyon mantığı (sunucu/CDN):

• Static avatar/thumbnails için uzun süreli Cache-Control: public, max-age=31536000, immutable (dosya adı hash’li ise).
• Varyantlarda Vary: Accept ve boyuta göre farklı URL’ler veya query yerine yol yapısı kullanma.
• Güncellenen kullanıcı avatarı için hash’li yeni URL üreterek eski cache’i boşa tüketmemek.

Sohbet özelinde performans: WebSocket/long-polling, ilk veri akışı, skeleton

Chat uygulamalarının performansı yalnızca “sayfa yükü”yle bitmez. WebSocket veya long-polling ile gelen veri akışı, etkileşim anında kullanıcı arayüzünün ne kadar hızlı tepki verdiğini etkiler. Örneğin WebSocket bağlanana kadar mesaj listesi boş kalıyorsa ve skeleton/placeholder kullanılmıyorsa kullanıcı “donmuş sayfa” hisseder. Bu da gözlemi kötüleştirir.

Bu yüzden iki katmanlı bir yaklaşım kurun: (1) İlk yükte mümkün olduğunca “boş değil ama minimal” UI render edin (sohbet başlığı, input alanı, iskelet mesajlar, ilk avatar spot’ları) (2) WebSocket bağlandıktan sonra mesaj batch’iyle akışı doldurun. Böylece LCP daha stabil olur; INP için de kullanıcı etkileşimi sırasında daha az ağır işlem çalışır.

Skeleton tasarımında CLS riskini azaltın: skeleton kartlarının gerçek mesaj kartlarıyla aynı boyut sistemine sahip olmasını sağlayın. Böylece “veri gelince alanlar kaymasın” hedefi tutar.

HTTP/2–HTTP/3 ve bağlantı sayısı azaltma: Üçüncü parti etkisi

Bağlantı sayısı arttıkça TLS ve bağlantı kurulumu maliyetleri büyür. HTTP/2 ve HTTP/3 paralelleştirmeyi iyileştirir ama sonsuz bant genişliği yoktur. Sohbet sayfasında üçüncü parti script’ler (chat widget’ı, anket, A/B testi, heatmap, reklam) yükleniyorsa, ana iş parçacığı (main thread) üzerinde gecikme yaratabilir.

Öncelikli yaklaşım: kritik olmayan üçüncü parti script’leri erteleyin. Aksi halde görsel/mesaj yükleri tamamlanmadan tarayıcı JS iş yüküne girer ve INP düşer.

Üçüncü parti script erteleme örneği:

<!-- Kritik olmayan: defer ile yüklenme sırasını bozmayın -->
<script defer src="https://tag.ornek.com/analytics.js"></script>

<!-- Daha iyisi: Etkileşim veya idle sonrasında yükle -->
<script>
  window.addEventListener('load', () => {
    const s = document.createElement('script');
    s.src = 'https://heatmap.ornek.com/sdk.js';
    s.async = true;
    document.head.appendChild(s);
  });
</script>

Uygulama adımları: HTML/JS örnekleri ve konfigürasyon mantığı

Somut bir planla ilerleyin. Aşağıdaki adımlar hem görsel maliyeti hem de bağlantı/etkileşim maliyetini birlikte azaltır. Ekipler çoğu zaman “format değiştiriyorum, bitti” yanılgısına düşer; sohbet özelinde asıl kazanım seti birden fazla tekniğin birlikte uygulanmasıyla ortaya çıkar.

1) Avatar/thumbnail için WebP/AVIF varyant seçimi (örnek hedefler)

Örnek WebP/AVIF dönüşüm hedefleri: Avatarı UI’da 72px gösteriyorsanız 128px kaynak yeterli olabilir; 72px’e indirip kalite düşürmek yerine 128px’te “netlik + makul boyut” dengesini yakalamak daha doğru olur. Thumbnail için ise 320px ve 640px olmak üzere iki varyant çoğu sohbet UI’si için iyi bir denge sunar.

HTML tarafında picture öğesiyle doğru formatı sunun:

<picture>
  <source
    type="image/avif"
    srcset="https://cdn.ornek.com/avatars/user123-128.avif 128w, https://cdn.ornek.com/avatars/user123-256.avif 256w"
    sizes="72px">

  <source
    type="image/webp"
    srcset="https://cdn.ornek.com/avatars/user123-128.webp 128w, https://cdn.ornek.com/avatars/user123-256.webp 256w"
    sizes="72px">

  <img
    src="https://cdn.ornek.com/avatars/user123-128.webp"
    width="72" height="72"
    loading="lazy"
    alt="Kullanıcı avatarı"
    decoding="async">
</picture>

2) Lazy-load + ölçü tanımı

Lazy-load yaparken her görsele width/height ya da CSS aspect-ratio tanımlayın. Bu, görsel geç geldiğinde CLS’yi azaltır. IntersectionObserver örneğini mesaj kartlarına uygulayın; emoji/medya için rootMargin değerini biraz daha agresif ayarlayabilirsiniz.

3) Kritik öğeleri preload edin

LCP hedefi için sohbet sayfasında en büyük görseli belirleyin ve sadece onu preload edin. Her şeyi preload yapmak yerine, LCP sorumlusu olan unsuru seçmek daha sağlıklı bir yaklaşımdır.

4) Üçüncü parti script’leri erteleme

Görsel ve mesaj akışı hazır olmadan üçüncü parti script’ler main thread’i meşgul edebilir. Bu yüzden analytics/heatmap/A-B testi gibi araçları defer veya load/idle sonrası yükleyin. WebSocket bağlanırken kritik bir işiniz yoksa script yüklerini geriye alabilirsiniz.

Test ve doğrulama: Lighthouse, PageSpeed Insights, WebPageTest ve RUM

Uygulama tamamlandıktan sonra “bir defa çalıştı” ile yetinmeyin. Sohbet sayfalarında gerçek performans; kullanıcı hızına (scroll), network koşullarına (3G/4G), cihaz CPU’suna ve mesaj hacmine göre değişir. Bu yüzden hem laboratuvar testleri (Lighthouse/PSI) hem de gerçek kullanıcı ölçümü (RUM) kullanın.

adım adım doğrulama yaklaşımıyla ilerleyin:

1. Laboratuvar ölçümü: Lighthouse ve PageSpeed Insights’ta LCP/INP/CLS değerlerine bakın; LCP sorumlusu görseli ve INP “main thread” darboğazını tespit edin.
2. Derin analiz: WebPageTest’te farklı viewport ve throttling senaryolarında mesaj akışını açıp ilk 30–60 saniyedeki görsel yük sırasını kontrol edin.
3. Gerçek kullanıcı ölçümü: RUM ile “ilk mesaj render süresi”, “gönder butonu yanıt süresi”, “scroll sırasında image decode gecikmesi” gibi ürün metrikleriyle korelasyon kurun.

Yaygın hatalar: Lazy-load ile UX bozmak ve cache’i yanlış kurgulamak

Lazy-load’ı kontrolsüz uygulamak sohbet deneyimini bozabilir. Örneğin rootMargin çok küçükse kullanıcı kaydırınca resimler geç görünebilir; bu da “sayfa geç yükleniyor” hissi yaratır ve INP’yi dolaylı etkileyebilir (kullanıcı tekrar tıklamaya yönelebilir). Ayrıca width/height tanımlamazsanız CLS artar ve mesaj kartları hareket eder.

Bir diğer sık hata, AVIF/WebP varyantlarını üretip teslim etmeden yalnızca HTML tarafında “varmış gibi” göstermektir. CDN tarafında Vary/Accept yönetimi yoksa yanlış format/yanlış cache yanıtı dönebilir. Sonuç olarak tarayıcı AVIF alamaz veya WebP yerine gereksiz büyük bir varyant indirir.

• Her görsel için otomatik lazy-load + boyutsuz img: CLS riskini artırır.
• Her domain için sınırsız preconnect: mobilde kaynak tüketimi yaratır.
• Üçüncü parti script’leri bloklayıcı şekilde yüklemek: INP düşer.

Core Web Vitals sohbet sayfasında nasıl yorumlanmalı (özellikle INP)

Sohbet sayfasında INP, “sadece etkileşim gecikmesi” değildir; aynı zamanda mesaj listesindeki DOM büyüklüğü, görsel decode yoğunluğu ve event listener’ların dağılımını da yansıtır. Bu yüzden INP raporlarını üretim ortamı verisiyle birlikte yorumlayın: kullanıcılar daha çok emoji eklediğinde mi INP düşüyor, yoksa mesaj gönderirken mi?

Özellikle mesaj akışında event delegasyonu yapın ve çok sayıda element üzerinde ayrı ayrı listener kurmayın. Görsel decode sürecini de azaltın: WebP/AVIF + doğru boyutlandırma + lazy-load ile decode yükünü zaman içinde yayarsınız. Böylece etkileşim anında main thread daha serbest kalır.

Sık sorulanlar (SSS)

WebP mi AVIF mi kullanmalıyım? (tarayıcı desteği ve kalite-boyut dengesi)

Genelde hibrit yaklaşım en iyisidir: picture ile AVIF’i destekleyen tarayıcıya AVIF, desteklemeyen tarayıcıya WebP sunun. Kalite-boyut dengesi için AVIF çoğu senaryoda daha düşük dosya boyutuyla benzer görsel netlik sağlar; ancak pipeline ve test ile “gerçek decode maliyeti”ni de kontrol edin.

Lazy-load sohbet uygulamasında neden bazen kötü UX yaratır? Nasıl düzeltilir?

Kötü UX genellikle iki sebepten doğar: (1) rootMargin/tetikleyici geç kalır, resimler kullanıcı kaydırınca görünür (2) boyut/placeholder verilmez, CLS oluşur. IntersectionObserver’da rootMargin’i artırın ve tüm görsellerde boyut tanımı yaptığınızdan emin olun.

Preconnect her siteye uygulanır mı, hangi domainler için doğru?

Her siteye değil. Preconnect, bağlantı kurma maliyeti hissedilen ve ilk yükte sık kullanılan domainler için uygundur: görsel/CDN domainleri, asset sağlayıcılar, kritik API endpoint’leri ve gerekirse websocket/long-polling fallback domainleri. Fazlası performansı ters etkileyebilir.

LCP’yi sohbet sayfasında nasıl düşürürüm (ilk mesaj/ilk avatar etkisi)?

LCP’den sorumlu öğeyi tespit edin. Çoğu sohbet sayfasında avatar/başlık alanı LCP olur. Bu öğeyi doğru boyutta üretin (gerekenden büyük değil), preload ile erken getirin ve decode’ı kolaylaştırmak için AVIF/WebP + uygun boyut varyantı kullanın.

Mesajlarda çok sayıda görsel/ek varsa en iyi yükleme stratejisi nedir?

Batch yükleme + lazy-load kombinasyonu en güvenlisidir. Yakın viewport’a yaklaşan görselleri IntersectionObserver ile yükleyin; uzak olanları bekletin. Medya eklerinde ayrıca görsel önizlemeyi küçültüp tıklamada tam dosyayı getirin.

CDN kullanmadan da WebP/AVIF ve cache optimizasyonu yapılır mı?

Evet. CDN olmasa bile AVIF/WebP varyantlarını kendi sunucunuzda üretip doğru Cache-Control ve ETag başlıklarıyla tarayıcı/ara bellek kullanımını artırabilirsiniz. Ancak CDN ile transform ve cache yönetimi genellikle daha verimli olur.

Core Web Vitals sohbet sayfalarında nasıl yorumlanmalı (INP özellikle)?

INP’yi “tek etkileşim anı” değil, etkileşim anındaki main thread yükü olarak yorumlayın. Mesaj listesi büyüdükçe etkileşim gecikmesi artıyorsa DOM/renderer yükünü azaltın; görsel decode yoğunluğu varsa lazy-load + doğru format/ölçü yaklaşımına dönün.

Chat sayfası performans kontrol listesi (hız darboğazı → uygulama)

Son olarak, ekiplerin her sprintte tekrarlayabileceği bir kontrol listesiyle ilerleyin. Bu liste sohbet sayfasının özelinde; mesaj akışı, görsel yükler, bağlantı maliyeti ve etkileşim gecikmelerini hedefler.

• Görsel format: Avatar/thumbnail için AVIF+WebP varyantları sunun; boyutları UI’a göre üretin.
• Lazy-load: Mesaj görselleri için IntersectionObserver kullanın; rootMargin ile “erken başlatın”; width/height verin.
• Preconnect: Görsel/CDN ve kritik API domainlerine <link rel="preconnect"> uygulayın.
• Öncelik: LCP sorumlusunu preload edin; her şeyi değil sadece kritik görseli seçin.
• Cache: Cache-Control ve ETag/immutable yaklaşımını doğru kurun; Accept/Vary ile varyant cache uyumluluğunu doğrulayın.
• INP: Üçüncü parti script’leri erteleyin; event listener’ları ve ana thread iş yükünü sadeleştirin.

Bu rehberin vaadi şudur: sohbet UI/UX akışına uygun biçimde görsel ve bağlantı yüklerini azaltıp, WebP/AVIF + lazy-load + preconnect’i ölçümle birlikte yöneterek LCP ve INP’de somut iyileştirme elde edebilirsiniz. Eğer isterseniz, sizdeki sohbet sayfası senaryosuna göre (liste mi oda mı, WebSocket mi long-polling mi, kaç görsel ortalama var) bir önceliklendirme planı da birlikte çıkarabiliriz.

İçeride önerilen yöntemler için ayrıca şu kaynakları inceleyebilirsiniz: Chat sitesi teknik SEO kontrol listesi (performans bölümünü referansla) ve sohbet özelinde SEO ile hızın nasıl birlikte yönetildiğine dair Sohbet sitesi SEO stratejileri (hız optimizasyonunu tamamlayıcı olarak).