เวลาคนอ่านจบบทหนึ่งแล้วกดเรื่องถัดไป สิ่งที่เกิดขึ้นหลังคลิกอาจเป็นได้ทั้งการเริ่มโหลดทุกอย่างใหม่ หรือการใช้ข้อมูลบางส่วนที่เว็บเตรียมไว้แล้ว แม้สุดท้ายจะเห็นบทความเดียวกัน จังหวะระหว่างทางก็ทำให้รู้สึกต่างกันได้
Prefetch เข้ามาช่วยโดยเตรียมสิ่งที่คาดว่าจะใช้ก่อนกด แต่ก็มีงานที่อาจโหลดมาแล้วไม่ได้ใช้ด้วยครับ ยิ่งหน้ารายการมีลิงก์มาก เราจึงควรถามทั้งว่าคนอ่านรอน้อยลงตรงไหน และก่อนกดเว็บได้ทำอะไรเพิ่มไปบ้าง
ส่วนการแยกข้อมูลไปเรียกผ่าน API ก็ต้องอยู่ในภาพเดียวกัน เพราะเตรียมเส้นทางหน้าไว้แล้วไม่ได้แปลว่าข้อมูลทุกแหล่งที่หน้านั้นเรียกเองจะพร้อมตามไปทั้งหมด
หน้าเว็บหนึ่งอาจมี layout ที่ใช้ร่วมกัน โค้ดของเส้นทาง และข้อมูลบทความที่เปลี่ยนตาม URL การเปลี่ยนหน้าภายในแอปสามารถรักษาบางส่วนไว้แล้วเปลี่ยนเฉพาะสิ่งที่จำเป็น จึงต่างจากการโหลดเอกสารใหม่ทั้งหน้า
แต่สิ่งที่ถูกเตรียมไว้ขึ้นกับ framework รูปแบบ route และวิธีดึงข้อมูล ตัวอย่างใน Next.js App Router มีการ prefetch ที่ทำงานร่วมกับ Link ส่วนขอบเขตของสิ่งที่โหลดล่วงหน้าอาจต่างกันระหว่าง route และการตั้งค่า
หาก component เรียก API เองหลังเริ่มทำงาน คำขอนั้นอาจอยู่นอกสิ่งที่ route prefetch เตรียมให้ ต้องตรวจ Network จริงว่าข้อมูลเริ่มก่อนหรือหลังคลิก ไม่ถือว่ามีคำว่า prefetch อยู่ในโค้ดแล้วทุกขั้นต้องหายจากเวลารอ
เรื่องนี้ทำให้การเปรียบเทียบควรแยกชื่อสิ่งที่เตรียม เช่น เตรียม route payload หรือเตรียมข้อมูลบทความ อย่าใช้คำว่าโหลดหน้าไว้แล้วโดยไม่รู้ว่ารอบที่กำลังวัดยังต้องรอส่วนใดเพิ่ม
ลิงก์บทถัดไปที่เห็นชัดกับลิงก์ทั้งหมดในคลังเนื้อหาอาจมีโอกาสถูกกดต่างกัน การโหลดล่วงหน้าจึงควรสัมพันธ์กับโอกาสใช้และต้นทุนของหน้า ไม่ใช่เปิดทุกอย่างให้เท่ากันเพียงเพราะทำได้
สำหรับ Next.js สามารถปรับนโยบายผ่านความสามารถของ Link ตามรุ่นที่ใช้ เช่น ปิด prefetch ในตำแหน่งที่ไม่ต้องการ แล้วเลือกเตรียมเส้นทางที่มีสัญญาณการใช้งานชัดขึ้น แต่ต้องดูพฤติกรรมทั้งเมาส์ คีย์บอร์ด และจอสัมผัส ไม่ใช้ hover เป็นเงื่อนไขเดียวจนผู้ใช้บางกลุ่มไม่ได้ประโยชน์
คำขอที่เตรียมไว้ใช้เครือข่ายและทรัพยากรของผู้ใช้ร่วมกับงานที่กำลังอ่านอยู่ ถ้ามันไปแย่งภาพหรือข้อมูลสำคัญของหน้าปัจจุบัน เราอาจทำให้เรื่องถัดไปพร้อมขึ้นด้วยการทำให้เรื่องตรงหน้าช้าลง จึงควรดูภาพรวมคำขอในจังหวะเดียวกันด้วย
หากลิงก์จำนวนมากมองเห็นพร้อมกัน ให้ตรวจว่ามีคำขอเพิ่มกี่ชุดและมีข้อมูลใดซ้ำ ไม่ใช้เพียงเวลาหลังคลิกที่ดีขึ้นเป็นหลักฐานว่าต้นทุนรวมลดลง เพราะงานอาจถูกย้ายไปเกิดก่อนคลิกเท่านั้น
สำหรับบทความที่ไม่ค่อยเปลี่ยน การเก็บข้อมูลใช้ซ้ำอาจเหมาะสม แต่เมื่อแก้เนื้อหาแล้วต้องรู้ว่าคนอ่านจะได้ฉบับใหม่เมื่อไร มีอายุแคชหรือวิธีล้างอย่างไร ไม่ปล่อยให้การเปลี่ยนหน้ารวดเร็วแต่หยิบข้อมูลเก่าโดยไม่มีขอบเขตที่ตั้งใจไว้
ถ้าเก็บข้อมูล API ฝั่ง client เอง ควรมี key ที่แยกสิ่งที่มีผลต่อข้อมูล เช่น slug และขอบเขตสิทธิ์ตามระบบ อย่าใช้ cache ร่วมแบบกว้างจนข้อมูลของคนหนึ่งหรือบริบทหนึ่งถูกนำไปแสดงผิดที่
งาน prefetch ควรเป็นการอ่านที่ไม่มีผลเปลี่ยนสถานะ การเตรียมเส้นทางก่อนกดไม่ควรทำให้ธุรกรรมหรือคำสั่งสำคัญเกิดขึ้นเอง ส่วนการแสดงผลว่าคนเข้าอ่านก็ควรคิดความหมายแยกจากเพียงมีคำขอข้อมูลถูกส่งล่วงหน้า
กรณีข้อมูลเตรียมไว้หมดอายุหรือคำขอล้มเหลว ต้องมีเส้นทางโหลดตามปกติและ feedback ที่เข้าใจได้ เพราะเราไม่สามารถรับรองว่าทุกคนจะหยุดอยู่หน้ารายการนานพอให้การเตรียมจบก่อนคลิก
การแสดงโครงหน้าหรือ loading state ที่สัมพันธ์กับสิ่งที่จะมา ช่วยให้คนรู้ว่าระบบรับการเปลี่ยนหน้าแล้ว แต่ยังต้องแยกเวลาที่เห็นโครงกับเวลาที่เริ่มอ่านเนื้อหาจริง หากวัดเพียงจังหวะแรกก็อาจมองไม่เห็นช่วงรอ API ที่ย้ายมาหลังจากนั้น
ควรดูการยกเลิกด้วย เช่น คนกดอีกเรื่องก่อนคำขอเดิมจบ ผลของรอบเก่าต้องไม่มาทับเนื้อหาปัจจุบัน การแสดง error กับปุ่มลองใหม่ก็ควรอ้างถึงหน้าที่กำลังอ่านอยู่ ไม่ใช่หน้าที่ถูกกดผ่านไปแล้ว
สำหรับประสบการณ์ย้อนกลับ ให้ตรวจตำแหน่งการเลื่อนกับสถานะรายการร่วมด้วย เพราะการเปลี่ยนหน้าเร็วไม่ได้ช่วยทั้งหมดถ้าคนกลับมาแล้วต้องเลื่อนหาตำแหน่งเดิมใหม่ทุกครั้ง สิ่งที่รักษาไว้ควรสัมพันธ์กับพฤติกรรมของหน้าจริง
การทดลองควรมีอย่างน้อยสถานการณ์เปิด URL จากภายนอก เปลี่ยนหน้าหลังอยู่ในรายการ และกดก่อนการเตรียมจบ โดยกำหนดเวลารอและสถานะแคชให้ชัด จะช่วยให้เห็นว่ากลยุทธ์นี้ช่วยเส้นทางใดและยังเหลือ fallback ส่วนไหน
เก็บเวลาเห็น feedback เวลาเนื้อหาที่ต้องการพร้อม และคำขอที่เกิดก่อนกับหลังคลิกแยกกัน รวมถึงดูหน้าที่ไม่ได้ถูกเลือกเพื่อประเมินงานที่เตรียมแล้วไม่ใช้ การนับเพียงเวลาหลังคลิกทำให้เรื่องต้นทุนหายไปจากรายงานได้ง่าย
ควรตรวจด้วย build กับโหมดที่แทนการใช้งานจริง เพราะพฤติกรรม prefetch และงานเสริมใน development อาจต่างจาก production ภาพในบทนี้เป็นขอบเขตแนวคิด ไม่มีผลเปรียบเทียบของสองโปรไฟล์ในเว็บนี้ จึงยังไม่ใช้ยืนยันว่าทางใดเร็วกว่าก่อนวัดจริง
หากลิงก์ชี้ไปงานที่ต้องยืนยันตัวตน ให้ตรวจการหมดอายุสิทธิ์ด้วย คำตอบที่เตรียมไว้ก่อนหน้าไม่ควรถูกใช้ข้ามการเปลี่ยนบัญชีหรือสถานะออกจากระบบ และหน้าควรกลับไปโหลดตามสิทธิ์ปัจจุบันได้อย่างชัดเจน
Prefetch ช่วยลดสิ่งที่ต้องเริ่มหลังคลิกเมื่อเตรียมส่วนที่เกี่ยวข้องได้ทัน แต่ต้องรู้ว่ามันเตรียม route หรือข้อมูลใด และเพิ่มงานที่อาจไม่ได้ใช้เท่าไร เมื่อวางเรื่องแคช ความสด และ fallback คู่กับการวัดทั้งก่อนและหลังคลิก เราจะเลือกความเร็วในการเปลี่ยนหน้าที่เหมาะกับต้นทุนของเว็บ โดยยังรักษาความถูกต้องของเนื้อหาที่คนอ่านได้รับครับ