วันพุธที่ 9 พฤศจิกายน 2016
Progressive Web App (PWA) ใช้ประโยชน์จากเทคโนโลยีใหม่เพื่อมอบสิ่งที่ดีที่สุดจากเว็บไซต์บนอุปกรณ์เคลื่อนที่และแอปพลิเคชันที่มาพร้อมเครื่องให้แก่ผู้ใช้ แถมยังเป็นแนวคิดใหม่ที่น่าตื่นเต้นที่สุดเรื่องหนึ่งบนเว็บตอนนี้ แต่เพื่อให้เกิดผลอย่างแท้จริง เว็บแอปเหล่านี้จะต้องจัดทำดัชนีและลิงก์ได้ ทุกคําแนะนําในบทความนี้เป็นแนวทางปฏิบัติแนะนําในปัจจุบันสําหรับการจัดทําดัชนี โดยไม่คํานึงว่าคุณกําลังสร้าง Progressive Web App หรือเว็บไซต์แบบคงที่ อย่างไรก็ตาม เราได้รวมแนวทางปฏิบัติแนะนําเหล่านี้ไว้ในรายการตรวจสอบเพื่อเป็นแนวทางแก่คุณ
ทำให้เนื้อหาของคุณสามารถ Crawl ได้
เพราะเหตุใด ก่อนหน้านี้ เว็บไซต์มักจะสร้างหรือแสดงผล HTML บนเซิร์ฟเวอร์ ซึ่งเป็นวิธีที่ง่ายที่สุดเพื่อให้มั่นใจว่าเนื้อหาจะลิงก์ได้โดยตรง เว็บแอปพลิเคชันทำให้การแสดงผลฝั่งไคลเอ็นต์เป็นที่นิยมมากขึ้น การแสดงผลวิธีนี้จะอัปเดตเนื้อหาแบบไดนามิกในหน้าเว็บระหว่างที่ผู้ใช้อยู่ในหน้าดังกล่าวโดยไม่ต้องโหลดหน้าใหม่
การแสดงผลรูปแบบใหม่ในปัจจุบันคือการแสดงผลแบบไฮบริด ซึ่งจะใช้การแสดงผลฝั่งเซิร์ฟเวอร์เมื่อผู้ใช้ไปยังส่วนต่างๆ ของ URL โดยตรง และใช้การแสดงผลฝั่งไคลเอ็นต์หลังการโหลดหน้าแรกสำหรับการนำทางครั้งต่อๆ มาและสำหรับคำขอที่โหลดพร้อมกันไม่ได้
ตัวอย่าง PWA ฝั่งเซิร์ฟเวอร์จะสาธิตการแสดงผลฝั่งเซิร์ฟเวอร์อย่างเดียว ในขณะที่ตัวอย่าง PWA แบบไฮบริดจะสาธิตการแสดงผลแบบผสม
หากคุณไม่คุ้นเคยกับคำศัพท์เฉพาะเกี่ยวกับการแสดงผลฝั่งเซิร์ฟเวอร์ และฝั่งไคลเอ็นต์ โปรดอ่านบทความต่อไปนี้เกี่ยวกับการแสดงผลฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ และการแสดงผลฝั่งเซิร์ฟเวอร์ในการตอบสนองและ node.js
แนวทางปฏิบัติแนะนำ
ใช้การแสดงผลฝั่งเซิร์ฟเวอร์หรือแบบไฮบริดเพื่อให้ผู้ใช้ได้รับเนื้อหาในข้อมูลส่วนแรกของคำขอเว็บ
โปรดตรวจสอบทุกครั้งว่า URL ของคุณเข้าถึงแบบแยกออกจากกันได้ ดังนี้
https://www.example.com/product/25/
URL ด้านบนควรลิงก์ในรายละเอียดไปยังทรัพยากรที่ระบุ
หากคุณไม่ได้รองรับการแสดงผลฝั่งเซิร์ฟเวอร์หรือการแสดงผลแบบไฮบริดสําหรับ Progressive Web App และตัดสินใจใช้การแสดงผลฝั่งไคลเอ็นต์ เราขอแนะนําให้ใช้ "เครื่องมือโปรแกรม Googlebot จําลอง" ของ Google Search Console เพื่อยืนยันเนื้อหาแสดงผลต่อ Crawler ของ Search ได้สําเร็จ
อย่าเปลี่ยนเส้นทางผู้ใช้ที่เข้าถึงลิงก์ในรายละเอียดให้กลับไปยังหน้าแรกของเว็บแอป
นอกจากนี้ยังควรหลีกเลี่ยงการแสดงหน้าข้อผิดพลาดให้ผู้ใช้ แทนการลิงก์ในรายละเอียด
สร้าง URL ที่สั้นและกระชับ
เพราะเหตุใด ตัวระบุ Fragment (#user/24601/ หรือ #!user/24601/) เป็นวิธีแก้ปัญหาชั่วคราวที่ได้ผลสำหรับเบราว์เซอร์ที่ไปยังเนื้อหาใหม่ของ AJAX จากเซิร์ฟเวอร์หนึ่งโดยไม่ต้องโหลดหน้าใหม่
การออกแบบนี้เรียกว่าการแสดงผลฝั่งไคลเอ็นต์
อย่างไรก็ตามไวยากรณ์ของตัวระบุ Fragment ใช้ไม่ได้กับเครื่องมือเว็บ กรอบการทำงาน และโปรโตคอลบางรายการ เช่น โปรโตคอลกราฟแบบเปิดของ Facebook
History API ทำให้เราสามารถอัปเดต URL โดยไม่ต้องใช้ตัวระบุ Fragment และยังสามารถเรียกทรัพยากรแบบไม่พร้อมกันได้ จึงช่วยหลีกเลี่ยงการโหลดหน้าใหม่ ซึ่งดีต่อทั้ง 2 ฝ่าย รูปแบบการ Crawl ของ AJAX (ที่มี #! / Escaped-fragment URL) อาจเหมาะสมในช่วงเวลานั้น แต่ตอนนี้เราไม่แนะนําให้ใช้แล้ว
ตัวอย่าง PWA แบบไฮบริดและ PWA ฝั่งไคลเอ็นต์จะสาธิต History API
แนวทางปฏิบัติแนะนำ
สร้าง URL ที่สั้นและกระชับโดยไม่มีตัวระบุ Fragment (# หรือ #!) เช่น
https://www.example.com/product/25/
หากใช้การแสดงผลฝั่งไคลเอ็นต์หรือแบบไฮบริด คุณจะต้องรองรับการนำทางในเบราว์เซอร์ด้วย History API
ข้อควรจำ
ไม่แนะนําให้ใช้โครงสร้าง URL #! เพื่อเพิ่ม URL ที่ไม่ซ้ำ
https://www.example.com/#!product/25/
วิธีนี้เป็นการแก้ปัญหาชั่วคราวก่อนที่จะมี History API ซึ่งถือว่าเป็นรูปแบบที่แยกจากโครงสร้าง URL แบบที่มี # อย่างเดียว
ระบบไม่รองรับการใช้โครงสร้าง URL # ที่ไม่มีสัญลักษณ์ ! มาด้วยกัน
https://www.example.com/#product/25/
โครงสร้าง URL นี้เป็นแนวคิดในเว็บอยู่แล้ว และเกี่ยวข้องกับการลิงก์ในรายละเอียดไปยังเนื้อหาในหน้าที่ระบุ
ระบุ URL ตามรูปแบบบัญญัติ
เพราะเหตุใด วิธีที่ดีที่สุดในการป้องกันความสับสนเมื่อจัดทำดัชนีเวลาที่มีเนื้อหาเดียวกันอยู่ในหลาย URL (ไม่ว่าจะในโดเมนเดียวกันหรือคนละโดเมนก็ตาม) คือการระบุให้หน้าหนึ่งเป็นหน้า Canonical และให้หน้าอื่นๆ ที่มีเนื้อหาซ้ำอ้างอิงหน้าดังกล่าว
แนวทางปฏิบัติแนะนำ
รวมแท็กต่อไปนี้ในทุกหน้าที่มีเนื้อหาเหมือนกัน ดังนี้
<link rel="canonical" href="https://www.example.com/your-url/" />
หากคุณมี Accelerated Mobile Pages อย่าลืมตรวจสอบว่าใช้คําสั่ง rel="amphtml" อย่างถูกต้องด้วย
ข้อควรจำ
หลีกเลี่ยงเนื้อหาที่ตั้งใจซ้ำกันใน URL หลายรายการและไม่ได้ใช้เอลิเมนต์ของลิงก์ rel="canonical"
ตัวอย่างเช่น เอลิเมนต์ของลิงก์ rel="canonical" สามารถลดความกำกวมสำหรับ URL ที่มีพารามิเตอร์การติดตาม
หลีกเลี่ยงการสร้างการอ้างอิงตามรูปแบบบัญญัติที่ขัดแย้งกันในหน้าต่างๆ ของคุณ
ออกแบบสำหรับอุปกรณ์ที่หลากหลาย
เพราะเหตุใด ผู้ใช้ทุกคนควรได้รับประสบการณ์ที่ดีที่สุดขณะที่ดูเว็บไซต์ของคุณ ไม่ว่าจะใช้อุปกรณ์ใดก็ตาม
ทำให้เว็บไซต์ของคุณตอบสนองตามอุปกรณ์ตั้งแต่การออกแบบ ทั้งแบบอักษร ระยะขอบระยะห่างจากขอบ ปุ่ม และการออกแบบทั่วไปของเว็บไซต์ควรปรับขนาดแบบไดนามิกตามความละเอียดของหน้าจอและวิวพอร์ตของอุปกรณ์
รูปภาพขนาดเล็กที่ขยายใหญ่ขึ้นในเดสก์ท็อปหรืออุปกรณ์แท็บเล็ตมอบประสบการณ์การใช้งานที่ไม่ดี ในทางกลับกัน รูปภาพความละเอียดสูงก็ใช้เวลาดาวน์โหลดนานสำหรับอุปกรณ์เคลื่อนที่และอาจส่งผลต่อประสิทธิภาพของการเลื่อน
อ่านเพิ่มเติมเกี่ยวกับ UX สําหรับ PWA
แนวทางปฏิบัติแนะนำ
ใช้แอตทริบิวต์ srcset เพื่อดึงข้อมูลรูปภาพความละเอียดต่างๆ สําหรับความหนาแน่นหน้าจอที่ต่างกัน เพื่อหลีกเลี่ยงการดาวน์โหลดรูปภาพที่มีขนาดใหญ่กว่าหน้าจอของอุปกรณ์
ปรับขนาดแบบอักษรและความสูงของบรรทัดเพื่อให้ข้อความอ่านได้ชัดเจนไม่ว่าอุปกรณ์จะมีขนาดเท่าไรก็ตาม และอย่าลืมตรวจสอบว่าระยะห่างจากขอบและขอบเขตขององค์ประกอบต่างๆ จะปรับขนาดตามขนาดของหน้าจออุปกรณ์อย่างเหมาะสมด้วยเช่นกัน
ทดสอบความละเอียดของหน้าจอขนาดต่างๆ โดยใช้ฟีเจอร์โหมดอุปกรณ์ของเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ Chrome และเครื่องมือทดสอบความเหมาะกับอุปกรณ์เคลื่อนที่
อย่าแสดงเนื้อหาต่อผู้ใช้ต่างจากที่คุณได้แสดงต่อ Google หากคุณใช้การเปลี่ยนเส้นทางหรือการตรวจหา User Agent (หรือที่เรียกว่าการดักจับเบราว์เซอร์หรือการแสดงผลแบบไดนามิก) เพื่อเปลี่ยนดีไซน์ของเว็บไซต์สําหรับ อุปกรณ์ต่างๆ สิ่งสําคัญคือเนื้อหาต้องเหมือนกัน
ใช้เครื่องมือ "โปรแกรม Googlebot จำลอง" ใน Search Console เพื่อตรวจสอบว่าเนื้อหาที่ Google ดึงมาตรงกับเนื้อหาที่ผู้ใช้เห็น
ด้วยเหตุผลด้านความสามารถในการใช้งาน โปรดหลีกเลี่ยงการใช้แบบอักษรที่มีขนาดคงที่
พัฒนาอย่างสม่ำเสมอ
เพราะเหตุใด วิธีที่ปลอดภัยที่สุดวิธีหนึ่งที่คุณควรใช้เมื่อมีการเพิ่มฟีเจอร์ลงในเว็บแอปพลิเคชันคือ การดำเนินการเปลี่ยนแปลงอย่างสม่ำเสมอ หากเพิ่มฟีเจอร์ทีละรายการ คุณจะสามารถดูผลการเปลี่ยนแปลงแต่ละรายการได้
แต่ในอีกแง่หนึ่ง นักพัฒนาซอฟต์แวร์มากมายกลับมองว่า Progressive Web App นี้เป็นโอกาสในการยกเครื่องเว็บไซต์ในอุปกรณ์เคลื่อนที่ด้วยการดำเนินการเพียงครั้งเดียว ซึ่งก็คือการพัฒนาเว็บแอปใหม่ในสภาพแวดล้อมแบบแยกและนำมาแทนที่เว็บไซต์ในอุปกรณ์เคลื่อนที่ที่มีอยู่เมื่อพร้อมใช้งาน
ระหว่างการพัฒนาฟีเจอร์อย่างสม่ำเสมอ ให้ลองแยกการเปลี่ยนแปลงออกเป็นส่วนย่อยๆ ตัวอย่างเช่น หากคุณต้องการย้ายจากการแสดงผลฝั่งเซิร์ฟเวอร์ไปเป็นการแสดงผลแบบไฮบริด คุณควรจัดการด้วยการปรับปรุงเพียงครั้งเดียว แทนการรวมกับฟีเจอร์อื่นๆ
ทั้ง 2 วิธีมีข้อดีและข้อเสียอยู่ในตัว การปรับปรุงช่วยลดความซับซ้อนในการจัดการกับความสามารถในการจัดทำดัชนีของการค้นหาเนื่องจากการเปลี่ยนแปลงเป็นไปอย่างต่อเนื่อง อย่างไรก็ตาม การปรับปรุงอาจส่งผลให้ขั้นตอนการพัฒนาช้าลงและอาจทำให้การปรับปรุงใหม่ไม่สร้างสรรค์เท่าที่ควรหากการพัฒนาไม่ได้เริ่มจากศูนย์
ในทั้ง 2 กรณี ส่วนที่ละเอียดอ่อนที่สุดที่คุณพึงระวังคือ Canonical URL และการกำหนดค่า robots.txt ของเว็บไซต์
แนวทางปฏิบัติแนะนำ
ปรับปรุงเว็บไซต์อย่างค่อยเป็นค่อยไปโดยเพิ่มฟีเจอร์ใหม่ทีละรายการ
ตัวอย่างเช่น หากยังไม่รองรับการใช้ HTTPS คุณควรเริ่มจากการเปลี่ยนไปใช้เว็บไซต์ที่ปลอดภัย
ข้อควรจำ
หากคุณพัฒนา Progressive Web App ในสภาพแวดล้อมแบบแยก และระวังการเปิดตัวเว็บดังกล่าวโดยที่ยังไม่ได้ตรวจสอบลิงก์ rel-canonical และการตั้งค่า robots.txt อย่างเหมาะสม
อย่าลืมตรวจสอบว่าลิงก์ rel-canonical ของคุณชี้ไปยังเว็บไซต์ที่มีอยู่จริง และการกำหนดค่า robots.txt อนุญาตให้ Crawler ทำการ Crawl เว็บไซต์ใหม่ของคุณได้
คุณควรป้องกันไม่ให้ Crawler จัดทำดัชนีเว็บไซต์ที่ยังอยู่ระหว่างการพัฒนาและยังไม่ได้เปิดตัว แต่อย่าลืมเลิกบล็อก Crawler ไม่ให้เข้าถึงเว็บไซต์ใหม่ของคุณหลังจากที่คุณเปิดตัวแล้ว
ใช้การเพิ่มประสิทธิภาพแบบต่อเนื่อง
เพราะเหตุใด คุณควรตรวจหาฟีเจอร์ของเบราว์เซอร์ก่อนเริ่มใช้ทุกครั้งที่ทำได้ เนื่องจากการตรวจหาฟีเจอร์เป็นวิธีที่ดีกว่าการทดสอบหาเบราว์เซอร์ที่คุณคิดว่ารองรับการใช้งานฟีเจอร์ที่ต้องการ
แนวทางปฏิบัติที่ไม่ถูกต้องซึ่งพบบ่อยในอดีตคือการเปิดหรือปิดใช้ฟีเจอร์โดยการทดสอบว่าผู้ใช้มีเบราว์เซอร์ใด อย่างไรก็ตาม เนื่องจากเบราว์เซอร์พัฒนาไปพร้อมกับฟีเจอร์อยู่เรื่อยๆ เราจึงไม่แนะนำเทคนิคนี้
Service Worker เป็นเทคโนโลยีใหม่ซึ่งคุณควรดูแลเพื่อรักษาความเข้ากันได้ในระหว่างที่พยายามสร้างความคืบหน้า จึงเป็นตัวอย่างที่เหมาะแก่การใช้การเพิ่มประสิทธิภาพแบบต่อเนื่อง
แนวทางปฏิบัติแนะนำ
ก่อนที่จะลงทะเบียน Service Worker ให้ตรวจหาความพร้อมใช้งานของ API ดังนี้
if ('serviceWorker' in navigator) {
...
ใช้ตามวิธีการตรวจหา API สำหรับฟีเจอร์ทั้งหมดของเว็บไซต์
อย่าใช้ user-agent ของเบราว์เซอร์เพื่อเปิดหรือปิดใช้คุณลักษณะในเว็บแอป ตรวจสอบเสมอว่า API ของฟีเจอร์พร้อมให้ใช้งานหรือไม่ และลดระดับอย่างค่อยเป็นค่อยไปหากไม่พร้อมใช้งาน
หลีกเลี่ยงการอัปเดตหรือการเปิดตัวเว็บไซต์โดยไม่ทดสอบในเบราว์เซอร์ที่หลากหลายก่อน! ตรวจดูการวิเคราะห์เว็บไซต์เพื่อเรียนรู้ว่าเบราว์เซอร์ใดเป็นที่นิยมที่สุดในฐานผู้ใช้ของคุณ
ทดสอบกับ Search Console
เพราะเหตุใด คุณควรทำความเข้าใจว่า Google Search ดูเนื้อหาในเว็บไซต์ของคุณอย่างไร คุณสามารถใช้ Search Console เพื่อดึงข้อมูล URL แต่ละรายการจากเว็บไซต์ และดูว่า Google Search เห็น URL เหล่านี้อย่างไรโดยใช้ฟีเจอร์ "ทำการ Crawl > โปรแกรม Googlebot จำลอง" Search Console จะประมวลผล JavaScript และแสดงหน้าเมื่อคุณเลือกตัวเลือกนั้น มิเช่นนั้นจะแสดงเพียงการตอบสนองต่อ Raw HTML เท่านั้น
นอกจากนี้ Google Search Console จะวิเคราะห์เนื้อหาในหน้าของคุณในรูปแบบต่างๆ รวมถึงการตรวจหาการมีอยู่ของ Structured Data, Rich Card, ไซต์ลิงก์ และ Accelerated Mobile Pages ด้วย
แนวทางปฏิบัติแนะนำ
ติดตามตรวจสอบเว็บไซต์ของคุณโดยใช้ Search Console และสำรวจฟีเจอร์ต่างๆ รวมถึง "โปรแกรม Googlebot จำลอง"
การสร้าง Sitemap ผ่าน Search Console (การ Crawl > Sitemap) ก็เป็นวิธีที่ได้ผลเพื่อให้ Google Search รับทราบถึงการมีอยู่ของทุกหน้าในเว็บไซต์
ใส่ข้อมูลเสริมด้วยข้อมูลที่มีโครงสร้างใน Schema.org
เพราะเหตุใด Structured Data ของ Schema.org เป็นคำศัพท์ที่ยืดหยุ่นสำหรับการสรุปส่วนที่สำคัญที่สุดของหน้าเว็บเป็นข้อมูลที่เครื่องประมวลผลได้ ซึ่งอาจเป็นการบอกข้อมูลทั่วไป เช่น หน้าเว็บนี้เป็น NewsArticle หรืออาจเจาะจงด้วยการบอกรายละเอียดสถานที่ ชื่อวงดนตรี สถานที่จัดงาน และผู้ขายตั๋วสำหรับวงดนตรีที่กำลังออกทัวร์คอนเสิร์ต หรือสรุปส่วนผสมและขั้นตอนการทำสูตรอาหาร
การใช้ข้อมูลเมตานี้อาจใช้ไม่ได้กับทุกหน้าในเว็บแอปพลิเคชันของคุณ แต่เราขอแนะนำให้ใช้เมื่อเหมาะสม Google จะแตกข้อมูลหลังจากที่แสดงผลหน้าเว็บแล้ว
ข้อมูลมีหลายประเภท เช่น NewsArticle, Recipe และ Product เป็นต้น คุณสามารถดูประเภทข้อมูลที่รองรับทั้งหมดที่นี่ได้ด้วย
แนวทางปฏิบัติแนะนำ
ตรวจสอบว่าข้อมูลเมตา Schema.org ถูกต้องโดยใช้เครื่องมือทดสอบ Structured Data ของ Google
ตรวจสอบว่าข้อมูลที่คุณใส่ไว้ปรากฏขึ้นและไม่มีข้อผิดพลาด
หลีกเลี่ยงการใช้ประเภทข้อมูลที่ไม่ตรงกับเนื้อหาจริงๆ ของหน้าเว็บ ตัวอย่างเช่น อย่าใช้ Recipe สําหรับเสื้อยืดที่คุณขาย ให้ใช้ Product แทน
ใส่ข้อมูลเสริมด้วยกราฟแบบเปิดและการ์ด Twiiter
เพราะเหตุใด นอกเหนือจากข้อมูลเมตาของ Schema.org คุณควรเพิ่มการรองรับการใช้งานสำหรับโปรโตคอลกราฟแบบเปิดของ Facebook และ Rich Card ของ Twitter
รูปแบบข้อมูลเมตาเหล่านี้จะปรับปรุงประสบการณ์ของผู้ใช้เมื่อมีการแชร์เนื้อหาของคุณในโซเชียลเน็ตเวิร์กที่สอดคล้อง
หากเว็บไซต์หรือเว็บแอปพลิเคชันที่มีอยู่ของคุณใช้รูปแบบเหล่านี้ คุณต้องดูแลให้เว็บเหล่านี้รวมอยู่ใน Progressive Web App ด้วยเพื่อให้เกิดความแพร่หลายที่มีประสิทธิภาพสูงสุด
แนวทางปฏิบัติแนะนำ
ทดสอบมาร์กอัป Open Graph ด้วยFacebook Object Debugger Tool
ทำความคุ้นเคยกับรูปแบบข้อมูลเมตาของ Twitter
อย่าลืมใส่รูปแบบเหล่านี้หากเว็บไซต์ที่คุณมีอยู่รองรับการใช้งาน
ทดสอบกับเบราว์เซอร์ที่หลากหลาย
เพราะเหตุใด จากมุมมองของผู้ใช้ พฤติกรรมการใช้เว็บไซต์ที่เหมือนกันในทุกเบราว์เซอร์เป็นเรื่องที่สำคัญ แม้ว่าการใช้งานอาจแตกต่างกันไปบนหน้าจอที่ขนาดไม่เท่ากัน แต่เราก็คาดหวังให้เว็บไซต์ในอุปกรณ์เคลื่อนที่ทำงานได้เหมือนกันในอุปกรณ์ขนาดใกล้เคียงกัน ไม่ว่าจะเป็น iPhone หรือโทรศัพท์มือถือ Android
แม้ว่าเว็บอาจดูเหมือนแยกเป็นส่วนต่างๆ เพราะมีการใช้เบราว์เซอร์จำนวนมากทั่วโลก แต่ความหลากหลายและการแข่งขันเป็นส่วนที่ทำให้เว็บเป็นแพลตฟอร์มที่สร้างสรรค์ โชคดีที่ปัจจุบันมาตรฐานของเว็บมีคุณภาพดีกว่าที่เคย อีกทั้งเครื่องมือที่ทันสมัยก็ทำให้นักพัฒนาซอฟต์แวร์สามารถสร้างเว็บไซต์ที่สมบูรณ์และเข้ากันได้ในทุกเบราว์เซอร์ด้วยความมั่นใจ
แนวทางปฏิบัติแนะนำ
ใช้เครื่องมือทดสอบข้ามเบราว์เซอร์ เช่น BrowserStack.com, Browserling.com หรือ BrowserShots.org เพื่อตรวจสอบว่า PWA ของคุณใช้งานได้บนเบราว์เซอร์ที่หลากหลาย
วัดประสิทธิภาพของการโหลดหน้าเว็บ
เพราะเหตุใด ยิ่งเว็บไซต์โหลดเร็วเท่าไหร่ ประสบการณ์ของผู้ใช้ก็ดีขึ้นเท่านั้น การเพิ่มประสิทธิภาพความเร็วของหน้าเว็บเป็นสิ่งที่นักพัฒนาเว็บให้ความสำคัญกันอยู่แล้ว แต่บางครั้ง เวลาที่คุณพัฒนาเว็บไซต์เวอร์ชันใหม่ การเพิ่มประสิทธิภาพที่จำเป็นอาจไม่ใช่สิ่งที่สำคัญที่สุด
ในการพัฒนา Progressive Web App เราขอแนะนำให้คุณวัดประสิทธิภาพของความเร็วในการโหลดหน้าเว็บและเพิ่มประสิทธิภาพก่อนการเปิดตัวเว็บไซต์เพื่อผลลพธ์ที่ดีที่สุด
แนวทางปฏิบัติแนะนำ
ใช้เครื่องมืออย่างเช่น Page Speed Insights และWeb Page Test เพื่อวัดประสิทธิภาพการโหลดหน้าเว็บของเว็บไซต์ แม้ว่า Googlebot อาจรอการแสดงผลของหน้าได้ แต่งานวิจัยแสดงให้เห็นว่าผู้บริโภค 40% จะออกจากหน้าเว็บที่ใช้เวลาโหลดนานกว่า 3 วินาที
อ่านเพิ่มเติมเกี่ยวกับคําแนะนําด้านประสิทธิภาพของหน้าเว็บและเส้นทางการแสดงผลที่จำเป็นได้ที่นี่
หลีกเลี่ยงการปล่อยให้การเพิ่มประสิทธิภาพเป็นขั้นตอนหลังการเปิดตัว หากเนื้อหาของเว็บไซต์ของคุณโหลดอย่างรวดเร็วก่อนการย้ายไปยัง Progressive Web App ใหม่ คุณก็ไม่ควรทำให้การเพิ่มประสิทธิภาพถดถอย
เราหวังว่ารายการตรวจสอบด้านบนจะเป็นประโยชน์และมอบแนวทางที่เหมาะสมเพื่อช่วยคุณพัฒนา Progressive Web App โดยคำนึงถึงความสามารถในการจัดทำดัชนีไปพร้อมกัน
ในการเริ่มต้น อย่าลืมดูตัวอย่างความสามารถในการจัดทำดัชนีของ Progressive Web App ที่สาธิตการแสดงผลฝั่งไคลเอ็นต์ ฝั่งเซิร์ฟเวอร์ และแบบไฮบริด หากมีข้อสงสัย โปรดไปที่ฟอรัมผู้ดูแลเว็บ