Hızlı sitenin arkasındaki mimari kararlar

Lighthouse skoru bir hedef değil, doğru kararların sonucudur. Aşağıda hızlı bir sitenin arkasında duran mimari kararları ve her birinin bedelini yazdık, çünkü her tercihin bir bedeli var.

1. Sayfayı önceden üret, istek anında üretme

Bir sayfanın içeriği her ziyaretçi için aynıysa o sayfayı her istekte yeniden üretmenin anlamı yoktur. Derleme sırasında bir kez üretip statik dosya olarak sunmak, sunucuda hesaplama yapılmadığı için en hızlı seçenektir.

Bedeli: İçerik değiştiğinde yeniden üretim gerekiyor. Günde birkaç kez değişen içerik için uygundur, saniyede değişen içerik için değildir.

Ara bir yol da var: sayfayı statik üretip belirli aralıklarla arka planda tazelemek. Böylece ziyaretçi her zaman hazır bir sayfa alıyor ama içerik de bayatlamıyor.

2. Varsayılan olarak sunucuda çalıştır

Modern React'te bileşenlerin çoğu sunucuda çalışabiliyor ve istemciye hiç JavaScript göndermiyor. Yalnızca gerçekten etkileşim gereken parçalar istemci bileşeni oluyor.

Bu ayrımı gevşek tutmak bütün sayfayı istemciye taşıyor ve etkileşim gecikmesini bozuyor. Pratikte en sık yapılan hata, tek bir küçük etkileşim için koca bir bölümü istemciye çekmektir. Doğrusu, etkileşimli parçayı ayrı ve küçük bir bileşene çıkarmaktır.

Bedeli: Hangi bileşenin nerede çalıştığına dikkat etmek gerekiyor; disiplin istiyor.

3. Açılır kapanır her şey JavaScript istemiyor

Sık sorulan sorular bölümü, HTML'in kendi açılır kapanır etiketleriyle sıfır JavaScript ile çalışıyor: klavye erişimi, ekran okuyucu davranışı ve sayfa içi arama tarayıcıdan geliyor.

Aynısı çoğu sekme, açılır menü ve iletişim kutusu için de geçerlidir.

Bedeli: Animasyon üzerinde daha az kontrol. Genellikle kabul edilebilir bir takastır.

4. Yazı tipini kendi sunucundan ver

Dışarıdan çekilen bir yazı tipi ek bağlantı ve gecikme demektir. Kendi sunucunuzdan sunulduğunda hem istek azalıyor hem de metnin ne zaman görüneceği kontrol edilebiliyor.

Ölçüleri baştan bildirmek de metnin yerleşirken kaymasını önlüyor. Yedek yazı tipinin ölçüleri asıl yazı tipine yaklaştırıldığında, geçiş anındaki kayma tamamen ortadan kalkıyor.

Bedeli: Yazı tipi dosyalarının yönetimi sizde. Küçük bir yüktür.

5. Görselin ölçüsünü her zaman belirt

Genişlik ve yükseklik verilmemiş bir görsel, yüklendiği anda altındaki içeriği aşağı itiyor. Bu, düzen kaymasının bir numaralı sebebidir ve tamamen önlenebilir.

Ekranın üstünde görünen görsel öncelikli, geri kalanı tembel yüklenmelidir. Ayrıca farklı ekran genişlikleri için farklı boyutlar sunmak, telefona gereksiz büyük dosya göndermeyi engelliyor.

Bedeli: Yok. Bunu yapmamanın hiçbir gerekçesi yok.

6. Üçüncü taraf içeriği en sona bırak

Harita, video gömüsü, sohbet aracı ve analiz betiklerinin hepsi ağırdır. Bu yükün büyük kısmı sayfanın kendi kodundan değil, dışarıdan gelir.

Üç ayrı yöntem var ve hangisinin uygun olduğu içeriğe göre değişiyor:

• Geç yükleme. İçerik ekranda görünene kadar hiç yüklenmiyor. Sayfanın altında duran harita için doğru yöntem budur.
• Kapak görseli. İçerik bir görselle temsil ediliyor, kullanıcı tıklayınca gerçek gömü yükleniyor. Video için idealdir.
• Onaydan sonra yükleme. Analiz ve pazarlama betikleri çerez onayı verilene kadar hiç çalışmıyor. Bu hem hız hem hukuk açısından doğru olanıdır.

Bedeli: Bazı durumlarda kullanıcı bir tıklama fazladan yapıyor. Bunu her içerik için değil, ağırlığı gerçekten yüksek olanlar için tercih etmek gerekiyor.

7. Animasyonu görünmeyen yerde çalıştırma

Sürekli dönen bir animasyon, öğe ekranda olmasa bile her karede iş üretiyor. Bu iş doğrudan kaydırma akıcılığından çalınıyor.

Çözüm basit: bölüm ekrandan çıktığında animasyonu duraklatmak. Bu sitede tam olarak böyle yapılıyor ve kaydırma sırasında ölçülen kare süresi belirgin biçimde düştü.

Bedeli: Birkaç satır ek kod.

8. Ölçmediğiniz şeyi iyileştiremezsiniz

Yukarıdaki kararların hepsi doğru olsa bile, sonradan eklenen tek bir ağır betik hepsini geçersiz kılabiliyor.

Bu yüzden hız, bir kerelik iş değil sürekli bir kontroldür. Her yayından sonra ölçmek ve sonucu kaydetmek, gerileme olduğunda hemen fark edilmesini sağlıyor. Ölçüm yöntemini web sitesi hızı nasıl ölçülür yazısında adım adım anlattık.

Skor bir sonuç, hedef değil

Bu kararların hepsi alındığında skor zaten yükseliyor. Tersi çalışmıyor: skoru yükseltmek için sonradan yapılan müdahaleler genellikle yüzeysel kalıyor ve saha verisine yansımıyor.

Asıl ölçüt de skor değil. Sayfa gerçek bir telefonda, gerçek bir bağlantıda hızlı açılıyorsa iş bitmiştir.

---

Mevcut sitenizin mimarisini inceleyip nerede takıldığını çıkarabiliriz. Web tasarım ve geliştirme sayfasında nasıl çalıştığımızı anlattık.