สิ่งที่ควรและไม่ควรทำล่วงหน้า

เอกสารประกอบนี้ได้กล่าวถึงการแคชล่วงหน้าไว้ก่อนหน้านี้ แต่ยังมีข้อมูลไม่เพียงพอที่จะทำได้อย่างถูกต้อง ซึ่งเป็นสิ่งสำคัญ เนื่องจากไม่ว่าคุณจะใช้ Workbox หรือไม่ การแคชล่วงหน้ามากเกินไปอาจทำให้สิ้นเปลืองอินเทอร์เน็ตมือถือและแบนด์วิดท์ได้ คุณควรระมัดระวังว่าเพย์โหลดการแคชล่วงหน้าจะส่งผลต่อประสบการณ์ของผู้ใช้อย่างไร

เมื่ออ่านเอกสารนี้ โปรดเข้าใจว่านี่เป็นหลักเกณฑ์ทั่วไป สถาปัตยกรรมและข้อกำหนดของแอปพลิเคชันอาจกำหนดให้คุณต้องดำเนินการบางอย่างที่แตกต่างจากที่แนะนำในที่นี้ แต่หลักเกณฑ์เหล่านี้จะเป็นค่าเริ่มต้นที่ดี

สิ่งที่ควรทำ: แคชเนื้อหาคงที่ที่สำคัญล่วงหน้า

ตัวเลือกที่ดีที่สุดสำหรับการแคชล่วงหน้าคือเนื้อหาคงที่ที่สำคัญ แต่สิ่งใดถือเป็นเนื้อหาที่ "สำคัญ" จากมุมมองของนักพัฒนาซอฟต์แวร์ คุณอาจจะคิดว่าแอปพลิเคชันทั้งแอป "สำคัญ" ก็ได้ แต่มุมมองของผู้ใช้คือสิ่งที่สำคัญที่สุด ให้คิดว่าเนื้อหาที่สำคัญคือส่วนที่สำคัญที่สุดในการมอบประสบการณ์ของผู้ใช้

• สไตล์ชีตส่วนกลาง
• ไฟล์ JavaScript ที่มีฟังก์ชันการทำงานส่วนกลาง
• HTML ของ Application Shell ในสถาปัตยกรรมของคุณ

หมายเหตุ: ข้อมูลเหล่านี้เป็นเพียงหลักเกณฑ์ทั่วไป ไม่ใช่คำแนะนำที่อ่านยาก ขณะแคชเนื้อหาล่วงหน้า วิธีที่ดีที่สุดคือการแคชเนื้อหาล่วงหน้าให้น้อยลงแทนที่จะทำมากกว่าที่คิด

สิ่งที่ควรทำ: แคชล่วงหน้าแบบออฟไลน์สำหรับเว็บไซต์ที่มีหลายหน้า

สำหรับเว็บไซต์ที่มีหลายหน้าโดยทั่วไป คุณอาจกำลังใช้กลยุทธ์การแคชเฉพาะเครือข่ายหรือเครือข่ายเท่านั้นเพื่อจัดการคำขอการนำทาง

ในกรณีเช่นนี้ คุณควรตรวจสอบว่าโปรแกรมทำงานของบริการแคชล่วงหน้าและตอบสนองด้วยหน้าสำรองแบบออฟไลน์เมื่อผู้ใช้ส่งคำขอการนำทางขณะออฟไลน์ วิธีหนึ่งที่จะทำได้ใน Workbox คือการใช้กลยุทธ์เฉพาะเครือข่ายเท่านั้นกับวิดีโอสำรองแบบออฟไลน์ โดยใช้ประโยชน์จากการโหลดการนำทางล่วงหน้าด้วย ดังนี้

import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';

navigationPreload.enable();

// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);

// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
  return request.mode === 'navigate';
}, new NetworkOnly({
  plugins: [
    new PrecacheFallbackPlugin({
      fallbackURL: '/offline.html'
    })
  ]
}));

registerRoute(networkOnlyNavigationRoute);

วิธีนี้ช่วยให้มั่นใจว่าหากผู้ใช้ออฟไลน์และไปยังหน้าเว็บที่ไม่ได้อยู่ในแคช อย่างน้อยผู้ใช้จะได้รับเนื้อหาออฟไลน์

เป็นไปได้ไหม: ลองใช้การแคชล่วงหน้าที่ไม่แน่นอน

ถึงแม้ว่าตัวเลขอาจมีความ "อาจ" อยู่บ้าง แต่ก็ให้ประโยชน์ที่อาจเกิดขึ้นในการแคชเนื้อหาล่วงหน้าซึ่งใช้ในสถานการณ์บางอย่างเท่านั้น ลองคิดในลักษณะนี้: ผู้ใช้จะต้องมีการดาวน์โหลดข้อมูลล่วงหน้าบางส่วน ซึ่งมีประโยชน์ที่ไม่น่าพอใจคือช่วยให้มีคำขอสำหรับเนื้อหาเหล่านั้นได้เร็วขึ้นในอนาคต

สำหรับคำเตือนสำคัญก็คือ ให้ระมัดระวังมากหากคุณตัดสินใจที่จะทำ คุณอาจสิ้นเปลืองข้อมูลเมื่อทำเช่นนี้และควรเป็นการตัดสินใจจากข้อมูล นอกจากนี้ โปรดหลีกเลี่ยงการแคชเนื้อหาล่วงหน้าซึ่งมีการเปลี่ยนแปลงบ่อย เนื่องจากผู้ใช้จะมีการใช้ข้อมูลเพิ่มเติมทุกครั้งที่โค้ดการแคชล่วงหน้าตรวจพบการแก้ไขใหม่ สังเกตกระแสของผู้ใช้ใน Analytics เพื่อดูว่าผู้ใช้มักจะไปที่ไหน หากคุณมีข้อสงสัยเกี่ยวกับการแคชเนื้อหาล่วงหน้าไว้ก่อน เนื้อหาดังกล่าวก็น่าจะเป็นสัญญาณที่ดีที่ไม่ควรทำเช่นนั้น

อาจไม่เหมาะ: แคช HTML แบบคงที่ล่วงหน้า

หลักเกณฑ์นี้มีผลบังคับใช้กับเว็บไซต์แบบคงที่ ซึ่งมีการสร้างไฟล์ HTML ที่แยกกันต่างหากโดยเครื่องมือสร้างเว็บไซต์แบบคงที่หรือสร้างขึ้นด้วยตนเอง แทนที่จะสร้างขึ้นแบบไดนามิกหรือจัดเตรียมโดยระบบแบ็คเอนด์ของแอปพลิเคชัน หากสิ่งนี้อธิบายสถาปัตยกรรมของคุณ ก็น่าจะดีที่สุดหากคุณไม่แคชไฟล์ HTML ทุกไฟล์สำหรับเว็บไซต์ไว้ล่วงหน้า

ปัญหาหนึ่งในการแคชไฟล์ HTML ทั้งเว็บไซต์ล่วงหน้าก็คือ มาร์กอัปที่ได้รับแคชล่วงหน้าตอนนี้จะแสดงจากแคชในภายหลังเสมอจนกว่าจะมีการอัปเดต Service Worker การทำเช่นนี้เหมาะกับประสิทธิภาพการทำงาน แต่อาจนำไปสู่การเลิกใช้งานแคชจำนวนมากหาก HTML ของเว็บไซต์มีการเปลี่ยนแปลงบ่อยครั้ง

กฎนี้มีข้อยกเว้น 2 ข้อ หากคุณกำลังปรับใช้เว็บไซต์ขนาดเล็กที่มีไฟล์ HTML แบบคงที่เพียงไม่กี่ไฟล์ อาจเป็นการดีที่จะแคชหน้าเหล่านั้นทั้งหมดไว้ล่วงหน้าเพื่อให้หน้าเหล่านั้นพร้อมใช้งานแบบออฟไลน์ได้ หากคุณมีเว็บไซต์ขนาดใหญ่เป็นพิเศษ ให้ลองแคชหน้าที่มีคุณค่าสูงไว้บ้างล่วงหน้า 2-3 หน้าและหน้าสำรองแบบออฟไลน์ และใช้การแคชรันไทม์เพื่อแคชหน้าอื่นๆ ให้คุณ

อย่าใช้การแคชรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์หรือไอคอน Fav ไว้ในแคชล่วงหน้า

นี่ไม่ใช่หลักเกณฑ์ทั่วไป แต่เป็นกฎเพิ่มเติม รูปภาพที่ปรับเปลี่ยนตามอุปกรณ์เป็นวิธีแก้ปัญหาที่ซับซ้อนเนื่องจากปัญหาที่ซับซ้อน คุณมีผู้ใช้จำนวนมากในอุปกรณ์หลายเครื่อง โดยแต่ละแบบจะมีขนาดหน้าจอ ความหนาแน่นของพิกเซล และการรองรับรูปแบบอื่นๆ แตกต่างกันไป หากคุณแคชรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ทั้งชุดไว้ล่วงหน้า จะเป็นการแคชรูปภาพหลายรูปไว้ล่วงหน้าเมื่อผู้ใช้ดาวน์โหลดรูปภาพเหล่านั้นเพียงรูปเดียว

ไอคอน Fav ก็มีสถานการณ์ที่คล้ายกัน โดยเว็บไซต์มักจะใช้ไอคอน Fav ทั้งชุดสำหรับสถานการณ์ที่แตกต่างกัน โดยส่วนใหญ่จะมีการขอไอคอน Fav เพียงรายการเดียว ซึ่งทำให้การแคชไอคอน Fav ทั้งชุดล่วงหน้าเป็นเรื่องที่สูญเปล่า

ผู้ใช้ชื่นชอบสิ่งที่คุณชอบและอย่าแคชชุดรูปภาพและไอคอน Fav ที่ปรับเปลี่ยนตามอุปกรณ์ไว้ล่วงหน้า อาศัยการแคชรันไทม์แทน หากคุณต้องแคชรูปภาพล่วงหน้า ให้แคชรูปภาพที่ใช้กันอย่างแพร่หลายล่วงหน้าซึ่งไม่ได้เป็นส่วนหนึ่งของชุดรูปภาพที่ปรับเปลี่ยนตามอุปกรณ์หรือไอคอน Fav SVG มีความเสี่ยงน้อยกว่าในแง่ของการใช้ข้อมูล เนื่องจาก SVG แต่ละไฟล์จะแสดงผลได้อย่างดีที่สุดโดยไม่คำนึงถึงความหนาแน่นพิกเซลของหน้าจอหนึ่งๆ

ไม่ใช้: โพลีฟิลล์ล่วงหน้า

การรองรับ API ต่างๆ ในเบราว์เซอร์เป็นความท้าทายของนักพัฒนาเว็บ และการสร้าง Polyfill ก็เป็นหนึ่งในวิธีที่ได้ผลกับปัญหานี้ วิธีหนึ่งในการลดค่าใช้จ่ายด้านประสิทธิภาพของ Polyfill คือการตรวจสอบฟีเจอร์และโหลดเฉพาะ Polyfill สำหรับเบราว์เซอร์ที่จำเป็นต้องใช้ Polyfill เท่านั้น

เนื่องจากการโหลด Polyfill แบบมีเงื่อนไขจะเกิดขึ้นระหว่างรันไทม์ตามสภาพแวดล้อมปัจจุบัน การแคช Polyfill ไว้ล่วงหน้าจึงเป็นการพนัน ผู้ใช้บางคนจะได้ประโยชน์ แต่บางคนก็จะสิ้นเปลืองแบนด์วิดท์ไปกับโพลีฟิลล์ที่ไม่จำเป็น

อย่าแคชโพลีฟิลล์ล่วงหน้า ใช้การแคชรันไทม์เพื่อให้แน่ใจว่าจะมีการแคชในเบราว์เซอร์ที่จำเป็นต้องใช้เท่านั้นเพื่อหลีกเลี่ยงการสูญเสียข้อมูล

บทสรุป

การแคชล่วงหน้าต้องการเนื้อหาที่ผู้ใช้ต้องการล่วงหน้าไว้ล่วงหน้า แต่แน่นอนว่าคุณสามารถทำให้ได้ถูกต้องโดยให้ความสำคัญกับประสิทธิภาพและความน่าเชื่อถือในอนาคต

หากไม่แน่ใจว่าควรจัดเก็บเนื้อหาบางรายการไว้ในแคชล่วงหน้าหรือไม่ คุณควรแจ้งให้ Workbox ยกเว้นเนื้อหาเหล่านั้น และสร้างเส้นทางการแคชรันไทม์เพื่อจัดการเนื้อหาเหล่านั้น ไม่ว่าจะเป็นลักษณะใดก็ตาม เราจะพูดถึงรายละเอียดเกี่ยวกับการแคชล่วงหน้าในเอกสารประกอบนี้ เพื่อให้คุณนำหลักการเหล่านี้ไปใช้กับตรรกะการแคชล่วงหน้าได้ในอนาคต