Ürün açıklaması bütün ziyaretçiler için aynıdır; ancak oturum açan kişiye gösterilecek teslimat adresi farklı olabilir. Adres sorgusu yavaşsa ürün açıklamasını da bekletmek gerekir mi? Bu yazıda hayalî bir kitap satış sayfasıyla ortak ana içerik ve kullanıcıya özgü alanları ayırma kararını inceliyoruz. Anlatılan özellik, Astro’nun sunucu adalarıdır; tarayıcıda düğmeleri çalıştıran istemci adalarından farklı görev üstlenir.
1. İlk belgeyi sonradan gelen alandan ayırmak
Astro’nun resmî sunucu adaları belgesi, belirli bir bileşenin sunucuda işlenmesini geciktirip sonucunu ayrı istekle alma yöntemini açıklar. İlk HTML, temel içeriği ve bekleme gösterimini içerir; ayrı yanıt geldiğinde ilgili alan değiştirilir. Bunun için sunucuda istek işleyen bir adaptör gerekir.
Kitap satış sayfasında başlık, yazar ve tanıtımı ortak belgede bırakıp yalnızca adres özetini aday seçelim. Ziyaretçi adresi beklerken de kitabın ne olduğunu okuyabilir. Buna karşılık ödeme düğmesini anlamak için sipariş toplamını görmesi gerekiyorsa fiyat ile ödeme eylemi arasındaki ilişki de tasarlanmalıdır. Görünen öğeleri küçük kutulara bölmek, işlevsel ayrımı tek başına tamamlamaz.
Bu tasarımın başarısını önce neyin gösterildiği belirler. Ana içeriği neredeyse boş bırakıp çoğunu geciktirmek, ziyaretçiyi birçok yükleme göstergesini beklemeye zorlar. Önce ilk ekranda yanıtlanacak sorularla geç gelebilecek bilgileri listeleyin. Sunucu adaları beklemenin yerini değiştiren bir araçtır; veritabanı sorgusunu kendiliğinden hızlandırmaz.
2. fallback içeriğini de bitmiş ekranın parçası olarak tasarlamak
Aşağıdaki küçük örnek kullanım biçimini gösterir. UserDelivery bileşeni ve adaptörün ayrıca uygulanmış olduğu varsayılır.
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">Teslimat adresi bilgileri kontrol ediliyor.</p>
</UserDelivery>fallback, kısaca görünüp kaybolan bir süs değil, ziyaretçinin gerçekten okuduğu ilk içeriktir. Adres kartının son boyutuna benzer alan ayırın ve neyin beklendiğini açıklayın. Henüz bilgi yokken önceden “Teslimat yapılabilir” yazmak, gerçek yanıtla anlam çatışmasına yol açabilir. Bilinmeyen durum ile doğrulanmış sonuç görsel olarak da ayrılmalıdır.
Örneğin oturum açmamış ziyaretçiye “Kaydedilmiş teslimat adresinizi görmek için oturum açın” açıklaması gerekebilir. Ağın yavaş olmasıyla oturum açılmamış olması farklı durumlardır. Her birinin metnini ve gidilecek yolunu ayrı belirlemek, geliştirmede kolaylık için yazılan cümlenin canlı ekranda kalmasını azaltır.
3. Veri sınırını küçük tutmak
Bileşeni çağırırken yalnızca gösterim ve sorgu için gerekli değerleri aktarın. Bütün sipariş geçmişini geçirip yalnızca tek ad yazdırıyorsanız önce veri bağımlılığını azaltma fırsatı vardır. Bazı değerler genel içerikte bulunabilir; bazıları ancak kullanıcı doğrulamasından sonra sorgulanmalıdır. Değerin aktarıldığı yolu ve ekranda gösterildiği kapsamı aynı listede kontrol edin.
Sunucu adasının isteği ayrı bir yürütme bağlamındadır. Mantık mevcut sayfa adresini gerektiriyorsa gereken yolu asıl sayfadan açıkça aktarmayı değerlendirin. Ada içindeki istek URL’sini asıl ürün sayfası URL’si sanmak, sayfaya özgü öneri veya geri dönüş bağlantısını yanlış oluşturabilir. Uygulamada gerçek istek adresini geliştirici araçlarında doğrulamak daha güvenlidir.
Kitap numarasıyla kullanıcı tanımlama bilgisini işleyen hayalî bir örnek düşünülebilir. Kitap numarasını ortak öneri verisini sorgulamakta, kullanıcı bilgisini ise sunucuda kimlik doğrulama durumuna göre işlemekte kullanarak görevleri ayırın. Şifreli aktarım biçimi de sunucudaki yetki kontrolünün yerini tutmaz. Girdinin alındığı konumla son erişim kararının verildiği konumu ayrı belgeleyin.
4. Önbelleği ekranın hedef kitlesine göre belirlemek
Ortak kitap tanıtımıyla kişisel teslimat adresine aynı önbellek politikasını uygulamak zordur. MDN’nin HTTP önbelleği rehberi, paylaşılan ve kişisel önbellek ayrımını açıklar. Önce verinin aynı olup olmadığından çok yanıtın herkese gösterilip gösterilemeyeceğine karar verin.
İki test hesabıyla aynı sayfayı açıp ilk hesabın adresinin ikinci hesapta görünmediğini kontrol edin. Oturumu kapattıktan sonra geri gitme ve yenileme davranışını da inceleyin. Bu kontrol, önbellek sunucusu, tarayıcı ve uygulamanın kimlik doğrulamasının birlikte ürettiği sonucu değerlendirir. Yalnızca bileşen dosyasını okuyup güvenli olduğu sonucuna varılamaz.
Ortak kitap önerileri gibi paylaşılabilir bölümlerde de içerik değişince güncelleme yolu gerekir. Eski önerinin kısa süre kabul edilip edilmeyeceğini veya yönetici düzenlediğinde hemen değişip değişmeyeceğini belirleyin. “Önbelleği açıyoruz” demek yerine hedefi, saklama konumunu, kabul edilen eskiliği ve geçersiz kılma koşullarını yazmak, başka geliştiricilerin tasarımı incelemesini kolaylaştırır.
5. Önce yavaş bağlantı ve başarısızlığı sınamak
Sayfayı normal bağlantıda bir kez açarak değerlendirmeyin. Adres isteğini geciktirin, başarısız kılın, oturum durumunu değiştirin ve her ekranı inceleyin. Temel içerik okunabiliyor mu, yükleme alanı sonraki düğmeyi sürekli itiyor mu ve başarısız bilgiye bağımlı işlemler yapılabiliyor mu, kontrol edin.
| Sınama durumu | Ziyaretçinin anlaması gereken durum |
|---|---|
| Adres sorgusu yavaş | Ne bekleniyor ve başka içerik okunabilir mi? |
| Kimlik doğrulanmamış | Oturum açma açıklaması ve ortak içerik görünüyor mu? |
| Sorgu başarısız | Boş ekran yerine toparlanma yolu bulunabiliyor mu? |
| Hesap değişmiş | Önceki kullanıcının bilgisi kalıyor mu? |
Birden çok ada birbirinin sonucunu bekliyorsa ayırma biçimini yeniden inceleyin. Önce adresi alıp sonra kargo ücretini sorgulamak ve ardından ödeme açıklamasını çizmek, ardışık bekleme istekleri oluşturabilir. Bu durumda ilgili bilgileri tek sunucu işi içinde toplamak veya kullanıcının istediği anda sorgulamak daha uygun olabilir. Ayrım sayısının çokluğu tek başına iyi yapı anlamına gelmez.
6. Önceki ve sonraki kazancı aynı koşullarda karşılaştırmak
Karşılaştırma kaydında ilk ana içeriğin görünmesini, adres gösteriminin tamamlanmasını, işlem yapılabilir zamanı ve hata durumlarını ayrı yazın. İlk belge hızlı görünse de adres kartı çok kayıyorsa veya ödemeye başlama gecikiyorsa ziyaretçi deneyimi başka yönde değişebilir. Tek ortalama yerine yavaş örneklerde neyin beklendiğini de kaydedin.
Sunucu adası adayını seçerken sorunun somutluğu yararlıdır. “Bu site statik mi?” yerine “Bu bilgi gecikse de kitap tanıtımı önce okunabilir mi?” uygulama kararına daha çok yardım eder. Astro’nun isteğe bağlı işleme rehberi ile dağıtım ortamını kontrol edin; küçük bir kullanıcıya özgü alanla başlayıp gerçek başarısızlık durumlarına kadar sınayın.