คำอธิบายสินค้าเหมือนทุกคน แต่ที่อยู่ส่งของที่แสดงให้ผู้เข้าใช้ระบบอาจต่าง ถ้าค้นที่อยู่ช้า ต้องให้คำอธิบายสินค้ารอด้วยไหม บทนี้ใช้หน้าขายหนังสือสมมุติเพื่อดูกระบวนการแยกเนื้อหาร่วมกับพื้นที่ผู้ใช้เฉพาะ ฟังก์ชันคือ server island ของ Astro ต่างบทบาท client island ที่ทำปุ่มทำงานในเบราว์เซอร์
1. แยกเอกสารเริ่มจากพื้นที่มาทีหลัง
เอกสาร server island ทางการ Astro อธิบายหน่วงเรนเดอร์เซิร์ฟเวอร์ของ component เฉพาะ แล้วรับผลด้วยคำขอแยก HTML เริ่มใส่เนื้อหาหลักกับสิ่งแสดงตอนรอ เมื่อคำตอบแยกมาค่อยแทนพื้นที่ ต้องมี adapter จัดคำขอบนเซิร์ฟเวอร์
หน้าหนังสือให้ชื่อ ผู้เขียน บทนำอยู่เอกสารร่วม เลือกเฉพาะสรุปที่อยู่เป็นตัวเลือก คนยังอ่านหนังสืออะไรได้ระหว่างรอ แต่ถ้าต้องยอดรวมจึงเข้าใจปุ่มจ่าย ต้องออกแบบสัมพันธ์ราคากับการจ่ายด้วย แบ่งสิ่งเห็นเป็นกล่องเล็กไม่ใช่จบแยกฟังก์ชัน
การแสดงอะไรก่อนกำหนดสำเร็จ หากเนื้อหาแทบว่างและหน่วงส่วนใหญ่ คนต้องรอสัญลักษณ์โหลดหลายอัน แยกรายการคำถามหน้าต้นต้องตอบกับข้อมูลช้าได้ก่อน Server island ย้ายตำแหน่งรอ ไม่ใช่ทำฐานข้อมูลเร็วเอง
2. ออกแบบ fallback เป็นส่วนของหน้าจอสมบูรณ์
ตัวอย่างเล็กต่อไปแสดงรูปใช้ สมมุติ component UserDelivery กับ adapter ทำไว้แยกแล้ว
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">กำลังตรวจสอบข้อมูลที่อยู่จัดส่ง</p>
</UserDelivery>fallback ไม่ใช่ของแต่งแวบหาย แต่เป็นเนื้อหาแรกผู้ใช้ได้อ่าน จองที่ใกล้ขนาดการ์ดที่อยู่สุดท้ายและบอกว่ารออะไร ยังไม่รู้แต่เขียน “จัดส่งได้” ก่อนอาจขัดความหมายตอบจริง ต้องแยกสถานะไม่ทราบกับผลยืนยันทางภาพด้วย
เช่น คนยังไม่เข้าสู่ระบบอาจต้อง “เข้าสู่ระบบเพื่อดูที่อยู่ที่บันทึกไว้” เน็ตช้ากับยังไม่เข้าระบบต่างกัน ตั้งข้อความเส้นทางแยกช่วยลดคำชั่วคราวเพื่อสะดวกตอนพัฒนาค้างในหน้าจอจริง
3. รักษาขอบเขตข้อมูลเล็ก
เรียก component ส่งเพียงค่าที่แสดงและค้นจำเป็น หากส่งประวัติสั่งทั้งหมดแล้วพิมพ์ชื่อเดียว มีโอกาสลดการพึ่งข้อมูลก่อน บางค่าอยู่สาธารณะได้ บางค่าควรค้นหลังยืนยันผู้ใช้ ตรวจทางส่งกับขอบเขตแสดงในรายการเดียว
คำขอ server island อยู่บริบททำงานแยก ถ้าตรรกะต้อง URL หน้าปัจจุบัน พิจารณาส่ง path ชัดจากหน้าเดิม สมมุติ URL คำขอใน island เป็นหน้าสินค้าต้นอาจทำคำแนะนำรายหน้าหรือ link กลับผิด ตอนทำควรดู URL คำขอจริงในเครื่องมือนักพัฒนา
คิดกรณีสมมุติรหัสหนังสือกับข้อมูลระบุคน แยกบทบาทรหัสค้นคำแนะนำร่วม ส่วนคนจัดบนเซิร์ฟเวอร์ตามยืนยัน แม้รูปส่งเข้ารหัสก็ไม่แทนตรวจสิทธิ์เซิร์ฟเวอร์ จดแยกตำแหน่งรับ input กับตำแหน่งตัดสินอนุญาตปลาย
4. กำหนด cache ตามผู้รับหน้าจอ
บทนำหนังสือร่วมกับที่อยู่คนใช้ cache เดียวกันยาก คู่มือ HTTP cache ของ MDN แยก cache ร่วมกับส่วนบุคคล คิดก่อนว่าคำตอบใครเห็นได้ ไม่ใช่เพียงข้อมูลเหมือน
เปิดหน้าเดียวด้วยสองบัญชีทดสอบ ตรวจที่อยู่คนแรกไม่ปรากฏคนสอง ดูด้วยหลังออกจากระบบแล้วย้อนหรือโหลดใหม่ ตรวจนี้เป็นผลทำงานร่วมของ cache server เบราว์เซอร์และยืนยันแอป ไม่อ่านไฟล์ component แล้วสรุปปลอดภัยได้
แม้ส่วนร่วมเช่นแนะนำหนังสือยังต้องทางอัปเดตเมื่อเนื้อหาเปลี่ยน เลือกยอมเก่าชั่วคราวหรือแอดมินแก้แล้วเปลี่ยนทันที แทนประโยค “เปิด cache” ให้จดเป้าหมาย ที่เก็บ ความเก่ายอมได้ เงื่อนไขล้าง เพื่อคนอื่นตรวจแบบง่าย
5. ทดสอบช้าและล้มเหลวก่อน
ไม่ประเมินจากเปิดครั้งเดียวเน็ตปกติ ทำคำขอที่อยู่ช้า ล้มและเปลี่ยนล็อกอิน ดูแต่ละหน้า เนื้อหาหลักอ่านได้ไหม พื้นที่โหลดผลักปุ่มต่อเรื่อยไหม การกระทำอาศัยข้อมูลล้มทำได้ไหม
| สถานการณ์ทดสอบ | สถานะผู้เข้าชมต้องเข้าใจ |
|---|---|
| ค้นที่อยู่ช้า | รออะไร อ่านอื่นระหว่างได้ไหม |
| ยังไม่ยืนยัน | เห็นคำให้เข้าระบบกับอธิบายร่วมไหม |
| ค้นล้มเหลว | หาทางกู้คืนแทนหน้าว่างได้ไหม |
| เปลี่ยนบัญชี | ข้อมูลคนก่อนค้างหรือไม่ |
หลาย island รอผลกันต้องทบทวนการแยก ได้ที่อยู่ค่อยค้นค่าส่งค่อยวาดคำจ่ายอาจต่อคิวรอ ตอนนี้อาจดีกว่ารวมข้อมูลสัมพันธ์งานเซิร์ฟเวอร์เดียว หรือค้นเมื่อผู้ใช้เรียก แยกมากไม่ได้เป็นโครงดีเอง
6. เทียบผลก่อนหลังภายใต้เงื่อนไขเดียว
บันทึกแยกเมื่อเนื้อหาต้นเห็น ที่อยู่ครบ ทำงานได้และข้อผิดพลาด แม้เอกสารต้นเร็วแต่การ์ดย้ายมากหรือจ่ายช้าประสบการณ์อาจเปลี่ยนอีกทาง อย่ามีแต่ค่าเฉลี่ย บันทึกกรณีช้าว่ารออะไรด้วย
ถามเลือก server island ยิ่งเฉพาะยิ่งช่วย “ข้อมูลนี้ช้าแต่คนอ่านแนะนำหนังสือก่อนได้ไหม” ช่วยตัดสินกว่าถาม “เว็บไซต์นี้คงที่ไหม” ดูแวดล้อมปล่อยงานกับ คู่มือเรนเดอร์เมื่อร้องขอ Astro แล้วตรวจพื้นที่เฉพาะผู้ใช้เล็กหนึ่งจนถึงความล้มเหลวจริง