Progressive Web App ในเว็บไซต์หลายต้นทาง

ความท้าทายและวิธีแก้ปัญหาชั่วคราวในการสร้าง Progressive Web App ในเว็บไซต์แบบหลายต้นทาง

Demián Renzulli

เผยแพร่: 19 สิงหาคม 2019

ก่อนหน้านี้การใช้สถาปัตยกรรมแบบหลายต้นทางมีข้อดีบางประการ สำหรับ Progressive Web App แนวทางดังกล่าวมีอุปสรรคมากมาย โดยเฉพาะอย่างยิ่ง Same-Origin Policy จะกำหนดข้อจำกัดในการแชร์สิ่งต่างๆ เช่น Service Worker และแคช สิทธิ์ และการสร้างประสบการณ์การใช้งานแบบสแตนด์อโลนในหลายๆ ต้นทาง

ดูการใช้งานที่เหมาะสมและไม่เหมาะสมของหลายต้นทาง รวมถึงอธิบายความท้าทาย และวิธีแก้ปัญหาในการสร้าง 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 นั้นเป็นของ ซึ่งหมายความว่าหากโฮสต์ Service Worker ที่ https://www.example.com จะควบคุมได้เฉพาะ URL จากต้นทางนั้น (ตามเส้นทางที่กำหนดไว้ในพารามิเตอร์ขอบเขต) แต่จะไม่ควบคุมหน้าเว็บใดๆ ในโดเมนย่อยอื่นๆ เช่น หน้าเว็บใน https://section.example.com

ในกรณีนี้ วิธีแก้ปัญหาเดียวคือการใช้ Service Worker หลายรายการ (รายการละ 1 ต้นทาง)

กำลังแคช

นอกจากนี้ ออบเจ็กต์แคช, IndexedDB และ 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

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

การติดตั้ง

หากต้องการติดตั้ง PWA ต้นทางแต่ละรายการต้องมีไฟล์ Manifest ของตัวเองที่มี start_url ซึ่งสัมพันธ์กับตัวมันเอง ซึ่งหมายความว่าผู้ใช้ที่ได้รับข้อความแจ้งให้ติดตั้งในต้นทางหนึ่ง (เช่น https://section.example.com) จะติดตั้ง PWA ที่มี start_url ในต้นทางอื่น (เช่น https://www.example.com) ไม่ได้ กล่าวอีกนัยหนึ่งคือ ผู้ใช้ที่ได้รับข้อความแจ้งให้ติดตั้งในโดเมนย่อยจะติดตั้ง PWA สำหรับหน้าย่อยได้เท่านั้น ไม่ใช่สำหรับ URL หลักของแอป

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

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

1. ฟังเหตุการณ์ beforeinstallprompt
2. ป้องกันไม่ให้ข้อความแจ้งปรากฏโดยการเรียกใช้ event.preventDefault()

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

โหมดสแตนด์อโลน

ขณะไปยังส่วนต่างๆ ในหน้าต่างแบบสแตนด์อโลน เบราว์เซอร์จะทำงานแตกต่างออกไปเมื่อผู้ใช้ออกนอกขอบเขตที่กำหนดโดยไฟล์ Manifest ของ PWA ลักษณะการทำงานจะขึ้นอยู่กับเวอร์ชันและผู้ให้บริการของเบราว์เซอร์แต่ละราย เช่น Chrome เวอร์ชันล่าสุดจะเปิด Chrome Custom Tab เมื่อผู้ใช้ออกจากขอบเขตในโหมดสแตนด์อโลน

ในกรณีส่วนใหญ่ ปัญหานี้ไม่มีวิธีแก้ แต่คุณสามารถใช้ทางอ้อมกับประสบการณ์การใช้งานบางส่วนที่โฮสต์อยู่ในโดเมนย่อยได้ (เช่น เวิร์กโฟลว์การเข้าสู่ระบบ) โดยทำดังนี้

1. URL ใหม่ https://login.example.com อาจเปิดภายใน iframe แบบเต็มหน้าจอ
2. เมื่อดำเนินการใน iframe เสร็จแล้ว (เช่น กระบวนการเข้าสู่ระบบ) คุณจะใช้ postMessage() เพื่อส่งข้อมูลที่ได้จาก iframe กลับไปยังหน้าหลักได้
3. ขั้นตอนสุดท้ายคือเมื่อหน้าหลักได้รับข้อความแล้ว คุณจะยกเลิกการลงทะเบียน Listener และนำ iframe ออกจาก DOM ได้

บทสรุป

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

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

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

ขอขอบคุณ Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle และ Andre Bandarra เป็นอย่างยิ่งสำหรับคำแนะนำและการตรวจสอบทางเทคนิค