ขนาดวัตถุขั้นต่ำที่แนะนำสำหรับประโยชน์ของประสิทธิภาพการทำงานของ gzip คืออะไร?


31

ฉันกำลังปรับปรุงเวลาในการแสดงหน้าความเร็วและวิธีหนึ่งคือการ gzip เนื้อหาจากเว็บเซิร์ฟเวอร์

Google แนะนำ :

โปรดทราบว่า gzipping จะเป็นประโยชน์สำหรับทรัพยากรที่มีขนาดใหญ่ เนื่องจากโอเวอร์เฮดและเวลาแฝงของการบีบอัดและคลายการบีบอัดคุณควร gzip ไฟล์ที่เกินขีด จำกัด ขนาดที่แน่นอน เราแนะนำช่วงต่ำสุดระหว่าง 150 ถึง 1,000 ไบต์ การขยายไฟล์ที่มีขนาดต่ำกว่า 150 ไบต์สามารถทำให้ไฟล์มีขนาดใหญ่ขึ้นได้

เราให้บริการเนื้อหาของเราผ่านAkamaiโดยใช้เครือข่ายของพวกเขาสำหรับพร็อกซีและ CDN สิ่งที่พวกเขาบอกฉัน:

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

คำตอบของฉัน:

ทำไมขนาดขั้นต่ำของ Akamai คือ 860 ไบต์คืออะไร และทำไมตัวอย่างเช่นกรณีนี้ไม่ใช่สำหรับไฟล์ที่ Akamai ใช้กับ Facebook? ( ดูด้านล่าง ) Google แนะนำให้ gzip มากยิ่งขึ้น และดูเหมือนว่าเหมาะสมในไซต์ของเราที่มีจำนวนการเข้าชมบ่อยที่สุดคือการโทร AJAX ที่มีขนาด <860 ไบต์ส่วนหัวของ Facebook สกรีนช็อตโต้แย้งคำสั่งของ Akamai

คำตอบของ Akamai:

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

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


ปรับปรุง 7/9/12: ฉันถามSteve Soudersว่ามีประสิทธิภาพเพิ่มขึ้นในการตอบกลับ gzipping ที่มีขนาดเล็กกว่าแพ็กเก็ตอยู่แล้วและขนาดวัตถุขั้นต่ำที่แนะนำสำหรับประโยชน์ของประสิทธิภาพการทำงาน gzip คืออะไรและนี่คือการตอบสนองของเขา:

ขอบคุณสำหรับอีเมล์ของคุณ. ขนาดอยู่ระหว่าง 1-5K Apache มีค่าเริ่มต้น แต่ฉันลืมว่ามันคืออะไร - นั่นจะเป็นแนวทางที่ดี

เราทำการบีบอัดบนอุปกรณ์ F5 ดังนั้นเราจะลดลงเหลือ ~ 350 ไบต์เนื่องจากมีการโทร AJAX ในปริมาณที่เหมาะสมระหว่างนั้นและ 1K โทร AJAX ที่น้อยกว่า 350 ไบต์บนเว็บไซต์ของเราจะลดลงทั้งหมดประมาณ 70 ไบต์ ... น้อยกว่าคำแนะนำของ Google ... ดังนั้นจริงๆมันดูเหมือนว่าจะถอยกลับไป: รู้ว่าเว็บไซต์ของคุณและปรับตามรหัสของคุณ

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


@Steve เกี่ยวกับการแก้ไขเดือนเมษายนฉันเพิ่มwelpเพื่ออธิบายความรู้สึกเนื่องจากผู้เชี่ยวชาญในการตอบกลับของฟิลด์นี้ไม่ได้ตอบคำถามใด ๆ ฉันดีใจที่ได้ยินจาก Mr. Sounders แต่เขาก็ไม่ทราบคำตอบที่ชัดเจนเช่นกัน
utt73

สำหรับ"กลับไปที่โพสต์นี้หลังจากการอัพเดท F5 ทำงานในระยะเวลาหนึ่ง " แม้ว่าฉันจะไม่ได้ทำงานกับแอปพลิเคชันเว็บนี้อีกต่อไป แต่เราก็ประสบความสำเร็จในเป้าหมายของเราในการทำให้ทั้งภาระหน้าที่เฉลี่ย () อินเตอร์แอคทีฟ (TTI) ต่ำกว่า 2 วินาทีและความพยายามในการลดลงนี้เป็นเพียงส่วนเล็ก ๆ การลดจำนวนการเรียกใช้ทราฟฟิก http การขยายการแคชเบราว์เซอร์การปรับโค้ดให้เหมาะสมและแนวทางปฏิบัติที่ดีที่สุดสำหรับประสิทธิภาพเว็บอื่น ๆ
utt73

คำตอบ:


3

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.