Опис товару однаковий для всіх відвідувачів, але адреса доставки користувача, який увійшов, може відрізнятися. Чи варто через повільний запит адреси затримувати й опис? На уявній сторінці продажу книжок розглянемо рішення про розділення спільного тексту та користувацьких ділянок. Ідеться про серверні острови Astro, роль яких відмінна від клієнтських островів, що забезпечують роботу кнопок у браузері.
1. Відокремити початковий документ від ділянок, що надходять пізніше
Офіційна документація серверних островів Astro пояснює відкладання серверного рендерингу компонента та отримання результату окремим запитом. Початковий HTML містить основний текст і показ очікування; окрема відповідь замінює відповідну ділянку. Для обробки запитів на сервері потрібен адаптер.
Залишимо назву книжки, автора й опис у спільному документі, а кандидатом на відкладання оберемо лише зведення адреси. Очікуючи адресу, відвідувач може читати про книжку. Якщо ж для розуміння кнопки оплати потрібна підсумкова сума замовлення, треба спроєктувати й зв’язок ціни з оплатою. Самого розрізання видимих елементів на маленькі прямокутники для розділення функцій недостатньо.
Успіх визначає те, що показано першим. Майже порожній текст із відкладеною більшістю вмісту змушує чекати кількох індикаторів завантаження. Спочатку окремо перелічіть питання, на які має відповісти перший екран, та інформацію, яка може прийти пізніше. Серверні острови змінюють місце очікування, але самі не прискорюють запити до бази даних.
2. Проєктувати fallback як частину завершеного екрана
Невеликий приклад показує спосіб використання. Передбачається, що компонент UserDelivery й адаптер реалізовано окремо.
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">Перевіряємо дані адреси доставки.</p>
</UserDelivery>fallback — не прикраса, що з’являється й зникає, а початковий вміст, який відвідувач справді читає. Залиште місце приблизно розміру кінцевої картки адреси та поясніть, чого очікують. Напис «Доставка доступна» до отримання даних може суперечити фактичній відповіді. Невідомий стан і підтверджений результат слід розрізняти й візуально.
Наприклад, відвідувачу без входу може знадобитися підказка «Увійдіть, щоб побачити збережену адресу доставки». Повільна мережа й відсутність входу — різні стани. Окремо визначені тексти та шляхи переходів зменшують імовірність, що тимчасові фрази розробки залишаться на робочому екрані.
3. Зберігати невеликі межі даних
Викликаючи компонент, передавайте лише значення для показу й запиту. Якщо вся історія замовлень передається заради одного імені, спочатку можна скоротити залежності від даних. Одні значення припустимі в публічному тексті, інші слід отримувати лише після автентифікації. В одному списку перевіряйте шлях передавання значень і обсяг показу на екрані.
Запит серверного острова має окремий контекст виконання. Якщо логіці потрібна адреса поточної сторінки, розгляньте явне передавання потрібного шляху з початкової сторінки. Припущення, що URL запиту всередині острова є URL початкової сторінки товару, може створити хибні рекомендації для сторінки або посилання повернення. Під час реалізації безпечніше перевірити справжні адреси запитів в інструментах розробника.
Уявімо випадок із номером книжки та ідентифікаційними даними користувача. Номер використовується для спільних рекомендацій, а дані користувача обробляються на сервері відповідно до стану автентифікації. Навіть зашифрований формат передавання не замінює серверну перевірку прав. Окремо задокументуйте місце приймання вводу й місце остаточного рішення про доступ.
4. Обирати кешування за аудиторією відповіді
До спільного опису книжки й особистої адреси важко застосувати одну політику кешу. Посібник MDN з HTTP-кешування пояснює різницю спільного й приватного кешу. Спершу визначте, кому можна показувати відповідь, а не чи однакові дані.
Відкрийте ту саму сторінку з двох тестових облікових записів і переконайтеся, що адреса першого не з’являється в другого. Перевірте також повернення назад і оновлення після виходу. Це перевірка спільного результату кеш-сервера, браузера й обробки автентифікації застосунком. Самого читання файлу компонента недостатньо для висновку про безпеку.
Навіть спільним книжковим рекомендаціям потрібен шлях оновлення зі зміною вмісту. Вирішіть, чи припустимі тимчасово застарілі рекомендації, чи зміна адміністратором має відразу їх замінити. Замість фрази «увімкнути кеш» запишіть об’єкт, місце зберігання, допустиму застарілість і умови скасування кешу: колегам буде легше перевірити задум.
5. Спочатку випробувати повільне з’єднання й відмови
Не оцінюйте сторінку за одним відкриттям із нормальним з’єднанням. Затримайте запит адреси, спричиніть його відмову, змініть стан входу й розгляньте кожен екран. Чи можна читати основний текст, чи завантажувальна ділянка продовжує відсувати наступну кнопку, чи можливі дії, що залежать від даних невдалого запиту?
| Умова випробування | Що має розуміти відвідувач |
|---|---|
| Повільний запит адреси | Чого чекати й чи можна читати інше |
| Немає автентифікації | Чи видно запрошення ввійти та спільний опис |
| Відмова запиту | Чи є шлях відновлення замість порожнього екрана |
| Зміна облікового запису | Чи не залишилися дані попереднього користувача |
Якщо кілька островів чекають результатів одне одного, перегляньте спосіб поділу. Запит вартості доставки після адреси, а потім показ оплати можуть створити послідовний ланцюг очікувань. Можливо, краще об’єднати пов’язані дані в одну серверну операцію або запитувати їх за дією користувача. Велика кількість окремих частин сама собою не означає вдалої структури.
6. Порівнювати виграш до й після за однакових умов
Окремо запишіть час появи першого тексту, завершення показу адреси, доступності дій і стани помилок. Навіть якщо початковий документ видно швидше, значний зсув картки або затримка початку оплати можуть інакше змінити досвід. Крім середнього значення, зафіксуйте, чого довелося чекати в повільних випадках.
Що конкретніше питання відбору острова, то краще. «Чи можна спочатку читати про книжку, навіть якщо ці дані запізняться?» корисніше для рішення, ніж «Цей сайт статичний?». Разом із посібником Astro з рендерингу на вимогу перевірте середовище розгортання та почніть із однієї невеликої персональної ділянки, випробувавши й реальні відмови.