1 saniye altında bir stüdyo sitesi: bağlı kaldığımız performans bütçesi

Orta düzey bir telefonda 4G üzerinden 1 saniyenin altında ilk içerik boyaması yapan stüdyo siteleri nasıl teslim ediyoruz — kendimize koyduğumuz bütçe, neyi kestiğimiz ve Core Web Vitals için en çok hangi kararların önemli olduğu.

Belirli bir tür stüdyo sitesi var — her kaydırmada parallax pırıltısı, font değişimi, üç saniye buffer'layan otomatik oynatan reel ve hover'da diş çıkaran imleç — orta düzey telefonda sekiz saniyede yükleniyor ve fiber olmayan her bağlantıda bozuk hissettiriyor. Biz bunları çıkarmıyoruz. Bağlı kaldığımız brief sert ve basit: orta düzey bir telefonda kısıtlanmış 4G üzerinde, 1 saniyenin altında ilk içerik boyaması.

Bu brief'i karşılamak kahramanca optimizasyon meselesi değil. Birikip büyüyen az sayıda mimari karar ve çok daha büyük sayıda yapmadığımız şey meselesi. Bu yazı, çalıştığımız bütçeyi, arkasındaki kararları ve bütçenin tutulduğunu kanıtlayan saha ölçümlerini anlatıyor.

Sayılarla bütçe

Teslim ettiğimiz her stüdyo sitesi şu rakamları hedefliyor (Chrome DevTools'ta Fast 3G kısıtlamasıyla Pixel 6a üzerinde): LCP 1.2sn altı (lab), 1.8sn altı (saha p75); FCP 1.0sn altı; CLS 0.05 altı; INP 100ms altı; ilk yükte toplam transfer boyutu 150KB altı; ilk yükteki JS 80KB altı. Bir sayfa bunlardan birini ıskalarsa bunu P1 hata olarak görüyoruz — siteyi yayına almadan düzeltiyoruz.

Neden bu kadar sıkı?

İki neden. Birincisi, Core Web Vitals Google için bir sıralama faktörü — eşitlik bozucu değil, sıralama faktörü. İkincisi, algılanan performans bir marka sinyali. Anında yüklenen bir site yetkin okunuyor. Bir tracking pixel çözülürken takılan bir site öyle okunmuyor.

Karar 1: Her şeyi statik render edin

Tek en büyük performans kararı render stratejisi. Next.js'i App Router ile kullanıyoruz ve stüdyo sitelerimizdeki her sayfa build zamanında statik render ediliyor. Çalışma anında veritabanı sorgusu yok. HTML'i servis eden edge fonksiyonunun ötesinde istek başına sunucu işi yok. Bütün site CDN üzerindeki dosyalar.

Karar 2: Bir web fontu, iki ağırlık

Özel fontlar ilk boyamada kontrol edilebilir en büyük gider. Tek ağırlık için bir web font subset'i tipik olarak sıkıştırılmış 25-40KB. İki ailenin üç ağırlığını yükleyen bir site, ilk içerik baytı boyanmadan önce 150KB font yolluyor. Biz bir aileyi iki ağırlıkta gönderiyoruz, next/font'un self-hosted, hash'li teslimatıyla.

Karar 3: Hero görsel bütçesi

Bir stüdyo sitesinde LCP neredeyse her zaman hero'dur. Yani LCP bütçesi hero bütçesi. Hero'ya sıkı bir tavan veriyoruz: masaüstü breakpoint'inde sıkıştırılmış 80KB, mobilde 40KB. Bunun üstündeki her şey, bütçeyi aşmak için bir bahane değil, görsel seçiminde veya işlemede çözülecek bir yaratıcı sorun.

Bizi bütçe içinde tutan dört uygulama: desteklenen yerde AVIF (WebP fallback ile); next/image üzerinden responsive boyutlar; her görselde açık genişlik ve yükseklik (CLS'yi önleyen şey bu); ve hero görselin preload edilmesi. <link rel="preload" as="image"> tek satır, LCP'de 200-400ms kazandırıyor.

Karar 4: JavaScript son çare olarak

Her kilobayt JavaScript, sayfa interaktif olmadan önce ana iş parçacığında indirilmesi, parse edilmesi ve çalıştırılması gereken bir kilobayttır. Server component'ler varsayılan. Yalnızca etkileşim gerektiren bir bileşeni 'use client' olarak işaretliyoruz. İlk yükte üçüncü taraf script yok.

Karar 5: CLS hatası göndermeyen CSS mimarisi

Cumulative Layout Shift, kazara başarısız olunması en kolay Core Web Vital ve bilinçle düzeltilmesi en kolay olanı. CLS'yi sıfıra yakın tutan dört alışkanlık: geç gelen her şey için yer ayır; font yüklenmesine bağımlı CSS'ten kaçın (font-display: swap kullan); fold üstüne yüklenme sonrası içerik enjekte etme; yavaş ağlarda test et.

Karar 6: Animasyon bütçesi

Harekette kısıtlama kendi başına bir performans optimizasyonu. Yalnızca transform ve opacity'yi animate edin — ikisi de GPU-composite ve layout tetiklemiyor. Reveal animasyonları CSS, JavaScript değil. Scroll'a bağlı animasyon yok. Hero'da otomatik oynatan video yok.

Karar 7: Erişilebilirlik / performans örtüşmesi

Çoğu erişilebilirlik kazancı aynı zamanda bir performans kazancı. Anlamsal HTML, div çorbasından küçük. Yerel focus halkaları özel JS focus yönetiminden daha hızlı render oluyor. Erişilebilirlik için önce tasarlıyor ve kodluyoruz; performans bedavaya geliyor.

Üretimde ölçüm

Lighthouse'tan lab metrikleri gerekli ama yeterli değil. Altın standart gerçek kullanıcı izleme (RUM) — gerçek cihazlardaki gerçek ziyaretçilerin yaşadığı. Vercel Analytics'i Web Vitals için kullanıyoruz çünkü platformla ücretsiz geliyor ve rota, cihaz, coğrafya bazında saha metriklerini raporluyor.

Yapmadığımız şeyler

Endüstri standardı olmasına rağmen bilinçle dışarıda bıraktığımız şeyler: küçük bir sitede SPA tarzı client-side routing yok; service worker yok; 30KB SDK enjekte eden bir görsel hosting servisi yok; akıllı lazy-load kütüphanesi yok; her linki hover'da prefetch eden mantık yok.

Bir site planlıyor ve elinizdekinin performans denetimini istiyor ya da baştan bu bütçeyle kurulmuş olanını istiyorsanız, hello@neptay.com.