Mobil performans farkı.

Aynı sayfa mobil cihazlarda masaüstünden belirgin biçimde yavaş çalışır ve bunun sebebi ağ değil, işlemci gücüdür.

Performans testleri çoğunlukla geliştiricinin kendi makinesinde yapılıyor ve o makine, gerçek kullanıcıların cihaz dağılımının en iyi ucunda duruyor. Sonuç, sistematik olarak iyimser bir tablo ve saha verisiyle sürekli ayrışan bir laboratuvar skoru.

Fark en çok JavaScript'te görünüyor. Bir betiğin indirilme süresi ağa bağlıdır ve mobil ağlar bazen masaüstünden hızlıdır; ama o betiğin ayrıştırılma, derlenme ve çalıştırılma süresi işlemciye bağlıdır ve orta sınıf bir telefon, bir dizüstü bilgisayarın kat kat gerisindedir.

Aynı bayt, farklı maliyet

Bu asimetri, bayt bazlı bütçelerin neden yeterli olmadığını da açıklıyor. Yüz kilobaytlık bir görsel her cihazda yaklaşık aynı maliyeti taşır — indirilir ve çözülür. Yüz kilobaytlık bir betik ise cihaza göre kat kat farklı maliyet üretir.

Pratik sonuç: mobil performans çalışmasının odağı görsel değil JavaScript olmalı. Görselleri küçültmek her cihazda benzer kazanç verir; betikleri küçültmek zayıf cihazlarda orantısız kazanç verir.

İkinci sonuç, test cihazının seçimiyle ilgili: en yeni telefonda test etmek, en yeni dizüstünde test etmekten çok az farklıdır. Anlamlı test, orta ya da alt segment bir cihazda yapılır — ya da tarayıcı araçlarındaki işlemci yavaşlatma ayarıyla simüle edilir.

1. 01Dört kat yavaşlatma — orta segment cihaza yakın bir simülasyon.
2. 02Altı kat yavaşlatma — alt segment cihaz. Google'ın kendi mobil testi bu civarda.
3. 03Ağ kısıtı ayrı — işlemci yavaşlatmayla birlikte kullanılmalı; ikisi farklı şeyleri yakalar.
4. 04Gerçek cihaz — simülasyonun yerini tutmaz; en az bir kez gerçek bir telefonda test edilmeli.
5. 05Saha verisi — nihai hakem. Simülasyon bir tahmindir, saha verisi ölçümdür.

Görüntü alanı ve düzen

Mobilde ikinci bir fark daha var ve gözden kaçıyor: aynı içerik dar bir ekranda çok daha uzun bir sayfa üretiyor. Bu, görünür alandaki öğe sayısını değiştiriyor ve dolayısıyla hangi öğenin LCP öğesi olduğunu da değiştirebiliyor.

Masaüstünde hero görseli LCP öğesiyken, mobilde bir başlık metni olabiliyor. İkisi tamamen farklı tedaviler gerektiriyor — biri görsel optimizasyonu, diğeri yazı tipi yükleme davranışı. Bu yüzden LCP öğesi her kırılımda ayrı belirlenmelidir.

Aynı ayrım dokunma hedefleri ve düzen kayması için de geçerli: mobil kırılımda daralan bir ızgara, masaüstünde sorunsuz olan hedefleri eşiğin altına düşürebiliyor ve sonradan gelen içerik dar ekranda daha büyük bir kayma üretiyor.

Bu sitede doğrulama süiti mobil kırılımı ayrı bir blok olarak ölçüyor: 390 piksel genişlikte sayfa akışı, dokunma hedefleri, metin kırpılması ve yazı sayfası ölçüleri ayrı ayrı denetleniyor. Masaüstü ölçümünün mobili kapsadığı varsayımı hiç yapılmıyor.

Masaüstünde ölçülen hiçbir şey mobil hakkında bir şey söylemez; ikisi ayrı ölçülür.

Ağ değişkenliği

İşlemci farkı en büyük etken ama tek etken değil; mobil ağların değişkenliği de bir tasarım kısıtı. Sabit bir bağlantıdan farklı olarak mobil bağlantı, kullanıcı hareket ettikçe hız ve gecikme değiştiriyor — ve bazı anlarda tamamen kesiliyor.

Bu, dayanıklılık gerektiriyor. Bir isteğin başarısız olması istisna değil beklenen bir durum; arayüzün o durumda ne yapacağı tasarlanmış olmalı. Sessizce başarısız olan bir form, kullanıcının verisini kaybettirir.

Bu sitede iletişim formu bu ilkeyle kurulu: sunucu yanıt vermezse akış e-posta bağlantısına devrediyor. Kanal hiçbir durumda tamamen kapanmıyor ve doğrulama süiti bu yedek davranışı ayrıca ölçüyor.

1. 01Yavaş bağlantı — içerik kademeli gelmeli; boş ekran değil iskelet gösterilmeli.
2. 02Kesintili bağlantı — istek başarısız olduğunda kullanıcıya ne olduğu söylenmeli.
3. 03Ölçülü veri paketi — veri tasarrufu tercihi bildiriliyorsa ağır kaynaklar yüklenmemeli.
4. 04Yüksek gecikme — istek sayısı azaltılmalı; her gidiş dönüş pahalı.
5. 05Yedek yol — kritik akışlar tek bir teknolojiye bağlı olmamalı.

Son madde bir mimari ilke ve mobilin ötesine geçiyor: tek dönüşüm yolu olan bir akış, tek bir teknolojinin çalışmasına bağlı olmamalı. Bu, performans kadar güvenilirlik meselesi — ve ikisi burada aynı çözümü işaret ediyor.

Pratik kontrol listesi

Bu sayfanın anlattıklarını bir denetim adımına çevirmek gerekirse, mobil performansı için bakılacaklar şunlar. Liste kısa tutuldu çünkü uzun listeler yürünmüyor; altı madde bir oturumda tamamlanabilir.

1. 01Test yavaşlatılmış işlemciyle yapıldı mı?
2. 02En az bir kez gerçek bir orta segment cihazda denendi mi?
3. 03LCP öğesi mobilde farklı mı — masaüstünden ayrı belirlenmeli.
4. 04Mobil kırılımda dokunma hedefleri eşiğin üstünde mi?
5. 05Ağ kesintisinde arayüz ne yapıyor?
6. 06Saha verisi mobil ve masaüstü ayrı okundu mu?

Üçüncü madde en çok gözden kaçanı: masaüstünde hero görseli LCP öğesiyken mobilde bir başlık metni olabiliyor ve ikisi tamamen farklı tedavi gerektiriyor.

Masaüstünde ölçülen hiçbir şey mobil hakkında bir şey söylemez.

Kapanışta bir öncelik çerçevesi: çoğu sitede trafiğin yarısından fazlası mobilden geliyor ve performans çalışması hâlâ masaüstü öncelikli yapılıyor. Bu ters öncelik, en çok kullanıcıyı etkileyen sorunların en son ele alınması anlamına geliyor.

Düzeltmesi bir alışkanlık değişikliği: ölçüme mobilden başlamak, test cihazını orta segment seçmek ve saha verisini mobil kırılımıyla okumak. Üçü de ek maliyet getirmiyor — yalnız hangi sayının önce bakılacağını değiştiriyor. Ve bu sitede süit mobil kırılımı ayrı bir blok olarak ölçüyor; masaüstü ölçümünün mobili kapsadığı varsayımı hiç yapılmıyor.

Kapanışta bir ölçüm hatırlatması: mobil saha verisi genelde masaüstünden belirgin biçimde kötü çıkıyor ve bu normal. Sorun, o farkı görüp «mobilde iyileştirilecek çok şey var» demek değil — sorun, iki veriyi birleştirip ortalamaya bakmak ve farkı hiç görmemek. Ayrı okunan iki sayı bir teşhis verir; birleştirilmiş tek sayı yalnız bir his verir.