Portfolio siteleri yüksek çözünürlüklü görseller, hareketli geçişler ve yoğun etkileşim kullandığı için performans sorunlarını kolayca saklayabilir. Masaüstünde hızlı görünen bir sayfa, orta seviye telefonda ilk proje kapağını geç gösterebilir veya filtre tıklamasına geç cevap verebilir. Core Web Vitals bu hissi üç ayrı açıdan ölçer: Largest Contentful Paint ana içeriğin görünme süresini, Interaction to Next Paint etkileşimlerin görsel yanıta dönüşme hızını, Cumulative Layout Shift ise beklenmedik yer değiştirmeleri izler.
Puan değil, gerçek kullanıcı deneyimi ölçülür
Google'ın web.dev belgeleri iyi deneyim için LCP değerinin 2,5 saniye veya altında, INP değerinin 200 milisaniye veya altında, CLS değerinin ise 0,1 veya altında olmasını önerir. Değerlendirme tek bir hızlı test üzerinden değil, mobil ve masaüstü ziyaretlerin yüzde 75'lik dilimi üzerinden yapılır. Bu ayrım önemlidir: geliştiricinin güçlü bilgisayarındaki Lighthouse sonucu ile gerçek ziyaretçilerin saha verisi aynı şeyi anlatmayabilir.
Önce Search Console veya CrUX gibi saha kaynaklarında hangi URL grubunun sorun yaşadığı bulunmalıdır. Ardından PageSpeed Insights ve tarayıcı performans araçlarıyla sorun tekrar üretilir. Portfolio ana sayfası, proje listeleme sayfası ve medya yoğun detay sayfası birbirinden ayrı ele alınmalıdır. Tek bir ortalama, yavaş sayfayı görünmez kılabilir.
LCP için ilk büyük görseli doğru seçmek
Portfolio sayfasında LCP öğesi çoğu zaman hero görseli veya ilk büyük proje kapağıdır. Bu görselin HTML içinde erken bulunması, doğru boyutta sunulması ve gereksiz bir istemci tarafı koşulunu beklememesi gerekir. İlk ekrandaki kritik görseli tembel yüklemek gecikme yaratabilir; ekran dışındaki galeriyi aynı öncelikle indirmek ise ağ bağlantısını gereksiz yere paylaşır.
Görsel dosyasının modern formatta olması tek başına yeterli değildir. Tarayıcıya gerçek görüntüleme genişliğini anlatan responsive kaynaklar hazırlanmalı, genişlik ve yükseklik değerleri belirtilmeli ve mobilde hiçbir zaman kullanılmayacak dev bir dosya gönderilmemelidir. LCP optimizasyonu sırasında sunucu yanıtı, kaynak keşif gecikmesi, dosyanın indirilmesi ve son render aşaması ayrı ayrı incelenirse çözüm daha görünür olur.
INP için filtre, menü ve slider akışını test etmek
INP yalnızca ilk tıklamayı ölçmez; ziyaret boyunca yapılan tıklama, dokunma ve klavye etkileşimlerinin gecikmesini gözlemler. Portfolio filtreleri, arama alanı, mobil menü, slider kontrolleri ve iletişim formu bu nedenle gerçek test senaryolarına dahil edilmelidir. Kullanıcı butona bastığında ana iş parçacığı uzun bir JavaScript göreviyle meşgulse geri bildirim gecikir ve arayüz bozukmuş gibi hissedilir.
Önce olay işleyicisinde gereksiz hesap, büyük liste dönüşümü veya senkron depolama işi olup olmadığı araştırılır. Tek tıklamada yüzlerce kartı yeniden kurmak yerine değişen bölüm sınırlandırılabilir. Ağ isteği gerekiyorsa butonun durumu hemen görünür biçimde güncellenir; sonuç geldiğinde içerik tamamlanır. Uzun görevler küçük parçalara ayrılabilir, ancak her yerde rastgele gecikme eklemek yerine ölçülen darboğaz hedeflenmelidir.
CLS için medya alanını baştan ayırmak
Görsel ölçüleri bilinmediğinde tarayıcı dosya gelene kadar ne kadar alan ayıracağını kestiremez. Kapak yüklendiğinde aşağıdaki başlık ve butonların kayması, özellikle mobilde yanlış tıklamaya yol açar. Görsellerde doğal genişlik ve yükseklik, video embed alanlarında sabit oran, sonradan gelen banner ve fontlarda kontrollü yerleşim kullanmak kararlılığı artırır.
Animasyon da yerleşim kayması yaratabilir. Boyut ve konum değiştiren animasyonlar yerine mümkün olduğunda transform ve opacity tabanlı geçişler seçilmelidir. Fakat teknik olarak kayma sayılmayan bir hareket yine de kullanıcıyı yorabilir; performans metriği tasarım değerlendirmesinin yerine geçmez.
Portfolio için ölçüm senaryosu kurmak
Test listesi gerçek ziyaret yolculuğunu izlemelidir: ana sayfayı aç, ilk projeyi gör, kategori filtresi seç, detay sayfasına geç, galeriyi tara ve iletişim aksiyonuna bas. Bu akış düşük hızlı ağ ve orta seviye mobil işlemci koşulunda denenmelidir. Klavye kullanımı, hareket azaltma tercihi ve büyük metin ayarı da düzenin dayanıklılığını gösterir.
Her sürümde tek seferlik skor ekran görüntüsü almak yerine temel sayfa tipleri için bütçe tanımlanabilir. Örneğin ilk ekran görselinin dosya ağırlığı, ilk yükte çalışan istemci JavaScript'i ve kritik font sayısı sınırlandırılabilir. Bütçe aşıldığında build veya gözden geçirme süreci uyarı verir. Böylece performans son teslim gününde yapılan kozmetik bir temizlik olmaktan çıkar.
Tasarım ve geliştirme birlikte karar vermeli
En büyük kazanç çoğu zaman koddan önce gelir. Ana mesajı taşımayan otomatik video, ilk ekranda aynı anda yüklenen çok sayıda font kalınlığı veya yalnız dekorasyon için kullanılan ağır efektler brief aşamasında sorgulanmalıdır. Tasarımcı hangi içeriğin önce görünmesi gerektiğini, geliştirici bunun en düşük maliyetle nasıl sunulacağını belirler.
Amaç her hareketi kaldırmak değildir. Öncelik sırası kurulur: kimlik ve anlam taşıyan etki korunur, tekrarlanan süsler azaltılır, hareket azaltma tercihi desteklenir. Ölçüm sonrasında kullanıcı davranışıyla birlikte bakıldığında iyi performans ile güçlü görsel anlatım arasında kalıcı bir denge kurulabilir.
Performans değişikliği yayınlandığında yalnız laboratuvar puanı değil saha eğilimi de beklenmelidir. CrUX verisinin gerçek ziyaretleri toplaması zaman alabilir. Değişiklik tarihi, etkilenen sayfa şablonu ve beklenen metrik kaydedilirse birkaç hafta sonra görülen fark doğru sürümle ilişkilendirilebilir. Trafiği düşük yeni sayfalarda yeterli saha verisi oluşmayabilir; bu durumda kontrollü lab testi ve kendi anonim RUM verisi birlikte kullanılabilir.
LCP, INP ve CLS'i iyileştirmek tasarım kararlarından ayrı düşünülemiyor: görsel boyutu, yazı tipi yükleme ve yerleşim kararları doğrudan bu metrikleri belirliyor. Web tasarım ve yazılım hizmetimde performans kontrollerini geliştirmenin bir parçası olarak yürütüyorum.
