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 โปรแกรมต่อต้นทาง)

การแคช

นอกจากนี้ ออบเจ็กต์ Cache, IndexingDB และ localStorage จะถูกจำกัดไว้ที่ต้นทางเพียงแห่งเดียว ซึ่งหมายความว่าคุณจะเข้าถึงแคชที่เป็นของ https://www.example.com ไม่ได้ เช่น https://www.section.example.com

ต่อไปนี้เป็นสิ่งที่คุณสามารถทำได้เพื่อจัดการแคชอย่างเหมาะสมในสถานการณ์เช่นนี้

  • ใช้ประโยชน์จากการแคชเบราว์เซอร์: ขอแนะนำให้ใช้แนวทางปฏิบัติแนะนำในการแคชเบราว์เซอร์แบบดั้งเดิมเสมอ เทคนิคนี้ให้ประโยชน์เพิ่มเติมคือการนำทรัพยากรที่แคชไว้มาใช้ซ้ำในต้นทางต่างๆ ซึ่งทำด้วยแคชของ Service Worker ไม่ได้ ดูแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับวิธีใช้ HTTP Cache กับ 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 ได้สำหรับหน้าเว็บย่อยเท่านั้น แต่จะติดตั้ง PWA หลักของแอปไม่ได้

นอกจากนี้ ปัญหาอาจเกิดจากผู้ใช้รายเดียวกันอาจได้รับข้อความแจ้งการติดตั้งหลายครั้งเมื่อไปยังส่วนต่างๆ ของเว็บไซต์ หากโดเมนย่อยแต่ละรายการมีคุณสมบัติตรงตามเกณฑ์การติดตั้ง และแจ้งให้ผู้ใช้ติดตั้ง 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