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

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

Demián Renzulli
Demián Renzulli
X GitHub

เผยแพร่เมื่อวันที่ 19 สิงหาคม 2019

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

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

การใช้ต้นทางหลายรายการที่ดีและไม่ดี

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

ข้อดี

ลองดูเหตุผลที่เป็นประโยชน์ต่อไปนี้ก่อน

  • การแปลภาษา/ภาษา: การใช้โดเมนระดับบนสุดแบบรหัสประเทศเพื่อแยกเว็บไซต์ที่จะแสดงในประเทศต่างๆ (เช่น 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, 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

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