ตอบโต้กลยุทธ์ SEO และแนวทางปฏิบัติที่ดีที่สุด

React ได้รับการพัฒนาเพื่อสร้าง UI แบบโต้ตอบที่ เปิดเผย แยกส่วน และ ข้ามแพลตฟอร์ม วันนี้ เป็นหนึ่งในเฟรมเวิร์ก JavaScript ที่ได้รับความนิยมมากกว่า—ถ้าไม่ได้รับความนิยมมากที่สุด—สำหรับการเขียนแอพพลิเคชั่นฟรอนต์เอนด์ที่มีประสิทธิภาพ React พัฒนาขึ้นในขั้นต้นเพื่อเขียน Single Page Applications (SPA) เพื่อสร้างเว็บไซต์และแอปพลิเคชั่นมือถือเต็มรูปแบบ

หากคุณมีประสบการณ์มากมายในการพัฒนาเว็บแบบเดิมๆ และย้ายไปที่ React คุณจะสังเกตเห็นว่าโค้ด HTML และ CSS ของคุณย้ายไปที่ JavaScript เพิ่มขึ้น เนื่องจาก React ไม่แนะนำให้สร้างหรืออัปเดตองค์ประกอบ UI โดยตรง แต่ให้อธิบาย "สถานะ" ของ UI แทน จากนั้น React จะอัปเดต DOM ให้ตรงกับสถานะด้วยวิธีที่มีประสิทธิภาพที่สุด

ด้วยเหตุนี้ การเปลี่ยนแปลงทั้งหมดใน UI หรือ DOM จะต้องทำผ่านเอ็นจิ้นของ React แม้ว่าจะสะดวกสำหรับนักพัฒนา แต่ก็อาจหมายถึงเวลาโหลดนานขึ้นสำหรับผู้ใช้ และทำงานมากขึ้นสำหรับเครื่องมือค้นหาเพื่อค้นหาและจัดทำดัชนีเนื้อหา

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

Google รวบรวมข้อมูลและจัดทำดัชนีหน้าเว็บอย่างไร

Google ได้รับมากกว่า 90% ของการค้นหาออนไลน์ทั้งหมด มาดูกระบวนการรวบรวมข้อมูลและจัดทำดัชนีอย่างละเอียดยิ่งขึ้น

ภาพรวมนี้นำมาจากเอกสารของ Google สามารถช่วยเราได้ โปรดทราบว่านี่เป็นแผนภาพบล็อกแบบง่าย Googlebot ที่แท้จริงนั้นซับซ้อนกว่ามาก

ข้อสังเกต:

1. Googlebot รักษาคิวการรวบรวมข้อมูลที่มี URL ทั้งหมดที่จำเป็นสำหรับการรวบรวมข้อมูลและจัดทำดัชนีในอนาคต
2. เมื่อโปรแกรมรวบรวมข้อมูลไม่ได้ใช้งาน โปรแกรมจะหยิบ URL ถัดไปในคิว ส่งคำขอ และดึง HTML
3. หลังจากแยกวิเคราะห์ HTML แล้ว Googlebot จะกำหนดว่าจำเป็นต้องดึงข้อมูลและเรียกใช้ JavaScript เพื่อแสดงผลเนื้อหาหรือไม่ ถ้าใช่ URL จะถูกเพิ่มในคิวการแสดงผล
4. ในเวลาต่อมา ตัวแสดงภาพจะดึงและเรียกใช้ JavaScript เพื่อแสดงผลหน้า มันส่ง HTML ที่แสดงผลกลับไปที่หน่วยประมวลผล
5. หน่วยประมวลผลจะแยก <a> tags ทั้งหมดที่กล่าวถึงในหน้าเว็บและเพิ่มกลับเข้าไปในคิวการรวบรวมข้อมูล
6. เนื้อหาถูกเพิ่มลงในดัชนีของ Google

โปรดสังเกตว่ามีความแตกต่างที่ชัดเจนระหว่างขั้นตอน การประมวลผล ที่แยกวิเคราะห์ HTML และขั้นตอนการแสดงผลที่รัน JavaScript

ความแตกต่างนี้มีอยู่เพราะการเรียกใช้ JavaScript มี ราคาแพง เนื่องจาก Googlebot ต้องดูหน้าเว็บมากกว่า 130 ล้านล้านหน้า ดังนั้นเมื่อ Googlebot รวบรวมข้อมูลหน้าเว็บ Googlebot จะแยกวิเคราะห์ HTML ทันที จากนั้นจึง จัดคิว JavaScript เพื่อเรียกใช้ในภายหลัง เอกสารของ Google ระบุว่าหน้าจะอยู่ในคิวการแสดงผลเป็นเวลาสองสามวินาที แม้ว่าอาจนานกว่านั้นก็ตาม

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

หมายเหตุ: คุณสามารถอ่านหลักเกณฑ์ของ Google ในการจัดการงบประมาณการรวบรวมข้อมูลได้ที่นี่

ทำไมการเพิ่มประสิทธิภาพ React สำหรับ SEO จึงเป็นความท้าทาย

ภาพรวมโดยย่อของ Googlebot การรวบรวมข้อมูลและการจัดทำดัชนีเป็นเพียงการขีดข่วนพื้นผิวเท่านั้น อย่างไรก็ตาม วิศวกรซอฟต์แวร์ควรระบุปัญหาที่อาจเกิดขึ้นซึ่งเครื่องมือค้นหาที่พยายามรวบรวมข้อมูลและจัดทำดัชนีหน้า React ตอนนี้ เราสามารถเจาะลึกถึงสิ่งที่ทำให้ React SEO ท้าทาย และสิ่งที่นักพัฒนาสามารถทำได้เพื่อแก้ไขปัญหาและเอาชนะความท้าทายเหล่านี้

เนื้อหาที่ผ่านครั้งแรกว่างเปล่า

เรารู้ว่าแอปพลิเคชัน React อาศัย JavaScript เป็นอย่างมาก และมักประสบปัญหากับเครื่องมือค้นหา นี่เป็นเพราะ React ใช้โมเดลเชลล์ของแอปโดยค่าเริ่มต้น HTML เริ่มต้นไม่มีเนื้อหาที่มีความหมาย และผู้ใช้หรือบอทต้องเรียกใช้ JavaScript เพื่อดูเนื้อหาจริงของหน้า

วิธีการนี้หมายความว่า Googlebot ตรวจพบหน้าว่างในระหว่างการผ่านครั้งแรก Google จะมองเห็นเนื้อหาก็ต่อเมื่อมีการแสดงหน้าเว็บเท่านั้น การทำเช่นนี้จะทำให้การจัดทำดัชนีเนื้อหาล่าช้าเมื่อต้องจัดการกับหน้าหลายพันหน้า

เวลาในการโหลดและประสบการณ์ผู้ใช้

การดึงข้อมูล การแยกวิเคราะห์ และรัน JavaScript ต้องใช้เวลา นอกจากนี้ JavaScript อาจต้องโทรผ่านเครือข่ายเพื่อดึงเนื้อหา และผู้ใช้อาจต้องรอสักครู่ก่อนที่จะสามารถดูข้อมูลที่ร้องขอได้

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

เราตรวจสอบประสิทธิภาพของเว็บไซต์โดยละเอียดในหัวข้อต่อไปนี้

ข้อมูลเมตาของหน้า

แท็ก Meta <meta> มีประโยชน์เพราะช่วยให้ Google และเว็บไซต์โซเชียลมีเดียอื่นๆ แสดงชื่อ ภาพขนาดย่อ และคำอธิบายที่เหมาะสมสำหรับเพจได้ แต่เว็บไซต์เหล่านี้ใช้แท็ก <head> ของหน้าเว็บที่ดึงมาเพื่อรับข้อมูลนี้ เว็บไซต์เหล่านี้ไม่รัน JavaScript สำหรับหน้าเป้าหมาย

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

แผนผังเว็บไซต์

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

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

ข้อควรพิจารณาเกี่ยวกับ SEO อื่นๆ

ข้อควรพิจารณาเหล่านี้เกี่ยวข้องกับการกำหนดแนวทางปฏิบัติ SEO ที่ดีโดยทั่วไป

1. มีโครงสร้าง URL ที่เหมาะสมเพื่อให้มนุษย์และเครื่องมือค้นหามีแนวคิดที่ดีเกี่ยวกับสิ่งที่คาดหวังบนหน้าเว็บ
2. การเพิ่มประสิทธิภาพไฟล์ robots.txt สามารถช่วยให้บอทการค้นหาเข้าใจวิธีรวบรวมข้อมูลหน้าในเว็บไซต์ของคุณ
3. ใช้ CDN เพื่อให้บริการเนื้อหาแบบคงที่ทั้งหมด เช่น CSS, JS, แบบอักษร เป็นต้น และใช้รูปภาพที่ตอบสนองเพื่อลดเวลาในการโหลด

เราสามารถแก้ไขปัญหาต่างๆ ที่อธิบายไว้ข้างต้นได้โดยใช้การแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) หรือการแสดงผลล่วงหน้า เราจะทบทวนแนวทางเหล่านี้ด้านล่าง

ป้อน Isomorphic React

คำจำกัดความของพจนานุกรมของ isomorphic คือ “สอดคล้องหรือคล้ายกันในรูปแบบ”

ในแง่ React นี่หมายความว่า เซิร์ฟเวอร์มีรูปแบบคล้าย กับไคลเอนต์ กล่าวอีกนัยหนึ่ง คุณสามารถใช้ส่วนประกอบ React เดียวกันซ้ำบนเซิร์ฟเวอร์และไคลเอนต์ได้

วิธีการแบบ isomorphic นี้ทำให้เซิร์ฟเวอร์สามารถแสดงแอป React และส่งเวอร์ชันที่แสดงผลไปยังผู้ใช้และเครื่องมือค้นหาของเรา เพื่อให้พวกเขาสามารถดูเนื้อหาได้ทันทีในขณะที่ JavaScript โหลดและดำเนินการในพื้นหลัง

กรอบงานเช่น Next.js หรือ Gatsby ได้ทำให้แนวทางนี้เป็นที่นิยม เราควรสังเกตว่าส่วนประกอบ isomorphic อาจดูแตกต่างจากส่วนประกอบ React ทั่วไปอย่างมาก ตัวอย่างเช่น พวกเขาสามารถรวมรหัสที่ทำงานบนเซิร์ฟเวอร์แทนที่จะเป็นไคลเอนต์ พวกเขาสามารถรวมความลับของ API ได้ (แม้ว่ารหัสเซิร์ฟเวอร์จะถูกถอดออกก่อนที่จะส่งไปยังไคลเอนต์)

ประเด็นหนึ่งที่ควรทราบคือเฟรมเวิร์กเหล่านี้ตัดทอนความซับซ้อนออกไปมากมาย แต่ยังแนะนำวิธีการเขียนโค้ดตามความคิดเห็นด้วย เราจะเจาะลึกการแลกเปลี่ยนประสิทธิภาพเพิ่มเติมในบทความนี้

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

ตัวชี้วัดสำหรับประสิทธิภาพของเว็บไซต์

ลองตรวจสอบปัจจัยบางอย่างที่เสิร์ชเอ็นจิ้นใช้ในการจัดอันดับเว็บไซต์

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

• ควรโหลดอย่างรวดเร็ว
• ผู้ใช้ควรสามารถเข้าถึงเนื้อหาได้โดยไม่ต้องรอนานเกินไป
• ควรโต้ตอบกับการกระทำของผู้ใช้ตั้งแต่เนิ่นๆ
• ไม่ควรดึงข้อมูลที่ไม่จำเป็นหรือรันโค้ดราคาแพงเพื่อป้องกันการระบายข้อมูลหรือแบตเตอรี่ของผู้ใช้

คุณลักษณะเหล่านี้จับคู่กับเมตริกต่อไปนี้โดยคร่าวๆ:

• TTFB : Time to First Byte – เวลาระหว่างการคลิกลิงก์กับเนื้อหาแรกที่เข้ามา
• LCP : Largest Contentful Paint – เวลาที่บทความที่ร้องขอปรากฏให้เห็น Google แนะนำให้เก็บค่านี้ไว้ไม่เกิน 2.5 วินาที
• TTI : Time To Interactive – เวลาที่หน้าเว็บกลายเป็นแบบโต้ตอบ (ผู้ใช้สามารถเลื่อน คลิก ฯลฯ)
• ขนาด ชุดรวม – จำนวนไบต์ทั้งหมดที่ดาวน์โหลดและโค้ดที่ดำเนินการก่อนที่หน้าเว็บจะมองเห็นได้อย่างสมบูรณ์และโต้ตอบได้

เราจะทบทวนเมตริกเหล่านี้อีกครั้งเพื่อให้เข้าใจมากขึ้นว่าเส้นทางการแสดงผลต่างๆ อาจส่งผลต่อแต่ละรายการอย่างไร

ต่อไป มาทำความเข้าใจเส้นทางการเรนเดอร์ที่แตกต่างกันสำหรับนักพัฒนา React

เส้นทางการแสดงผล

เราสามารถแสดงแอปพลิเคชัน React ในเบราว์เซอร์หรือบนเซิร์ฟเวอร์ และสร้างผลลัพธ์ที่แตกต่างกัน

สองฟังก์ชันเปลี่ยนแปลงอย่างมากระหว่างแอปที่แสดงผลฝั่งไคลเอ็นต์และเซิร์ฟเวอร์ ได้แก่ การกำหนดเส้นทาง และ การแยกโค้ด เรามาดูสิ่งเหล่านี้ด้านล่างอย่างละเอียดยิ่งขึ้น

การแสดงผลฝั่งไคลเอ็นต์ (CSR)

การเรนเดอร์ฝั่งไคลเอ็นต์เป็น พาธ การเรนเดอร์เริ่มต้นสำหรับ React SPA เซิร์ฟเวอร์จะให้บริการ แอปเชลล์ ที่ไม่มีเนื้อหาใดๆ เมื่อเบราว์เซอร์ดาวน์โหลด แยกวิเคราะห์ และรันซอร์ส JavaScript ที่รวมอยู่ เนื้อหา HTML จะถูกเติมหรือ แสดงผล

ฟังก์ชันการกำหนดเส้นทางได้ รับการจัดการโดยแอปไคลเอ็นต์ โดยการจัดการประวัติเบราว์เซอร์ ซึ่งหมายความว่ามีการให้บริการไฟล์ HTML เดียวกันโดยไม่คำนึงถึงเส้นทางที่มีการร้องขอ และไคลเอ็นต์จะอัปเดตสถานะการดูหลังจากที่แสดงผลแล้ว

การแยกรหัสค่อนข้างตรงไปตรงมา คุณสามารถแบ่งรหัสของคุณโดยใช้การนำเข้าแบบไดนามิกหรือ React.lazy เพื่อให้โหลดเฉพาะการพึ่งพาที่จำเป็นตามเส้นทางหรือการกระทำของผู้ใช้

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

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

การแสดงผลฝั่งไคลเอ็นต์ด้วยข้อมูล Bootstrapped (CSRB)

พิจารณาสถานการณ์เดียวกันกับ CSR แต่แทนที่จะดึงข้อมูลหลังจากแสดงผล DOM สมมติว่าเซิร์ฟเวอร์ส่งข้อมูลที่เกี่ยวข้องซึ่งบูตสแตรปภายใน HTML ที่ให้บริการ

เราสามารถรวมโหนดที่มีลักษณะดังนี้:

 <script type="application/json"> {"title": "My blog title", "comments":["comment 1","comment 2"]} </script>

และแยกวิเคราะห์เมื่อส่วนประกอบติดตั้ง:

 var data = JSON.parse(document.getElementById('data').innerHTML);

เราเพิ่งช่วยตัวเองเดินทางไปกลับเซิร์ฟเวอร์ เราจะเห็นการประนีประนอมในอีกสักครู่

การแสดงผลฝั่งเซิร์ฟเวอร์เป็นเนื้อหาแบบคงที่ (SSRS)

ลองนึกภาพสถานการณ์ที่เราจำเป็นต้องสร้าง HTML ทันที

ตัวอย่างเช่น หากเรากำลังสร้างเครื่องคำนวณออนไลน์และผู้ใช้ออกคำสั่ง sort /calculate/34+15 (ไม่เว้น URL ที่เป็นค่า Escape) เราจำเป็นต้องประมวลผลการสืบค้น ประเมินผลลัพธ์ และตอบกลับด้วย HTML ที่สร้างขึ้น

HTML ที่เราสร้างขึ้นนั้นค่อนข้างเรียบง่ายในโครงสร้าง และเราไม่ต้องการ React เพื่อจัดการและจัดการ DOM เมื่อแสดงผล HTML ที่สร้างขึ้น

ดังนั้นเราจึงให้บริการเนื้อหา HTML และ CSS เท่านั้น คุณสามารถใช้เมธอด renderToStaticMarkup เพื่อทำสิ่งนี้ได้

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

การแสดงผลฝั่งเซิร์ฟเวอร์ด้วย Rehydration (SSRH)

ลองนึกภาพสถานการณ์เดียวกันกับที่อธิบายไว้ข้างต้น แต่คราวนี้เราต้องการแอปพลิเคชัน React ที่ทำงานได้อย่างสมบูรณ์บนไคลเอนต์

เราจะทำการเรนเดอร์ ครั้งแรก บนเซิร์ฟเวอร์และส่งกลับเนื้อหา HTML พร้อมกับไฟล์ JavaScript React จะ เติมน้ำ ให้กับมาร์กอัปที่แสดงโดยเซิร์ฟเวอร์ และแอปพลิเคชันจะทำงานเหมือนแอปพลิเคชัน CSR นับจากนี้เป็นต้นไป

React มีเมธอดในตัวเพื่อดำเนินการเหล่านี้

คำขอแรกได้รับการจัดการโดยเซิร์ฟเวอร์ และการเรนเดอร์ที่ตามมาจะได้รับการจัดการโดยไคลเอ็นต์ ดังนั้นแอปดังกล่าวจึงเรียกว่าแอป Universal React (แสดงผลทั้งบนเซิร์ฟเวอร์และไคลเอ็นต์) รหัสสำหรับจัดการเส้นทางอาจถูกแยกออก (หรือทำซ้ำ) บนไคลเอนต์และเซิร์ฟเวอร์

การแยกรหัสนั้นค่อนข้างยุ่งยากเนื่องจาก ReactDOMServer ไม่รองรับ React ขี้เกียจ ดังนั้นคุณอาจต้องใช้บางอย่างเช่น Loadable Components

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

นี่คือจุดที่เฟรมเวิร์กอย่าง NextJS ปรากฏขึ้น พวกเขาปกปิดความซับซ้อนที่เกี่ยวข้องกับการกำหนดเส้นทางและการแยกโค้ดใน SSRH และมอบประสบการณ์นักพัฒนาที่ราบรื่นยิ่งขึ้น

วิธีการนี้ให้ผลลัพธ์ที่หลากหลายเมื่อพูดถึงประสิทธิภาพของหน้า ซึ่งเราจะสังเกตเห็นในอีกสักครู่

การแสดงผลล่วงหน้าเป็นเนื้อหาคงที่ (PRS)

จะเกิดอะไรขึ้นถ้าเราสามารถแสดงหน้าเว็บก่อนที่ผู้ใช้จะร้องขอได้ ซึ่งสามารถทำได้ในเวลาที่สร้างหรือแบบไดนามิกเมื่อข้อมูลเปลี่ยนแปลง

จากนั้น เราสามารถแคชเนื้อหา HTML ที่เป็นผลลัพธ์บน CDN และให้บริการเร็วขึ้นมากเมื่อผู้ใช้ร้องขอ

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

การแสดงผลล่วงหน้าด้วย Rehydration (PRH)

เราอาจต้องการให้ HTML ที่แสดงผลล่วงหน้าของเราเป็นแอป React ที่ทำงานได้อย่างสมบูรณ์เมื่อไคลเอนต์แสดงผล

หลังจากส่งคำขอครั้งแรก แอปพลิเคชันจะทำงานเหมือนแอป React มาตรฐาน โหมดนี้คล้ายกับ SSRH ที่อธิบายไว้ข้างต้น ในแง่ของการกำหนดเส้นทางและฟังก์ชันการแยกโค้ด

เมทริกซ์ประสิทธิภาพ

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

ในเมทริกซ์นี้ เรากำหนดคะแนนให้กับแต่ละเส้นทางการแสดงผลโดยพิจารณาจากประสิทธิภาพของเมตริก

คะแนนมีตั้งแต่ 1 ถึง 5:

• 1 = ไม่น่าพอใจ
• 2 = แย่
• 3 = ปานกลาง
• 4 = ดี
• 5 = ยอดเยี่ยม

ประเด็นที่สำคัญ

การแสดงผลล่วงหน้าไปยังเนื้อหาแบบคงที่ (PRS) นำไปสู่เว็บไซต์ที่ มีประสิทธิภาพสูงสุด ในขณะที่การเรนเดอร์ฝั่งเซิร์ฟเวอร์ด้วยการดื่มน้ำ (SSRH) หรือการแสดงผลฝั่งไคลเอ็นต์ (CSR) อาจทำให้ได้ผลลัพธ์ที่ไม่ดีนัก

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

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

การอ่านและการพิจารณาเพิ่มเติม

ในขณะที่ฉันพยายามครอบคลุมเทคนิคที่ได้รับความนิยมในปัจจุบัน แต่นี่ไม่ใช่การวิเคราะห์ที่ละเอียดถี่ถ้วน ฉันขอแนะนำอย่างยิ่งให้อ่านบทความนี้ซึ่งนักพัฒนาซอฟต์แวร์จาก Google พูดคุยเกี่ยวกับเทคนิคขั้นสูงอื่นๆ เช่น การแสดงเซิร์ฟเวอร์สตรีมมิง การเรนเดอร์ trisomorphic และการแสดงผลแบบไดนามิก (ให้การตอบสนองที่แตกต่างกันต่อโปรแกรมรวบรวมข้อมูลและผู้ใช้)

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