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

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

สรุปผลการค้นพบความเร็วหน้าที่สำคัญ

• 29 % ของ เวลาในการโหลดในสหราชอาณาจักรไม่เป็นที่ยอมรับ ตามความคาดหวังของ Google: เกินเวลาสูงสุด 2.5 วินาที
• อย่างไรก็ตาม แนวโน้ม กำลังชี้ไปใน ทิศทางที่ถูกต้อง สัดส่วนของเว็บไซต์ที่รวดเร็วเพิ่มขึ้น 2 เปอร์เซ็นต์ในช่วงหลายเดือนที่ผ่านมา
• การเข้าถึงเว็บไซต์จาก สหราชอาณาจักรนั้นไม่เร็วเท่าที่ควร ยุโรปชั้นนำ ได้แก่ สวิตเซอร์แลนด์ สวีเดน นอร์เวย์ และเยอรมนี
• Jimdo แสดงให้เห็นว่า CMS บนคลาวด์สามารถมอบ ค่า Core Web Vitals ที่ดีมากได้ แต่โอเพ่นซอร์สก็สามารถทำได้เช่นกัน – Typo3 นั้นช้ากว่าเพียงเล็กน้อยเท่านั้น
• ไม่มี CMS ใดที่ ช้ากว่า Wix ที่ใส่ช้อนไม้ในหมวด CMS อันดับสุดท้ายรองจาก WordPress แสดงให้เห็นว่าโซลูชันบนคลาวด์ไม่ได้รวดเร็วเสมอไป
• Lightspeed นำเสนอระบบร้านค้าที่รวดเร็วมาก Shopify อยู่ในครึ่งล่างของรายการเท่านั้น WooCommerce add-on ของ WordPress เป็นระบบร้านค้าที่ช้าที่สุด
• ภาษาการเขียนโปรแกรม ไม่สำคัญสำหรับเทคโนโลยีเว็บ: มีเฟรมเวิร์กที่รวดเร็วใน Ruby (บน Rails), PHP (Yii & Laravel), Python (Django) และภาษาอื่นๆ เฉพาะ Angular เท่านั้นที่ช้าจริงๆ
• AMP ไม่ ได้นำไปสู่เว็บไซต์ที่รวดเร็วโดยอัตโนมัติ มีเพียง 70% ของหน้า AMP ที่ตรงตามมาตรฐาน Core Web Vitals

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

เหตุใดเวลาในการโหลดเว็บไซต์จึงสำคัญ

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

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

ประสิทธิภาพของเว็บไซต์วัดได้อย่างไร?

มีเครื่องมือและแนวทางที่หลากหลายในการทำให้ประสบการณ์ของผู้ใช้บนเว็บไซต์สามารถวัดผลได้ ด้วย Core Web Vitals Google ได้จัดเตรียมข้อมูลสำคัญสามประการที่ได้มาตรฐานและเปรียบเทียบได้ Web Vitals หลักเหล่านี้จะกลายเป็นปัจจัยในการจัดอันดับในปีหน้า (2021) ดังนั้นพวกเขาจะมีอิทธิพลโดยตรงต่อตำแหน่งของหน้าในผลลัพธ์ของ Google

เราได้แสดงประวัติความเป็นมา วิธีการวัดต่างๆ และวิธีการปรับปรุง Web Vitals หลักสามประการในบทความอื่นแล้ว นี่เป็นเพียงการเตือนความจำสั้นๆ:

• Largest Contentful Paint (LCP) – เวลาที่ใช้ในการโหลดเนื้อหาส่วนที่ใหญ่ที่สุด ดี: น้อยกว่า 2.5 วินาที
• First Input Delay (FID) – เวลาจนกว่าผู้ใช้จะสามารถโต้ตอบกับเพจได้ ดี: น้อยกว่า 0.1 วินาที
• Cumulative Layout Shift (CLS) – ตัวบ่งชี้ว่าเลย์เอาต์เปลี่ยนไปมากน้อยเพียงใดระหว่างการโหลด ดี: น้อยกว่า 0.1

ในการวิเคราะห์นี้ เราใช้ค่าสำหรับ Largest Contenful Paint ( LCP ) ยกเว้นไดอะแกรมแรกที่แสดงการวัดทั้งสาม จากสาม Core Web Vitals นี่เป็นค่าพื้นฐานสำหรับการวัดเวลาในการโหลดหน้า

สหราชอาณาจักร – 29% ของไซต์ไม่เร็วพอ

สำหรับขั้นตอนแรก เราวิเคราะห์ว่าการเข้าถึงเว็บไซต์จากสหราชอาณาจักรดำเนินการอย่างไรสำหรับตัวเลขหลักสามประการของ Core Web Vitals Google ได้กำหนดสามส่วนสำหรับแต่ละส่วน:

• ดี (สีเขียว ) หากมูลค่าอยู่ในความคาดหมายของ Google
• ต้องการการปรับปรุง (สีเหลือง) หากเกินความคาดหมาย แต่ยังไม่เบี่ยงเบนไปจากพวกเขาและ
• แย่ (สีแดง) หากค่าที่วัดได้นั้นอยู่นอกเป้าหมายได้ดี

บนพื้นฐานนี้ นี่คือผลลัพธ์สำหรับสหราชอาณาจักรโดยอิงจาก Core Web Vitals สามประการ

ด้วย Largest Contentful Paint (LCP) 70% ของผลลัพธ์ทั้งหมดนั้นดีอยู่แล้ว Google ให้คะแนน 12.9% ของผลลัพธ์ว่าแย่ LCP เป็นส่วนสำคัญของ Core Web Vitals เนื่องจากส่วนใหญ่สะท้อนถึงเวลาในการโหลดจริงโดยตรง

First Input Delay (FID ) กล่าวคือ เวลาจนถึงการโต้ตอบ มีค่าที่ดีที่สุด: 90% ของการเข้าถึงนั้นดีอยู่แล้ว และมีเพียง 2% เท่านั้นที่ได้รับการจัดอันดับว่าแย่โดย Google หากคุณยังมีงานต้องทำที่นี่ คุณจะต้องรีบเร่งเพื่อไม่ให้ถูกทิ้งไว้ข้างหลัง

ด้วย Cumulative Layout Shift (CLS) การเปลี่ยนเลย์เอาต์ระหว่างกระบวนการโหลด จะสังเกตได้ว่าเว็บไซต์ผ่านการทดสอบนี้ (สีเขียว) หรือล้มเหลวโดยสิ้นเชิง (สีแดง) – มีเพียงไม่กี่กรณีที่จำเป็นต้องปรับปรุงเท่านั้น (สีเหลือง).

แนวโน้มเชิงบวก: เว็บไซต์เริ่มเร็วขึ้นเล็กน้อยทุกเดือน

เพื่อให้เข้าใจว่าเวลาในการโหลดเปลี่ยนแปลงไปอย่างไรในช่วงสองสามเดือนที่ผ่านมา การประเมินครั้งถัดไปจะแสดงการ เปลี่ยนแปลงรายเดือน ของ Largest Contentful Paint ในช่วงหลายเดือนที่ผ่านมา:

ความคืบหน้าไม่รวดเร็ว แต่มี แนวโน้มเชิงบวก เล็กน้อย ตั้งแต่เดือนพฤศจิกายน 2019 จำนวนการวัดที่ผิดพลาดได้ลดลงประมาณ 2 จุดเปอร์เซ็นต์ และการวัดที่ดีได้เพิ่มขึ้นจาก 73% เป็น 75% ทิศทางเป็นบวก: เว็บไซต์เริ่มเร็วขึ้นเล็กน้อยทุกเดือน

แท็บเล็ตเป็นเพียงเดสก์ท็อปที่ไม่ดี

เรามาวิเคราะห์กันต่อไป โดยแยกการประเมินตาม ประเภทของอุปกรณ์ เดสก์ท็อป โทรศัพท์มือถือ และแท็บเล็ต นี่คือผลลัพธ์:

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

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

อันดับที่ 20: การเข้าเว็บไซต์จากอังกฤษจำเป็นต้องปรับปรุง

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

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

ใน ประเทศจีน และ เกาหลีใต้ 82% ของเว็บไซต์ทั้งหมดตรงกับความคาดหวังด้านประสิทธิภาพของ Google ซึ่งเป็นมูลค่าสูงสุดและเป็นผู้นำระดับโลก ตามมาด้วยกลุ่มประเทศนอร์ดิก (สวีเดน นอร์เวย์ เดนมาร์ก) แต่ยังรวมถึงญี่ปุ่นและไต้หวันด้วย

เยอรมนี อยู่ในอันดับที่เก้าในการวิเคราะห์นี้: 3 ใน 4 ของคำขอของผู้ใช้ทั้งหมดสอดคล้องกับความคาดหวังด้านความเร็วของ Google แล้ว อังกฤษ อยู่ในอันดับที่ 20 ซึ่งอาจสะท้อนถึงปริมาณการใช้เนื้อหาจากนอกประเทศ โดยเฉพาะจากสหรัฐอเมริกา และอาจมาจากบริการในส่วนอื่นๆ ของยุโรป

เวลาในการโหลดใน รัสเซีย และ สหรัฐอเมริกา นั้นใกล้เคียงกัน ค่านิยมที่ต่ำสำหรับประเทศไทยและเวียดนามแสดงให้เห็นว่าเอเชียไม่สามารถเทียบได้กับอินเทอร์เน็ตที่รวดเร็วเสมอไป

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

CMS: Jimdo เร็วที่สุด Wix ช้ากว่า WordPress

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

เราได้รวมฐานข้อมูลเทคโนโลยีเว็บเข้ากับการวัด Core Web Vitals เพื่อให้สามารถประเมิน ความเร็วในการโหลด ของระบบจัดการเนื้อหาที่ใช้มากที่สุด มาดูการวิเคราะห์กัน:

Jimdo ผู้สร้างเว็บไซต์จากฮัมบูร์ก ประเทศเยอรมนี มอบ ประสิทธิภาพที่ดีที่สุด สำหรับ Largest Contentful Paint กว่า 82% ของการเข้าถึงเว็บไซต์ที่ทำงานบน Jimdo เป็นไปตามความคาดหวังด้านประสิทธิภาพของ Google

Typo3 แสดงให้เห็นว่า แม้แต่ CMS ที่โฮสต์เองก็สามารถให้ประสิทธิภาพที่ดีมากเช่นกัน เป็น ที่ที่สอง ในการประเมิน ใครก็ตามที่เคยพัฒนาด้วย Typo3 มักจะจดจำความซับซ้อนด้วยความสยองขวัญ อย่างไรก็ตาม สิ่งนี้ไม่ส่งผลต่อความเร็วของ CMS ที่ใช้ PHP นี้

WordPress โดย CMS ที่แพร่หลายที่สุดนั้นช้ากว่ามากใน อันดับสองจากตำแหน่งสุดท้าย ประมาณครึ่งหนึ่งของเว็บไซต์ทั้งหมดทำงานบน WordPress แต่ยังมีอีกหลายคนที่ใช้งานเว็บไซต์ซึ่งให้คุณค่าเพียงเล็กน้อยกับเวลาในการโหลดที่ดี Google จำแนกประมาณ 20% ของ Hit บนเว็บไซต์โดยพิจารณาจาก WordPress ว่า แย่ และอีก 21% จำเป็นต้องปรับปรุง

การวิเคราะห์นี้ทำให้ WordPress ไม่มีช้อนไม้ ต้องขอบคุณผู้ให้บริการชื่อ Wix โซลูชันระบบคลาวด์นี้มอบการเข้าถึงทั้งหมดเพียง ครึ่งเดียว พร้อมเวลาในการโหลดที่ดี เกือบหนึ่ง ในสี่ ให้คะแนน Core Web Vitals ของ Google ว่า แย่

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

ระบบร้านค้า: Shopify กลางทุ่ง, WooCommerce ที่ด้านล่าง

ต้นปี 2549 Amazon ระบุว่าเวลาในการโหลดเพิ่มขึ้น 0.1 วินาทีทำให้ยอดขายลดลง 1% ไม่ดีขึ้นเลยในช่วง 14 ปีที่ผ่านมา เวลาในการโหลดที่ดีมีความสำคัญพื้นฐาน สำหรับร้านค้าออนไลน์

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

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

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

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

WooCommerce ส่วนขยายของ WordPress ล้าหลังมากในตำแหน่งสุดท้าย ปัจจุบันร้านค้า WooCommerce ไม่ถึงครึ่งหนึ่งมีคุณสมบัติตรงตามข้อกำหนดของ Google ที่น่าตกใจ 26% นั้น แย่ จริง ๆ โซลูชันโฮสติ้งที่ดำเนินการด้วยตนเองพร้อมผู้ให้บริการจำนวนมากที่ประสิทธิภาพต่ำมีความชัดเจนที่นี่

เทคโนโลยีเว็บ: AMP ช้ากว่าที่คาดไว้

การประเมินนี้เกี่ยวข้องกับเทคโนโลยีเว็บที่หลากหลาย ตั้งแต่เทคโนโลยี แบ็กเอนด์ สำหรับการสร้างเว็บไซต์ไปจนถึงไลบรารี JavaScript และ CSS สำหรับการออกแบบและการโต้ตอบกับ Google AMP

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

Ruby on Rails ซึ่งเป็นเฟรมเวิร์กของ Ruby ที่พัฒนาโดยผู้ก่อตั้ง Basecamp นั้นเป็นผู้นำอยู่แล้ว: เกือบ 85% ของเว็บไซต์ทั้งหมดที่มีเทคโนโลยีนี้นำเสนอเว็บไซต์ภายในขอบเขตที่ Google กำหนดไว้สำหรับเรตติ้งที่ดีของ Largest Contentful Paint

แต่ เฟรมเวิร์ก PHP เช่น Yii (74%) หรือ Laravel (73%) ก็มอบช่วงเวลาที่ดีเช่นกัน เพื่อไม่ให้ใครรู้สึกว่าถูกทอดทิ้ง: Python ยังเป็นตัวแทนที่ดีด้วย เฟรมเวิร์ก Django (75%) และ ASP.NET (77%) แม้จะอยู่ในอันดับที่สอง เราเรียนรู้อะไรจากสิ่งนี้ ความเร็วไม่ได้ขึ้นอยู่กับภาษาโปรแกรม แต่ขึ้นอยู่กับการใช้งาน

เห็นได้ชัดว่า AMP ไม่ใช่หนึ่งในเทคโนโลยีที่เร็วที่สุด Accelerated Mobile Pages (AMP) เป็นอนุพันธ์ของ HTML ที่ Google ผลักดันเป็นหลัก ข้อจำกัดหลายประการควรหมายความว่าหน้า AMP โหลดได้เร็วกว่าบนโทรศัพท์มือถือได้เร็วกว่าหน้า HTML แบบคลาสสิก

ผลลัพธ์ไม่น่าเชื่อถือ: น้อยกว่า 70% ของโดเมน AMP ตรงตามข้อกำหนดของ Google เห็นได้ชัดว่า Google รับรู้สิ่งนี้แล้วและในอนาคตจะมอบสิทธิ์ AMP ในกล่องเรื่องเด่นให้กับไซต์ที่มี Core Web Vitals ที่รวดเร็ว

AMP จะไม่จำเป็นสำหรับเรื่องราวที่จะนำเสนอในเรื่องเด่นบนมือถืออีกต่อไป จะ เปิดหน้าใดก็ได้

บล็อก Google Webmaster Central การประเมินประสบการณ์หน้าเพื่อเว็บที่ดีขึ้น

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

CDN ไซต์ที่รวดเร็วกำลังใช้งาน Fastly

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

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

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

โดเมนที่พึ่งพา Fastly ในการโหลด CDN โดยเฉลี่ยจะเร็วกว่าโดเมนที่พึ่งพาผู้ให้บริการรายอื่นมาก Google ครองตำแหน่งที่สอง แต่ Amazon และ Microsoft (Azure) ก็อยู่ไม่ไกลหลังเช่นกัน

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

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

ความเป็นมา: เราวัดอะไร (และอย่างไร)

การวัดความเร็วในการโหลดมีประวัติอันยาวนาน: จากการวัดเริ่มต้นของการเริ่มต้นการส่งมอบ HTML บริสุทธิ์ ( TTFB , เวลาถึงไบต์แรก) ไปจนถึง First Contentful Paint จนถึงค่าที่วัดได้สามค่าในปัจจุบันของ Core Web Vitals ด้วย Largest Contentful Paint เนื่องจากตัววัดส่วนกลางได้เปลี่ยนแปลงไปอย่างมาก

สำหรับการวิเคราะห์ เราใช้ฐานการคำนวณอย่างเป็นทางการของ Google Core Web Vitals มีสองวิธีการวัดที่แตกต่างกันสำหรับสิ่งนี้: ข้อมูลในห้องปฏิบัติการ กล่าวคือ ค่าที่วัดได้ด้วยตัวเองภายใต้สภาพห้องปฏิบัติการของคุณเองและ ข้อมูลภาคสนาม วัดเหล่านี้โดยแผงผู้ใช้ เราประเมินข้อมูลภาคสนามสำหรับการวิเคราะห์นี้ ใน SISTRIX คุณสามารถเข้าถึงทั้งข้อมูลห้องปฏิบัติการและข้อมูลภาคสนาม โดยรวมแล้ว เราวิเคราะห์เวลาในการโหลด 18.5 ล้านโดเมน

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

เราได้รวมค่าที่วัดได้เหล่านี้เข้ากับการตรวจจับเทคโนโลยีใน SISTRIX เพื่อให้สามารถระบุเกี่ยวกับโซลูชันซอฟต์แวร์และกองเทคโนโลยีได้ สำหรับการจดจำเทคโนโลยี เรารวบรวมข้อมูลส่วนใหญ่ของอินเทอร์เน็ตเป็นประจำ และเปรียบเทียบคุณลักษณะที่พบ ("ลายนิ้วมือ") กับรายการเทคโนโลยีอินเทอร์เน็ตที่เกี่ยวข้องกว่า 1,000 รายการของเรา เรารวมเฉพาะชุดค่าผสมของเทคโนโลยี-แกนกลาง-เว็บ-สำคัญเหล่านั้นในการวิเคราะห์ขั้นสุดท้ายที่เกิดขึ้นกับจำนวนโดเมนที่เพียงพอเพื่อให้ได้มาซึ่งนัยสำคัญทางสถิติ

บทสรุป

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

เช่นเดียวกับ SEO มาก การปรับปรุงเวลาในการโหลดต้องเป็น กระบวนการที่ต่อเนื่อง ไม่ใช่งานที่ทำเพียงครั้งเดียว แต่เป็นกระบวนการที่มีการตรวจสอบอย่างต่อเนื่อง จะต้องได้รับการเอาใจใส่อย่างสม่ำเสมอและต้องปรับเปลี่ยนเป้าหมายเป็นระยะๆ

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

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