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

ความท้าทายและวิธีแก้ปัญหาเบื้องต้นในการสร้าง 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

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

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

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

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

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

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

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

บทสรุป

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

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

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

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