Smashing Magazine จัดการเนื้อหาอย่างไร: การโยกย้ายจาก WordPress ไปยัง JAMstack

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

ทุกครั้งที่นักพัฒนาพูดถึง WordPress เปอร์เซ็นต์ส่วนแบ่งการตลาดจะเปลี่ยนไป “ 20% ของไซต์ทั้งหมดอยู่บน WordPress! ” “ 40% ของไซต์ทั้งหมดอยู่บน WordPress! ” ไม่ว่าเปอร์เซ็นต์จะเป็นเท่าใด ข้อความก็เหมือนกัน: ในแง่ของการยอมรับ WordPress นั้นมีขนาดใหญ่มาก

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

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

มาขุดกันเถอะ!

ทำไม?

ในปี 2015 Mathias Biilmann ผู้ร่วมก่อตั้ง Netlify และ Vitaly Friedman ผู้ก่อตั้ง Smashing ได้พูดคุยถึงร้านค้า เมื่อสถาปัตยกรรม JAMstack เริ่มทำงาน Smashing ก็มีความสนใจในแนวคิดเรื่อง stack มากขึ้น Vitaly และ Markus (อดีตกรรมการผู้จัดการของ Smashing) ถาม Matt ว่าจะเกิดอะไรขึ้นหาก Smashing ย้ายจากไซต์ WordPress/LAMPstack แบบเดิมไปเป็นสถาปัตยกรรม JAMstack

ในการทดลอง Matt ได้คัดลอก HTML ทั้งหมดจาก Smashing และโฮสต์ไว้บน Netlify โดยส่งเนื้อหาแบบสแตติกจาก CDN ผลลัพธ์ที่ได้นั้นน่าดึงดูด — เวอร์ชันสแตติกนั้นเร็วกว่าโดยเฉลี่ยถึงหกเท่า!

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

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

เวทีจึงถูกจัด Smashing Magazine ได้ย้ายไปยัง JAMstack — ไปยัง Netlify ในฐานะแพลตฟอร์มโดยเฉพาะ ในระยะเวลา 10 ปีของการดำเนินงาน Smashing ได้เติบโตจากสิ่งพิมพ์ออนไลน์เล็กๆ ไปสู่บล็อก WordPress ขนาดใหญ่ โดยขายสิ่งต่างๆ เช่น หนังสือ ตั๋วการประชุม และเวิร์กช็อป

มีบางไซต์นี้:

• บล็อก WordPress
• คณะกรรมการงาน Rails
• ร้านค้า Shopify
• CMS อื่นสำหรับไซต์การประชุม

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

ความน่าเชื่อถือ

Smashing ประสบความสำเร็จในสิ่งที่แพลตฟอร์มอื่น ๆ ใฝ่ฝัน: บทความที่แบ่งปันอย่างกว้างขวางผ่านชุมชนขนาดใหญ่ อย่างไรก็ตาม เมื่อถึงจุดเปลี่ยนของการเข้าชมสำหรับโพสต์ Smashing มักมีปัญหาเรื่องไฟดับ เพื่อลดปัญหานี้ มีการใช้ปลั๊กอิน WordPress อย่างหนักในสแต็กของพวกเขา แต่พวกเขายังคงพยายามรักษาตัวชี้วัดเวลาทำงานที่ดี

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

การให้บริการผ่าน CDN ยังช่วยให้ Smashing นอนหลับได้ง่ายขึ้นเล็กน้อยในแง่ของความปลอดภัย wp-login.php เป็นแหล่งที่มาของช่องโหว่ด้านความปลอดภัยและเวกเตอร์การโจมตีมาเป็นเวลานาน ไม่สามารถเข้าถึงเนื้อหาที่สร้างไว้ล่วงหน้าในลักษณะเดียวกันและช่องโหว่ด้านความปลอดภัยไม่แพร่หลายเท่าที่ควร

แคช Invalidation

Smashing วนเวียนอยู่ในปลั๊กอินแคชของ WordPress ทุกตัว ด้วยผลลัพธ์ที่หลากหลายและปัญหามากมาย Vitaly Friedman แห่ง Smashing กล่าวว่า

“ปัญหาหลักที่เรามีเกี่ยวข้องกับ 'ข้อผิดพลาดในการสร้างการเชื่อมต่อฐานข้อมูล' ที่เรามีทุกสัปดาห์เว้นสัปดาห์ และเราลองใช้ปลั๊กอินแคช WordPress ทุกตัวที่มีอยู่จริง ประสิทธิภาพค่อนข้างโอเค (โดยรวม) แต่เราต้องการปรับปรุงให้ดียิ่งขึ้นไปอีก นอกจากนี้ เราต้องการเปิดตัวการเป็นสมาชิกและเชื่อมต่อข้อเสนอต่างๆ เช่น การประชุม ประกาศรับสมัครงาน บทความ หนังสือ eBooks ด้วยแพลตฟอร์มเดียว และเป็นเรื่องยากมากที่จะบรรลุความสำเร็จด้วย WordPress”

การย้ายไปยัง Netlify ทำให้ทีม Smashing สามารถเห็นการปิดใช้งานแคชทันทีในขณะที่ให้บริการเนื้อหาแคชและเนื้อหาที่มีประสิทธิภาพ โดยไม่มีค่าใช้จ่ายเพิ่มเติม

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

เวิร์กโฟลว์

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

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

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

เมื่อเขียนและแปลงแล้ว จะถูกโหลดลงใน repo ใหม่ใน GitHub และใช้ Netlify CMS แทน สิ่งที่ทำให้ Netlify CMS ไม่เหมือนใครคือมันมีน้ำหนักเบา และรวมตัวแก้ไขเนื้อหาเข้ากับเวิร์กโฟลว์ Git ซึ่งหมายความว่าจะดึงและให้บริการไฟล์ markdown จาก git repo แทนฐานข้อมูลอย่างแท้จริง นอกจากนี้ Netlify CMS ยังเป็นแพลตฟอร์มที่ไม่เชื่อเรื่องพระเจ้าและทำงานร่วมกับ (เกือบ) ตัวสร้างไซต์แบบคงที่และไซต์ที่จัดเก็บไว้ใน GitHub

ในเวลานั้น Sara Soueidan ทำงานให้กับ Smashing ในฐานะนักพัฒนาฟรอนต์เอนด์อิสระในการออกแบบใหม่ เธอสร้างไลบรารีของส่วนประกอบเพื่อสร้างสถาปัตยกรรมส่วนหน้า และตั้งข้อสังเกตว่าการทำงานนี้ง่ายขึ้นมากเพียงใด เพราะเธอทำงานโดยตรงใน git แม้กระทั่งตอนที่ทำงานกับ CMS

“ทุกสิ่งที่ฉันผลักไปที่ที่เก็บจะถูกนำไปใช้กับไลบรารีรูปแบบโดยตรง ซึ่งหมายความว่าคุณไม่จำเป็นต้องดูแลองค์ประกอบสองชุดที่แตกต่างกัน... ความต่อเนื่องแบบนี้เยี่ยมมาก! ทั้งหมดที่ฉันต้องทำคือเขียน HTML, CSS และ JavaScript แล้วกดไปที่ repo และทุกอย่างทำงานเหมือนเวทมนตร์ เวิร์กโฟลว์นั้นยอดเยี่ยมมาก”

ทั้งหมดนี้กล่าวว่า Netlify CMS บางครั้งอาจเบาเกินไปสำหรับกรณีการใช้งานปริมาณการใช้งานและขนาดที่สูง Smashing มักมีผู้เขียนรับเชิญและกองบรรณาธิการเต็มรูปแบบ ฟีเจอร์มากมายที่ WordPress มอบให้นั้นมีประโยชน์จริง ๆ สำหรับสภาพแวดล้อมที่มีการทำงานร่วมกันสูงประเภทนี้

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

ตัวเลือกกรอบงาน

ในต้นแบบเริ่มต้นที่ Matt Biilmann สร้างขึ้น เขาเขียนทุกอย่างด้วย Preact ขั้นต่ำ จับคู่กับ Hugo เนื่องจากเขาให้ความสำคัญกับประสิทธิภาพเป็นอย่างมาก เขาแค่ใช้อุปกรณ์ประกอบฉากและเก็บทุกอย่างที่เบามาก เมื่อเขายกเลิกโปรเจ็กต์เพื่อให้ Ilya Pukhalski ผู้พัฒนาของ Smashing ดูแล เขาพบว่า Preact ขาดคุณสมบัติบางอย่างที่พวกเขาขาดหายไปเพื่อใช้ประโยชน์จากระบบนิเวศของ React ในที่สุด ประโยชน์ของ Redux และไลบรารีอื่นๆ ก็มีมากกว่าต้นทุน

เมื่อไตร่ตรองแล้ว Matt กล่าวว่าเขาจะใช้ Vue ซึ่งตอนนั้นมีส่วนแบ่งการตลาดไม่มากพอ (ฉันสาบานว่าฉันไม่ได้บอกให้เขาพูดแบบนั้น) ฉันถามคำถามที่ชัดเจน: ทำไมไม่ Svelte? เนื่องจากผู้ที่ใส่ใจในประสิทธิภาพมักจะเข้าถึงห้องสมุดนั้น เขากล่าวว่า Svelte ยังไม่มีระบบนิเวศที่ Vue มีอยู่

เมื่อ Matt ไตร่ตรองว่าเขาจะยังใช้ Hugo อยู่หรือไม่ เขาบอกว่าเขารัก Hugo แต่สิ่งที่เขาพบว่ายากสำหรับโครงการนี้โดยเฉพาะคือมันไม่มีระบบปลั๊กอินเพียงพอ - การสร้างโฆษณาแบนเนอร์และสิ่งต่างๆ ธรรมชาตินั้นไม่สามารถตั้งโปรแกรมได้เพียงพอกับ Hugo และเขาจำเป็นต้องฉีดสคริปต์เพื่อให้สำเร็จ สคริปต์เหล่านี้มีแนวโน้มที่จะทำให้กระบวนการสร้างช้าลง ที่กล่าวว่าเรายังคงใช้ Hugo สำหรับไซต์ของเราเองที่ netlify.com และชอบมัน – ข้อแม้นี้มีความเฉพาะเจาะจงอย่างยิ่งต่อความต้องการของไซต์ของ Smashing โดยเฉพาะอย่างยิ่ง

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

สร้างไซต์ขนาดใหญ่

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

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

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

สิ่งที่ Netlify ทำคือสร้างโฟลเดอร์ /production-articles ขนาดใหญ่ ซึ่งมีบทความมากกว่า 1,000 บทความที่พวกเขาโฮสต์อยู่แล้วจำนวนมาก จากนั้นจึงสร้างไดเร็กทอรีการทำงานแยกต่างหากที่เรียกว่า content/articles ซึ่งสามารถวางบทความที่กำลังสร้างและแก้ไขได้

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

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

โอเพ่นซอร์ส APIs

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

• โกเทล
  API และเครื่องมือสร้างสำหรับจัดการความคิดเห็นจำนวนมาก
• GoCommerce
  Go-based API ขนาดเล็กสำหรับไซต์อีคอมเมิร์ซที่จัดการคำสั่งซื้อและการชำระเงิน
• GoTrue
  API โอเพ่นซอร์สขนาดเล็กที่เขียนใน Golang ที่สามารถทำหน้าที่เป็นบริการ API แบบยืนด้วยตนเองสำหรับการจัดการการลงทะเบียนผู้ใช้และการตรวจสอบสิทธิ์สำหรับโครงการ อิงตาม OAuth2 และ JWT และจะจัดการการสมัครของผู้ใช้ การตรวจสอบสิทธิ์ และข้อมูลผู้ใช้ที่กำหนดเอง

ชิ้นส่วนเหล่านี้แต่ละชิ้นจำเป็นต้องมีการโยกย้ายและปัจจัยเฉพาะของตนเอง และในขณะที่สิ่งเหล่านี้ไม่อยู่ในขอบเขตสำหรับบทความนี้ สิ่งเหล่านี้ทั้งหมดถูกกล่าวถึงในหนังสือฟรีที่ Matt ร่วมเขียนในชื่อ " Modern Web Development on the JAMstack " นอกจากนี้ เราจะเจาะลึกข้อมูลในลักษณะนี้ — พร้อมตัวอย่างที่ใช้งานได้ — ในการค้นหาและการตรวจสอบสิทธิ์ในโพสต์ต่อๆ ไป

บทสรุป

การอพยพย้ายถิ่นไปอย่างว่องไว อย่างยอดเยี่ยม? เอ่อ… ผ่านไปด้วยดี Smashing ไม่ได้ถูกลงโทษสำหรับความสำเร็จของตัวเอง — เมื่อมีบทความยอดนิยมเข้ามา พวกเขาสามารถให้บริการเนื้อหาได้อย่างสม่ำเสมอ ไม่มีการประกันตัวกับงานจำนวนมากอีกต่อไป นอกจากนี้ การย้ายไปยังโครงสร้างพื้นฐาน JAMstack ยังทำให้ประสิทธิภาพและความปลอดภัยดีขึ้นอีกด้วย

Markus Seyfferth อดีต CEO ของ Smashing Magazine กล่าวว่า:

“เวลาในการโหลดครั้งแรกเร็วกว่าเมื่อก่อนมาก… ก่อนที่เราจะต้องรอให้ไฟล์ HTML แสดงผลเป็นเวลา 800 มิลลิ วินาที และตอนนี้ก็ 80 มิลลิวินาที ”

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