ความท้าทายและวิธีแก้ปัญหาเบื้องต้นในการสร้าง Progressive Web App ในเว็บไซต์ที่มีหลายต้นทาง
ที่มา
ที่ผ่านมา การใช้สถาปัตยกรรมแบบหลายต้นทางมีข้อดีอยู่บ้าง แต่สำหรับ Progressive Web App วิธีนี้สร้างปัญหาได้มากกว่า โดยเฉพาะอย่างยิ่งนโยบายต้นทางเดียวกันซึ่งกำหนดข้อจำกัดในการแชร์สิ่งต่างๆ เช่น โปรแกรมทำงานของบริการและแคช สิทธิ์ และเพื่อให้ได้ประสบการณ์การใช้งานแบบสแตนด์อโลนในหลายๆ ต้นทาง บทความนี้จะอธิบายถึงการใช้งานหลายต้นทางที่ดีและไม่ดี รวมทั้งอธิบายความท้าทายและวิธีแก้ปัญหาชั่วคราวในการสร้าง Progressive Web App ในเว็บไซต์ที่มีหลายต้นทาง
การใช้หลายต้นทางที่ดีและไม่ดี
มีเหตุผลที่ถูกต้องบางประการที่เว็บไซต์ต้องใช้สถาปัตยกรรมแบบหลายต้นทาง ซึ่งส่วนใหญ่เกี่ยวข้องกับการให้บริการเว็บแอปพลิเคชันชุดอิสระ หรือเพื่อสร้างประสบการณ์ที่แยกออกจากกันโดยสิ้นเชิง นอกจากนี้ยังมีการใช้งานที่ควรหลีกเลี่ยงด้วย
ดี
เรามาดูเหตุผลที่มีประโยชน์กันก่อน
การแปล / ภาษา: ใช้โดเมนระดับบนสุดตามรหัสประเทศเพื่อแยกเว็บไซต์ไปแสดงในประเทศต่างๆ (เช่น
https://www.google.com.ar
) หรือใช้โดเมนย่อยเพื่อแบ่งเว็บไซต์ที่กำหนดเป้าหมายไปยังสถานที่ตั้งที่แตกต่างกัน (เช่นhttps://newyork.craigslist.org
) หรือเพื่อนำเสนอเนื้อหาสำหรับภาษาใดภาษาหนึ่ง (เช่นhttps://en.wikipedia.org
)เว็บแอปอิสระ: การใช้โดเมนย่อยต่างๆ เพื่อมอบประสบการณ์การใช้งานที่มีวัตถุประสงค์แตกต่างจากเว็บไซต์ในต้นทางหลักอย่างมาก เช่น ในเว็บไซต์ข่าว อาจตั้งใจให้บริการเว็บแอปครอสเวิร์ดจาก
https://crosswords.example.com
รวมถึงติดตั้งและใช้เป็น PWA อิสระโดยไม่ต้องแชร์ทรัพยากรหรือฟังก์ชันการทำงานใดๆ กับเว็บไซต์หลัก
ไม่ดี
หากคุณไม่ทำตามขั้นตอนเหล่านี้เลย ก็มีแนวโน้มว่าการใช้สถาปัตยกรรมแบบหลายต้นทางจะมีข้อเสียเมื่อสร้าง Progressive Web App
แต่ถึงกระนั้น เว็บไซต์จำนวนมากก็ยังคงได้รับการจัดโครงสร้างแบบนี้ต่อไปโดยไม่มีเหตุผลเฉพาะเจาะจง หรือด้วยเหตุผล "แบบเดิม" ตัวอย่างหนึ่งคือการใช้โดเมนย่อยเพื่อแยกส่วนต่างๆ ของเว็บไซต์ตามอำเภอใจ ซึ่งควรเป็นส่วนหนึ่งของประสบการณ์ที่เป็นหนึ่งเดียว
เราขอแนะนำให้คุณใช้รูปแบบต่อไปนี้
ส่วนของเว็บไซต์: การแยกส่วนต่างๆ ของเว็บไซต์ในโดเมนย่อย คุณเห็นหน้าแรกที่
https://www.example.com
ในเว็บไซต์ข่าว ส่วนข่าวกีฬาแบ่งเป็นhttps://sports.example.com
การเมืองที่https://politics.example.com
เป็นต้น ในกรณีของเว็บไซต์อีคอมเมิร์ซ การใช้แท็ก เช่นhttps://category.example.com
สำหรับหมวดหมู่ผลิตภัณฑ์ และhttps://product.example.com
สำหรับหน้าผลิตภัณฑ์ เป็นต้นเส้นทางของผู้ใช้: อีกแนวทางหนึ่งที่ไม่แนะนำคือการแยกส่วนย่อยต่างๆ ของเว็บไซต์ เช่น หน้าเว็บสำหรับขั้นตอนการเข้าสู่ระบบหรือขั้นตอนการซื้อในโดเมนย่อย เช่น กำลังใช้
https://login.example.com
และhttps://checkout.example.com
สําหรับกรณีที่ไม่สามารถย้ายข้อมูลไปยังต้นทางเดียวได้ ขั้นตอนถัดไปคือรายการความท้าทายและ (หากเป็นไปได้) วิธีแก้ปัญหาเบื้องต้นซึ่งควรพิจารณาเมื่อสร้าง Progressive Web App
ความท้าทายและวิธีแก้ปัญหาสำหรับ PWA ในต้นทางต่างๆ
เมื่อสร้างเว็บไซต์บนต้นทางหลายแห่ง การมอบประสบการณ์การใช้งาน PWA แบบครบวงจรนั้นเป็นเรื่องที่ท้าทาย ซึ่งส่วนใหญ่เนื่องมาจากนโยบายต้นทางเดียวกันซึ่งมีข้อจำกัดหลายประการ เรามาดูกันทีละรายการ
Service Worker
ต้นทางของ URL สคริปต์ Service Worker ต้องเหมือนกับต้นทางของหน้าเว็บที่เรียกใช้ register() ซึ่งหมายความว่า ตัวอย่างเช่น หน้าเว็บที่ https://www.example.com
จะเรียกใช้ register()
ด้วย URL ของ Service Worker ที่ https://section.example.com
ไม่ได้
อีกข้อหนึ่งคือ Service Worker จะควบคุมได้เฉพาะหน้าเว็บที่โฮสต์ภายใต้ต้นทางและเส้นทางที่อยู่ในต้นทางเท่านั้น ซึ่งหมายความว่าหาก Service Worker โฮสต์อยู่ที่ https://www.example.com
ก็จะควบคุมได้เฉพาะ URL จากต้นทางนั้น (ตามเส้นทางที่กำหนดไว้ในพารามิเตอร์ขอบเขต) แต่จะไม่ควบคุมหน้าเว็บในโดเมนย่อยอื่นๆ เช่น หน้าที่อยู่ใน https://section.example.com
ในกรณีนี้ วิธีแก้ปัญหาวิธีเดียวคือการใช้ Service Worker หลายตัว (1 รายการต่อต้นทาง)
การแคช
ออบเจ็กต์ Cache,IndexDB และ localStorage ยังถูกจำกัดไว้ที่ต้นทางเดียวด้วย ซึ่งหมายความว่าคุณจะเข้าถึงแคชที่เป็นของ https://www.example.com
ไม่ได้ เช่น https://www.section.example.com
ต่อไปนี้เป็นสิ่งที่คุณทำได้เพื่อจัดการแคชอย่างเหมาะสมในสถานการณ์เช่นนี้
ใช้ประโยชน์จากการแคชเบราว์เซอร์: เราแนะนำให้ใช้แนวทางปฏิบัติแนะนำในการแคชเบราว์เซอร์แบบดั้งเดิมเสมอ เทคนิคนี้จะให้ประโยชน์เพิ่มเติมในการใช้ทรัพยากรที่แคชไว้ซ้ำข้ามต้นทาง ซึ่งทำด้วยแคชของ Service Worker ไม่ได้ โปรดอ่านโพสต์นี้เพื่อดูแนวทางปฏิบัติแนะนำเกี่ยวกับวิธีใช้แคช HTTP กับ Service Worker
ทำให้การติดตั้ง Service Worker มีค่าใช้จ่ายน้อย: หากคุณบำรุงรักษา Service Worker หลายตัว ก็อย่าทำให้ผู้ใช้ต้องเสียค่าใช้จ่ายในการติดตั้งจำนวนมากทุกครั้งที่ไปยังต้นทางใหม่ กล่าวอีกนัยหนึ่งคือ แคชล่วงหน้าสำหรับทรัพยากรที่จำเป็นจริงๆ เท่านั้น
สิทธิ์
สิทธิ์ต่างๆ จะกำหนดขอบเขตไว้ที่ต้นทางด้วย ซึ่งหมายความว่าหากผู้ใช้ให้สิทธิ์กับต้นทาง https://section.example.com
ไว้ ระบบจะไม่ส่งต่อสิทธิ์ดังกล่าวไปยังต้นทางอื่นๆ เช่น https://www.example.com
เนื่องจากไม่สามารถแชร์สิทธิ์ข้ามต้นทางได้ วิธีเดียวที่ทำได้จึงเป็นเพียงการขอสิทธิ์บนโดเมนย่อยแต่ละรายการที่จำเป็นต้องใช้ฟีเจอร์ดังกล่าว (เช่น ตำแหน่ง) สำหรับสิ่งต่างๆ เช่น ข้อความ Push จากเว็บ คุณสามารถเก็บคุกกี้ไว้เพื่อติดตามว่าผู้ใช้ในโดเมนย่อยอื่นยอมรับสิทธิ์หรือไม่ เพื่อหลีกเลี่ยงการขอสิทธิ์อีกครั้ง
การติดตั้ง
หากต้องการติดตั้ง PWA แต่ละต้นทางต้องมีไฟล์ Manifest ของตัวเองที่มี start_url
ซึ่งสัมพันธ์กับตัวเอง ซึ่งหมายความว่าผู้ใช้ที่ได้รับข้อความแจ้งการติดตั้งในต้นทางหนึ่งๆ (เช่น https://section.example.com
) จะติดตั้ง PWA ด้วย start_url
ในต้นทางอื่น (เช่น https://www.example.com
) ไม่ได้
กล่าวคือ ผู้ใช้ที่ได้รับข้อความแจ้งให้ติดตั้งในโดเมนย่อยจะติดตั้ง PWA สำหรับหน้าเว็บย่อยได้เท่านั้น แต่จะติดตั้งสำหรับ URL หลักของแอปไม่ได้
นอกจากนี้ ผู้ใช้รายเดียวกันอาจได้รับข้อความแจ้งการติดตั้งหลายรายการเมื่อไปยังส่วนต่างๆ ของเว็บไซต์ หากโดเมนย่อยแต่ละรายการมีคุณสมบัติตรงตามเกณฑ์การติดตั้ง และแจ้งให้ผู้ใช้ติดตั้ง PWA
คุณลดปัญหานี้ได้ด้วยการตรวจสอบว่าข้อความแจ้งจะแสดงในต้นทางหลักเท่านั้น เมื่อผู้ใช้เข้าชมโดเมนย่อยที่ผ่านเกณฑ์การติดตั้ง:
- ฟังเหตุการณ์
beforeinstallprompt
- ป้องกันไม่ให้ข้อความแจ้งปรากฏขึ้น ให้โทรหา
event.preventDefault()
วิธีนี้ช่วยให้คุณแน่ใจว่าข้อความแจ้งจะไม่แสดงในส่วนที่ไม่ต้องการของเว็บไซต์ ขณะเดียวกันก็ยังแสดงข้อความแจ้งต่อไปได้ เช่น ในต้นทางหลัก (เช่น หน้าแรก)
โหมดสแตนด์อโลน
ขณะไปยังส่วนต่างๆ ในหน้าต่างแบบสแตนด์อโลน เบราว์เซอร์จะทํางานแตกต่างออกไปเมื่อผู้ใช้อยู่นอกขอบเขตที่ไฟล์ Manifest ของ PWA กําหนด การทำงานจะขึ้นอยู่กับเวอร์ชันของเบราว์เซอร์และผู้ให้บริการแต่ละราย ตัวอย่างเช่น Chrome เวอร์ชันล่าสุดจะเปิด Chrome Custom Tab เมื่อผู้ใช้ออกจากขอบเขตในโหมดสแตนด์อโลน
ในกรณีส่วนใหญ่ จะไม่มีวิธีแก้ปัญหานี้ แต่สามารถใช้วิธีแก้ปัญหาชั่วคราวกับประสบการณ์ส่วนเล็กๆ ที่โฮสต์ในโดเมนย่อยได้ (เช่น เวิร์กโฟลว์การเข้าสู่ระบบ) ดังนี้
- URL ใหม่
https://login.example.com
อาจเปิดใน iframe แบบเต็มหน้าจอ - เมื่องานเสร็จสมบูรณ์ใน iframe (เช่น ขั้นตอนการเข้าสู่ระบบ) คุณจะใช้ postMessage() เพื่อส่งข้อมูลที่ได้จาก iframe กลับไปยังหน้าระดับบนสุด
- ในขั้นตอนสุดท้าย เมื่อหน้าหลักได้รับข้อความแล้ว ผู้ฟังจะยกเลิกการลงทะเบียนได้ และ iframe ดังกล่าวก็ถูกนำออกจาก DOM ในที่สุด
บทสรุป
นโยบายต้นทางเดียวกันกำหนดข้อจำกัดมากมายสำหรับเว็บไซต์ที่สร้างขึ้นจากต้นทางหลายรายการที่ต้องการสร้างประสบการณ์การใช้งาน PWA ที่สอดคล้องกัน ด้วยเหตุนี้ เพื่อมอบประสบการณ์ที่ดีที่สุดให้แก่ผู้ใช้ เราจึงไม่แนะนําให้แบ่งเว็บไซต์ออกเป็นต้นทางที่แตกต่างกัน
สําหรับเว็บไซต์ที่มีอยู่ซึ่งสร้างขึ้นในลักษณะนี้แล้ว การทําให้ PWA แบบต้นทางหลายต้นทางทํางานได้อย่างถูกต้องนั้นทำได้ยาก แต่เราได้ศึกษาวิธีแก้ปัญหาที่เป็นไปได้บางส่วนแล้ว แต่ละแบบอาจมีข้อดีและข้อเสีย ดังนั้นจงใช้วิจารณญาณในการตัดสินใจว่าจะใช้แนวทางใดบนเว็บไซต์ของคุณ
เมื่อประเมินกลยุทธ์ระยะยาวหรือการออกแบบเว็บไซต์ใหม่ ให้พิจารณาย้ายข้อมูลไปยังต้นทางเดียว เว้นแต่ว่าจะมีเหตุผลสำคัญที่จำเป็นต้องใช้สถาปัตยกรรมแบบหลายต้นทาง
ขอขอบคุณอย่างยิ่งสำหรับรีวิวและคำแนะนำทางเทคนิค: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle และ Andre Bandarra