PageSpeed Insights จะวิเคราะห์หน้าเว็บเพื่อดูว่าเป็นไปตามคำแนะนำของเราสำหรับการทำให้หน้าเว็บแสดงผลภายใน 1 วินาทีบนเครือข่ายมือถือหรือไม่ งานวิจัยพบว่าความล่าช้านานกว่า 1 วินาทีจะทำให้ผู้ใช้รบกวนความคิดของตน ซึ่งทำให้เกิดประสบการณ์การใช้งานที่ไม่ดี เป้าหมายของเราคือการทำให้ผู้ใช้มีส่วนร่วมกับหน้าเว็บอยู่เสมอและมอบประสบการณ์ที่ดีที่สุดไม่ว่าจะใช้อุปกรณ์หรือเครือข่ายประเภทใด
การใช้จ่ายงบประมาณสำหรับเวลา 1 วินาทีไม่ใช่เรื่องง่าย แต่โชคดีที่หน้าเว็บทั้งหน้าไม่จำเป็นต้องแสดงผลภายในงบประมาณนี้แทน เราต้องนำส่งและแสดงผลเนื้อหาครึ่งหน้าบน (ATF) ภายใน 1 วินาที ซึ่งช่วยให้ผู้ใช้เริ่มโต้ตอบกับหน้าเว็บได้โดยเร็วที่สุด จากนั้นขณะที่ผู้ใช้กำลังตีความเนื้อหาหน้าแรก ส่วนที่เหลือของหน้าจะแสดงอย่างต่อเนื่องในเบื้องหลัง
การปรับให้เข้ากับเครือข่ายมือถือที่มีเวลาในการตอบสนองสูง
การมีคุณสมบัติตรงตามเกณฑ์ ATF 1 วินาทีบนอุปกรณ์เคลื่อนที่จะทำให้เกิดความท้าทายที่ไม่เหมือนใครซึ่งไม่มีอยู่ในเครือข่ายอื่นๆ ผู้ใช้อาจเข้าถึงเว็บไซต์ของคุณผ่านเครือข่าย 2G, 3G และ 4G ที่แตกต่างกัน เวลาในการตอบสนองของเครือข่ายจะสูงกว่าการเชื่อมต่อแบบใช้สายเป็นอย่างมาก และใช้งบประมาณ 1, 000 มิลลิวินาทีในการแสดงผลเนื้อหา ATF
4G เป็นเครือข่ายประเภทที่นิยมใช้กันทั่วโลก โปรดทราบว่าผู้ใช้ส่วนใหญ่จะเข้าถึงหน้าเว็บของคุณผ่านเครือข่าย 4G ด้วยเหตุนี้ เราจึงต้องถือว่าคำขอเครือข่ายแต่ละครั้งจะใช้เวลาโดยเฉลี่ย 100 มิลลิวินาที
ในข้อนี้ เราลองมาย้อนกลับไปดูกัน หากเราดูลำดับการสื่อสารปกติระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ การเชื่อมต่อเครือข่ายใช้ไปแล้ว 300 มิลลิวินาทีในช่วงเวลาดังกล่าว นั่นคือ การค้นหา DNS เพื่อแก้ไขชื่อโฮสต์ (เช่น google.com) ไปยังที่อยู่ IP, การส่งข้อมูลไปกลับของเครือข่ายเพื่อทำแฮนด์เชค TCP และการเชื่อมต่อ TLS ที่ไม่บังคับ ซึ่งทำให้เราเหลือเวลา 700 มิลลิวินาที
มอบประสบการณ์การแสดงผลย่อย 1 วินาที
หลังจากหักลบเวลาในการตอบสนองของเครือข่ายแล้ว เราเหลือเวลาเพียง 700 มิลลิวินาทีในงบประมาณของเรา และยังคงมีงานอีกมาก ซึ่งก็คือ เซิร์ฟเวอร์จะต้องแสดงผลตอบสนอง โค้ดของแอปพลิเคชันฝั่งไคลเอ็นต์จะต้องทำงาน และเบราว์เซอร์ต้องจัดวางและแสดงผลเนื้อหา ด้วยเหตุนี้ เกณฑ์ต่อไปนี้น่าจะช่วยให้เราอยู่ภายในงบประมาณได้:
- (1) เซิร์ฟเวอร์ต้องแสดงการตอบกลับ (< 200 มิลลิวินาที)
- เวลาในการตอบสนองของเซิร์ฟเวอร์คือระยะเวลาที่เซิร์ฟเวอร์ใช้ในการส่ง HTML เริ่มต้นกลับมา โดยต้องพิจารณาเวลารับส่งของเครือข่ายด้วย เนื่องจากเรามีเวลาน้อยมาก จึงควรใช้เวลานี้ให้น้อยที่สุด ซึ่งก็คือไม่เกิน 200 มิลลิวินาที และหากเป็นไปได้ให้น้อยกว่านั้น
- (2) ควรลดจำนวนการเปลี่ยนเส้นทางให้เหลือน้อยที่สุด
- การเปลี่ยนเส้นทาง HTTP เพิ่มเติมอาจเพิ่มรอบเครือข่ายเพิ่มเติม 1-2 รอบ (หากต้องใช้การค้นหา DNS เพิ่มเติม) ซึ่งทำให้เกิดเวลาในการตอบสนองเพิ่มขึ้นหลายร้อยมิลลิวินาทีในเครือข่าย 4G ด้วยเหตุนี้ เราจึงขอแนะนำให้ผู้ดูแลเว็บลดจำนวนลงและกำจัดการเปลี่ยนเส้นทางโดยสิ้นเชิง ซึ่งเป็นสิ่งสำคัญอย่างยิ่งสำหรับเอกสาร HTML (หลีกเลี่ยงการเปลี่ยนเส้นทาง “m.” หากทำได้)
- (3) ควรลดจำนวนการรับส่งข้อมูลไปกลับในการแสดงผลครั้งแรก
-
การเชื่อมต่อ TCP ใหม่จะใช้แบนด์วิดท์ที่มีอยู่ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ไม่ได้ในทันที เนื่องจาก TCP ประมาณความจุของการเชื่อมต่อ (เช่น TCP Slow Start) ด้วยเหตุนี้ เซิร์ฟเวอร์จะสามารถส่งแพ็กเก็ต TCP ได้สูงสุด 10 แพ็กเก็ตในการเชื่อมต่อใหม่ (ประมาณ 14 KB) ในรอบแรก จากนั้นต้องรอให้ไคลเอ็นต์รับทราบข้อมูลนี้ก่อน จึงจะขยายช่วงความแออัดได้และดำเนินการต่อเพื่อส่งข้อมูลเพิ่มเติม
นอกจากนี้ โปรดทราบว่าขีดจำกัด 10 แพ็กเก็ต (IW10) เป็นการอัปเดตมาตรฐาน TCP เมื่อเร็วๆ นี้ ดังนั้นคุณควรตรวจสอบว่าเซิร์ฟเวอร์ของคุณอัปเกรดเป็นเวอร์ชันล่าสุดเพื่อใช้ประโยชน์จากการเปลี่ยนแปลงนี้ ไม่เช่นนั้น ขีดจำกัดจะอยู่ที่ 3-4 แพ็กเก็ต
เนื่องด้วยลักษณะการทำงานของ TCP การเพิ่มประสิทธิภาพเนื้อหาจึงสำคัญต่อการลดรอบที่ต้องใช้ในการนำส่งข้อมูลที่จำเป็นในการแสดงผลหน้าเว็บครั้งแรก ตามหลักการแล้ว เนื้อหา ATF ควรมีขนาดไม่เกิน 98KB ซึ่งช่วยให้เบราว์เซอร์สามารถวาดหน้าเว็บหลังจากการส่งข้อมูลไปกลับเพียง 3 รอบ เพื่อให้มีเวลามากพอสำหรับเวลาในการตอบสนองการตอบกลับของเซิร์ฟเวอร์และการแสดงผลของไคลเอ็นต์
- (4) หลีกเลี่ยงการบล็อก JavaScript และ CSS จากภายนอกสำหรับเนื้อหาครึ่งหน้าบน
-
เบราว์เซอร์จะต้องแยกวิเคราะห์หน้าเว็บก่อน จึงจะแสดงผลหน้าเว็บแก่ผู้ใช้ได้ หากพบสคริปต์ภายนอกที่ไม่ซิงค์หรือบล็อกสคริปต์ภายนอกในระหว่างการแยกวิเคราะห์ ระบบจะหยุดและดาวน์โหลดทรัพยากรนั้น ในแต่ละครั้งที่ทำแบบนั้น จะเป็นการเพิ่มเครือข่ายไป-กลับ ซึ่งทำให้เวลาในการแสดงผลหน้าเว็บครั้งแรกล่าช้า
ดังนั้น JavaScript และ CSS ที่ต้องใช้ในการแสดงผลบริเวณครึ่งหน้าบนควรแทรกอยู่ และ JavaScript หรือ CSS ที่จำเป็นในการเพิ่มฟังก์ชันเพิ่มเติมลงในหน้าควรโหลดหลังจากแสดงเนื้อหา ATF แล้ว
- (5) จองเวลาสำหรับการจัดวางและการแสดงผลของเบราว์เซอร์ (200 มิลลิวินาที)
- กระบวนการแยกวิเคราะห์ HTML, CSS และการเรียกใช้ JavaScript ต้องใช้เวลาและทรัพยากรของไคลเอ็นต์ ขั้นตอนนี้อาจใช้เวลาหลายร้อยมิลลิวินาที ทั้งนี้ขึ้นอยู่กับความเร็วของอุปกรณ์เคลื่อนที่และความซับซ้อนของหน้า คำแนะนำของเราคือให้สงวนเวลา 200 มิลลิวินาทีไว้สำหรับการใช้งานทางเบราว์เซอร์
- (6) เพิ่มประสิทธิภาพการเรียกใช้ JavaScript และเวลาในการแสดงผล
- สคริปต์ที่ซับซ้อนและโค้ดที่ไม่มีประสิทธิภาพอาจใช้เวลาดำเนินการหลายสิบหลายร้อยมิลลิวินาที ใช้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ที่มีในตัวในเบราว์เซอร์เพื่อสร้างโปรไฟล์และเพิ่มประสิทธิภาพโค้ด ถ้าต้องการทราบข้อมูลเบื้องต้นดีๆ โปรดดูหลักสูตรแบบอินเทอร์แอกทีฟสำหรับเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Chrome
คำถามที่พบบ่อย
- ฉันใช้ไลบรารี JavaScript เช่น JQuery อยู่ไหม
- ไลบรารี JavaScript จำนวนมาก เช่น JQuery ใช้สำหรับปรับปรุงหน้าเว็บเพื่อเพิ่มการโต้ตอบ ภาพเคลื่อนไหว และเอฟเฟกต์อื่นๆ อย่างไรก็ตาม คุณสามารถเพิ่มลักษณะการทำงานเหล่านี้ได้อย่างปลอดภัยหลังจากที่แสดงเนื้อหา ATF แล้ว ตรวจสอบการย้ายการดำเนินการและการโหลด JavaScript ดังกล่าวจนกว่าจะโหลดหน้าเว็บเสร็จ
- คุณกำลังใช้เฟรมเวิร์ก JavaScript ในการสร้างหน้าเว็บ ฉันควรทำอย่างไร
- หากเนื้อหาของหน้าสร้างขึ้นโดย JavaScript ฝั่งไคลเอ็นต์ คุณควรตรวจสอบการอินไลน์โมดูล JavaScript ที่เกี่ยวข้องเพื่อหลีกเลี่ยงการไปกลับในเครือข่ายเพิ่มเติม ในทำนองเดียวกัน การใช้ประโยชน์จากการแสดงผลฝั่งเซิร์ฟเวอร์จะช่วยปรับปรุงประสิทธิภาพในการโหลดหน้าแรกได้อย่างมาก เช่น แสดงผลเทมเพลต JS บนเซิร์ฟเวอร์ แทรกผลลัพธ์ในบรรทัด HTML จากนั้นใช้เทมเพลตฝั่งไคลเอ็นต์เมื่อโหลดแอปพลิเคชันแล้ว
- ฉันจะระบุ CSS ที่สำคัญในหน้าเว็บของฉันได้อย่างไร
- เปิดแผงการตรวจสอบในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Chrome แล้วเรียกใช้รายงานประสิทธิภาพของหน้าเว็บ จากนั้นมองหากฎ CSS ที่ไม่ได้ใช้ในรายงานที่สร้างขึ้น หรือใช้เครื่องมือหรือสคริปต์ของบุคคลที่สามอื่นๆ เพื่อระบุว่าตัวเลือก CSS ใดที่ใช้ในแต่ละหน้า
- ใช้แนวทางปฏิบัติแนะนำเหล่านี้แบบอัตโนมัติได้ไหม
- แน่นอน มีผลิตภัณฑ์เพื่อการเพิ่มประสิทธิภาพเว็บ (WPO) เชิงพาณิชย์และแบบโอเพนซอร์สจำนวนมากที่จะช่วยให้คุณตรงตามเกณฑ์บางส่วนหรือทั้งหมดข้างต้น สำหรับโซลูชันโอเพนซอร์ส โปรดดูที่เครื่องมือเพิ่มประสิทธิภาพ PageSpeed
- ฉันจะปรับเซิร์ฟเวอร์ให้ตรงตามเกณฑ์เหล่านี้ได้อย่างไร
-
ขั้นแรก ให้ตรวจสอบว่าเซิร์ฟเวอร์ของคุณใช้ระบบปฏิบัติการเวอร์ชันล่าสุด เพื่อใช้ประโยชน์จากขนาดหน้าต่างความคับคั่งของ TCP เริ่มต้นที่เพิ่มขึ้น (IW10) คุณจะต้องมี Kernel ของ Linux 2.6.39+ สำหรับระบบปฏิบัติการอื่นๆ โปรดดูเอกสารประกอบ
เมื่อต้องการเพิ่มประสิทธิภาพเวลาในการตอบกลับของเซิร์ฟเวอร์ ให้ติดตั้งโค้ด หรือใช้โซลูชันการตรวจสอบแอปพลิเคชันเพื่อระบุจุดคอขวดของคุณ เช่น รันไทม์ในการเขียนสคริปต์, การเรียกใช้ฐานข้อมูล, คำขอ RPC, การแสดงผล ฯลฯ โดยมีเป้าหมายเป็นการแสดงผลการตอบสนอง HTML ภายใน 200 มิลลิวินาที - แล้วนโยบายรักษาความปลอดภัยเนื้อหาล่ะ
- หากใช้ CSP คุณอาจต้องอัปเดตนโยบายเริ่มต้น
ขั้นแรก แอตทริบิวต์ CSS ในบรรทัดในองค์ประกอบ HTML(เช่น< p style=...>) ควรหลีกเลี่ยงหากทำได้ เนื่องจากมักจะนำไปสู่การทำซ้ำโค้ดที่ไม่จำเป็นและถูกบล็อกโดยค่าเริ่มต้นด้วย CSP (ปิดใช้ผ่าน "แทรกในบรรทัดที่ไม่ปลอดภัย" ใน "style-src") หากเปิดใช้ CSP ก็จะบล็อกแท็กสคริปต์ในหน้าทั้งหมดโดยค่าเริ่มต้น หากมี JavaScript ในหน้า คุณจะต้องอัปเดตนโยบาย CSP ให้ใช้แฮชสคริปต์หรือ nonces หรือใช้ "unsafe-inline" เพื่อเปิดใช้สคริปต์ในหน้าทั้งหมดให้ทํางาน หากคุณมีรูปแบบอินไลน์ คุณจะต้องอัปเดตนโยบาย CSP ให้ใช้แฮชสไตล์หรือ nonces หรือใช้ "unsafe-inline" เพื่อเปิดใช้การบล็อกสไตล์แบบในหน้าทั้งหมดให้ได้รับการประมวลผล
หากมีคำถามเพิ่มเติม โปรดอย่าลังเลที่จะสอบถามและแสดงความคิดเห็นในกลุ่มสนทนาของเราที่ pagespeed-insights-discuss
ความคิดเห็น
หน้านี้มีประโยชน์ไหม