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

เผยแพร่แล้ว: 2021-05-27

เล็กน้อยเกี่ยวกับ React

React เป็นไลบรารี JavaScript ส่วนหน้าแบบโอเพ่นซอร์สซึ่งสร้างและดูแลโดยชุมชนนักพัฒนา Facebook ใช้เพื่อสร้างส่วนต่อประสานผู้ใช้หรือส่วนประกอบ UI

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

การเดินทางของหน้าเว็บ | จากเซิร์ฟเวอร์สู่เบราว์เซอร์ของคุณ

เพื่อทำความเข้าใจว่า Server Side Rendering คืออะไร ก่อนอื่นคุณต้องเข้าใจภาพรวมว่าหน้าเว็บนั้นปรากฏบนหน้าจอของคุณอย่างไร ซึ่งจะอธิบายโดยไดอะแกรมด้านล่าง:

ssr-with-react-webpage-server-to-browser
  1. เมื่อใดก็ตามที่คุณพิมพ์ URL ของเว็บไซต์หรือคลิกลิงก์ไปยังเว็บไซต์ เบราว์เซอร์ของคุณจะส่งคำขอสำหรับไฟล์บางไฟล์ไปยังเซิร์ฟเวอร์ที่เหมาะสม ซึ่งระบุโดย URL
  2. เซิร์ฟเวอร์ส่งไฟล์บางไฟล์ เช่น ไฟล์ HTML และ JavaScript ไปยังเบราว์เซอร์ของคุณ
  3. เบราว์เซอร์ของคุณดาวน์โหลดและ 'แสดงผล' หรือประมวลผลไฟล์เหล่านี้ และคุณสามารถดูและโต้ตอบกับหน้าเว็บที่คุณร้องขอได้

นี่เป็นการทำให้การเดินทางของเว็บเพจง่ายขึ้นอย่างมาก แต่เป็นคำนำที่ดีพอที่จะอธิบายขั้นตอนย่อยต่างๆ และวิธีการต่างๆ (รวมถึง Server Side Rendering) เพื่อทำงานนี้ให้สำเร็จ

การเดินทางของหน้าเว็บแสดงผลฝั่งไคลเอ็นต์ 'ปกติ'

เจาะลึกลงไปในกระบวนการที่กล่าวถึงในส่วนก่อนหน้านี้ เรามีเทคนิคที่เรียกว่า Client Side Rendering หรือ CSR ซึ่งใช้งานมาเป็นเวลานาน เพื่อแสดงเว็บไซต์บนหน้าจอของผู้ใช้ สิ่งนี้อธิบายไว้ในแผนภาพต่อไปนี้:

ssr-with-react-csr-webpage-rendering
  1. ในการพิมพ์ URL ของเว็บไซต์หรือคลิกลิงก์ไปยังเว็บไซต์ เบราว์เซอร์ของคุณจะส่งคำขอสำหรับไฟล์บางไฟล์ไปยังเซิร์ฟเวอร์ที่เหมาะสม ซึ่งระบุโดย URL
  2. เซิร์ฟเวอร์ส่งไฟล์ HTML ซึ่งมีข้อมูลอ้างอิงไปยังสินทรัพย์อื่นๆ เช่น ไฟล์รูปภาพ ไฟล์ CSS และไฟล์ JavaScript
  3. เบราว์เซอร์ส่งคำขออีกครั้งไปยังเซิร์ฟเวอร์และดาวน์โหลดไฟล์ทั้งหมด รวมถึงไฟล์ CSS และ JavaScript ที่อ้างอิงในไฟล์ HTML
    1. นี่อาจเป็นปัจจัยสนับสนุนในการเพิ่มเวลาในการโหลดของเว็บไซต์หากผู้ใช้มีการเชื่อมต่อที่ไม่ดีและไฟล์ JavaScript มีขนาดใหญ่
  4. เมื่อไฟล์เหล่านี้ถูกดาวน์โหลดโดยเบราว์เซอร์ เบราว์เซอร์จะเรียกใช้งานเฟรมเวิร์กหรือไลบรารี (เช่น React) และแยกวิเคราะห์ไฟล์ JavaScript ซึ่งมีหน้าที่ทำให้หน้าเว็บโต้ตอบได้
    1. จากมุมมองการปรับความเร็วให้เหมาะสม ประเด็นนี้ขึ้นอยู่กับเครื่องไคลเอ็นต์ และหากไคลเอ็นต์เป็นฮาร์ดแวร์ที่ใช้พลังงานต่ำ อาจต้องใช้เวลามาก
    2. ผู้ใช้ยังคงเห็นหน้าจอการโหลดเมื่อทำตามขั้นตอนเหล่านี้
  5. ในที่สุดหน้าเว็บก็โหลดอย่างสมบูรณ์และผู้ใช้สามารถดูและโต้ตอบกับหน้าเว็บได้

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

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

การเดินทางของหน้าเว็บการแสดงผลฝั่งเซิร์ฟเวอร์

อธิบายเป็นบรรทัดเดียวว่า Server Side Rendering หรือ SSR เป็นกระบวนการของการนำเว็บไซต์กรอบงาน JavaScript ฝั่งไคลเอ็นต์และแสดงผลเป็น HTML และ CSS แบบคงที่บนเซิร์ฟเวอร์แทนที่จะเป็นไคลเอ็นต์ เช่นเดียวกับใน CSR

ด้านล่างนี้คือการแสดงรูปภาพของการเดินทางที่หน้าเว็บใช้ด้วย Server Side Rendering พร้อม React:

ssr-with-react-ssr-webpage-rendering-with-react
  1. ในการพิมพ์ URL ของเว็บไซต์หรือคลิกลิงก์ไปยังเว็บไซต์ เบราว์เซอร์ของคุณจะส่งคำขอสำหรับไฟล์บางไฟล์ไปยังเซิร์ฟเวอร์ที่เหมาะสม ซึ่งระบุโดย URL
  2. เซิร์ฟเวอร์ แทนที่จะส่งไฟล์ vanilla HTML เช่น CSR ให้แสดงแอปเป็นสตริงโดยใช้ฟังก์ชัน renderToString ที่นำเข้าจาก react-dom/server
    1. จากนั้นจะถูกฉีดเข้าไปในไฟล์ index.html และถูกส่งไปยังเบราว์เซอร์
    2. นี่คือจุดที่ปมของ SSR อยู่ที่การพูดตามหน้าที่ เนื่องจากเป็นที่ที่เซิร์ฟเวอร์แสดงหน้าเว็บ ไม่ใช่เครื่องไคลเอ็นต์
  3. เบราว์เซอร์แสดงไฟล์ HTML นี้ส่งผลให้มุมมองถูกเติมลงในเบราว์เซอร์
    1. อย่างไรก็ตาม นี่ยังไม่เป็นแบบโต้ตอบ แต่ผู้ใช้สามารถดูมุมมองสุดท้ายของหน้าเว็บได้
  4. เบราว์เซอร์ส่งคำขออีกครั้งไปยังเซิร์ฟเวอร์และดาวน์โหลดไฟล์ทั้งหมดที่อ้างอิงในไฟล์ HTML รวมถึงไฟล์ JavaScript
  5. เมื่อดาวน์โหลดสคริปต์ทั้งหมดแล้ว องค์ประกอบ React จะแสดงผลบนไคลเอนต์อีกครั้ง อย่างไรก็ตาม คราวนี้จะทำให้มุมมองที่มีอยู่ชุ่มชื้นแทนที่จะเขียนทับ
    1. มุมมอง 'การให้ความชุ่มชื้น' หมายความว่ามุมมองนั้นแนบตัวจัดการเหตุการณ์ใดๆ กับองค์ประกอบ DOM (Document Object Model) ที่แสดงผล แต่ยังคงองค์ประกอบ DOM ที่แสดงผลไว้เหมือนเดิม ด้วยวิธีนี้ สถานะขององค์ประกอบ DOM จะยังคงอยู่และไม่มีการรีเซ็ตมุมมองที่เกิดขึ้น
  6. ในที่สุด หน้าเว็บก็โหลดอย่างสมบูรณ์แล้ว และตอนนี้ผู้ใช้สามารถโต้ตอบกับหน้าเว็บที่สามารถดูได้จากขั้นตอนที่ 3 เอง

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

สิ่งนี้ไม่ได้ทำให้หน้าเว็บโหลดได้เร็วกว่าแอปที่ไม่ใช่ SSR แต่ให้ผู้ใช้ดูหน้าเว็บเมื่อไฟล์ JavaScript ดาวน์โหลดและแยกวิเคราะห์ในพื้นหลัง หลังจากนั้นหน้าเว็บจะกลายเป็นแบบโต้ตอบ ซึ่งหมายความว่า TTI เช่น Time To Interactive (นี่คือเวลาที่หน้าเว็บใช้ในการโต้ตอบอย่างสมบูรณ์ตั้งแต่เมื่อผู้ใช้ร้องขอหน้าเว็บ) มากกว่าเวลาที่ใช้ในการมองเห็นหน้าเว็บเล็กน้อย ในเบราว์เซอร์

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

ความเข้าใจผิดที่พบบ่อยเกี่ยวกับการทำงานของ SSR กับ React คือหลังจากการเปลี่ยนแปลงทุกครั้ง เช่น ผู้ใช้ร้องขอข้อมูลใหม่ เซิร์ฟเวอร์จะทำตามขั้นตอนทั้งหมดอีกครั้งและส่งไฟล์ HTML ที่มี UI ใหม่ไปยังเบราว์เซอร์ แต่นี่ไม่ใช่กรณี . อัปเดตหน้าเพียงบางส่วนเท่านั้น แม้ว่าการเรนเดอร์จะทำโดยเซิร์ฟเวอร์ แต่เอาต์พุตที่สรุปแล้วจะถูกแทรกเข้าไปใน DOM โดย 'ไฮเดรต' มัน ดังที่อธิบายไว้ก่อนหน้านี้

ssr-with-react-pros-cons-of-ssr

การแสดงผลฝั่งเซิร์ฟเวอร์ | เมื่อไรและเมื่อใดที่จะไม่ใช้

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

React ดีสำหรับ SSR อย่างไร?

React เป็นตัวเลือกที่ยอดเยี่ยมในการใช้ SSR เพราะมันรวมเอาแนวคิดของ DOM เสมือน (Document Object Model)

ซึ่งช่วยให้นักพัฒนาสามารถสร้างแอป React เวอร์ชันเสมือนและมีไว้ในเซิร์ฟเวอร์ได้

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

ดังนั้น เมื่อพิจารณาจากข้อเท็จจริงที่ว่าเวอร์ชันเสมือนนี้ตรงกับ HTML ที่เราส่งออกจากเซิร์ฟเวอร์แล้ว React จะไม่แสดงผลซ้ำ ซึ่งจะทำให้ Time To Interactive (TTI) ลดลง ส่งผลให้หน้าเว็บโหลด 'เร็วขึ้น'

SSR ทั้งวัน ทุกวัน!

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

นั่นคือสิ่งที่ Creole Studios เข้ามา เรามีผู้เชี่ยวชาญด้านเทคโนโลยีมากมาย คอยติดตามเทคโนโลยีใหม่ๆ เกือบทุกอย่างที่ปรากฏใน techverse เราจะเข้าใจความต้องการทางธุรกิจของคุณและมอบโซลูชันที่ปรับแต่งได้สำหรับคุณ ไม่ว่าจะเป็นแอป SSR หรือ CSR และมั่นใจได้เลยว่าคุณจะไม่ต้องกังวลอะไรเลยในขณะที่เราจัดการงานหนักให้คุณ ติดต่อเราและรับแนวคิดของคุณจากหัวของคุณเป็นแอพ!