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

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

Demián Renzulli

ข้อมูลเบื้องต้น

ที่ผ่านมา การใช้สถาปัตยกรรมหลายต้นทางมีข้อดีอยู่บ้าง แต่สำหรับ Progressive Web App แนวทางดังกล่าวก่อให้เกิดปัญหาหลายประการ โดยเฉพาะอย่างยิ่ง นโยบายต้นทางเดียวกันจะกำหนดข้อจำกัดในการแชร์สิ่งต่างๆ เช่น 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 ที่ 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

เนื่องจากไม่มีวิธีแชร์สิทธิ์ระหว่างต้นทางต่างๆ ทางออกเดียวคือขอสิทธิ์ในแต่ละโดเมนย่อยที่ต้องใช้ฟีเจอร์หนึ่งๆ (เช่น ตำแหน่ง) สําหรับสิ่งต่างๆ เช่น Web 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 เมื่อผู้ใช้ออกจากขอบเขตในโหมดสแตนด์อโลน

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

  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