วันนี้ผมได้เรียกดู "เว็บไซต์ประสิทธิภาพสูง" สั้นๆ หนังสือเล่มนี้ในเวอร์ชันภาษาจีนคือ "คำแนะนำในการสร้างเว็บไซต์ประสิทธิภาพสูง"
หนังสือเล่มนี้ยังมีบทขั้นสูง "Even Faster Web Sites" ที่จะเจาะลึกประเด็นแต่ละประเด็น และฉบับแปลเป็นภาษาจีนคือ "Advanced Guide to Building High-Performance Websites"
ผู้เขียนแนะนำไว้ในลิงก์ Douban ด้านบน ดังนั้นฉันจะไม่คัดลอกไว้ที่นี่
หนังสือเล่มนี้ให้หลักการ 14 ข้อในการปรับปรุงประสิทธิภาพเว็บไซต์ แต่ละหลักการเป็นบทอิสระพร้อมตัวอย่าง หลักการเหล่านี้ส่วนใหญ่ใช้งานได้จริงและเหมาะสำหรับสถาปนิกไซต์และวิศวกรส่วนหน้า มันมีความสำคัญมากกว่าสำหรับวิศวกรส่วนหน้า
ครั้งนี้ผมได้ดูเวอร์ชั่นต้นฉบับ ฉันขาดประสบการณ์จริงในการพัฒนาเว็บไซต์ และฉันรีบอ่าน ดังนั้นอาจมีการละเว้นและการแสดงออกที่ไม่เหมาะสม ฉันหวังว่าชาวเน็ตจะรู้สึกอิสระที่จะแก้ไขฉัน
หลักการที่ 1 ลดจำนวนคำขอ HTTP
ต้องใช้เวลาในการสร้างคำขอและรอการตอบกลับ ดังนั้น ยิ่งคำขอน้อยลงก็ยิ่งดีเท่านั้น แนวคิดทั่วไปในการลดคำขอคือการรวมทรัพยากรและลดจำนวนไฟล์ที่ต้องใช้ในการแสดงเพจ
1. แผนที่รูปภาพ
ด้วยการตั้งค่าแอตทริบิวต์ usemap ของแท็ก <img> และใช้แท็ก <map> คุณสามารถแบ่งรูปภาพออกเป็นหลายพื้นที่และชี้ไปที่ลิงก์ต่างๆ เมื่อเทียบกับการใช้รูปภาพหลายรูปเพื่อสร้างลิงก์แยกกัน จำนวนคำขอจะลดลง
2. CSS SPRite (การรวมพื้นผิว CSS / การเย็บพื้นผิว / การวางตำแหน่งพื้นผิว)
ทำได้โดยการตั้งค่ารูปแบบตำแหน่งพื้นหลังขององค์ประกอบ โดยทั่วไปใช้สำหรับไอคอนอินเทอร์เฟซ โดยทั่วไปสามารถอ้างถึงปุ่มเล็กๆ เหนือโปรแกรมแก้ไข TinyMCE โดยพื้นฐานแล้วรูปภาพขนาดเล็กหลายภาพจะถูกตัดออกจากรูปภาพขนาดใหญ่ที่มีออฟเซ็ตต่างกัน ด้วยวิธีนี้ ปุ่มจำนวนมากบนอินเทอร์เฟซการโหลดจะต้องได้รับการร้องขอเพียงครั้งเดียวเท่านั้น (ขอรูปภาพขนาดใหญ่เพียงครั้งเดียว) ซึ่งจะช่วยลดจำนวนคำขอ HTTP
3. รูปภาพอินไลน์
อย่าระบุ URL ของไฟล์รูปภาพภายนอกใน src ของ <img> แต่ให้ใส่ข้อมูลรูปภาพโดยตรง ตัวอย่างเช่น src="data:image/gif;base64,R0lGODlhDAAMAL..." มีประโยชน์ในบางกรณีพิเศษ (เช่น รูปภาพขนาดเล็กจะใช้เฉพาะในหน้าปัจจุบันเท่านั้น)
หลักการที่ 2: ใช้ CDN หลายบรรทัด
ให้เว็บไซต์ของคุณสามารถเข้าถึงหลายสาย (เช่น โทรคมนาคมภายในประเทศ, China Unicom, China Mobile) และที่ตั้งทางภูมิศาสตร์หลายแห่ง (เหนือ, ใต้, ตะวันตก) เพื่อให้ผู้ใช้ทุกคนสามารถเข้าถึงได้อย่างรวดเร็ว
หลักการที่ 3: ใช้แคช HTTP
เพิ่มข้อมูลส่วนหัว Expires ที่ยาวขึ้นให้กับทรัพยากรที่ไม่ได้อัปเดตบ่อยครั้ง (เช่น รูปภาพคงที่) เมื่อทรัพยากรเหล่านี้ถูกแคชไว้ ทรัพยากรเหล่านั้นจะไม่ถูกส่งอีกเป็นเวลานานในอนาคต
หลักการที่ 4: ใช้การบีบอัด Gzip
ใช้ Gzip เพื่อบีบอัดข้อความ HTTP เพื่อลดขนาดและเวลาในการส่ง
หลักการที่ 5: วางสไตล์ชีตไว้ที่ด้านหน้าของหน้า
โหลดสไตล์ชีตก่อนเพื่อให้สามารถเรนเดอร์เพจได้เร็วยิ่งขึ้น ทำให้ผู้ใช้รู้สึกว่าเพจโหลดเร็วขึ้น
หลักการที่ 6: วางสคริปต์ไว้ที่ส่วนท้ายของหน้า
เหตุผลเหมือนกับ 5 การแสดงหน้าเว็บจะถูกประมวลผลก่อน การแสดงหน้าเว็บจะเสร็จสมบูรณ์ก่อนหน้านี้ และตรรกะของสคริปต์จะดำเนินการในภายหลัง ซึ่งทำให้ผู้ใช้รู้สึกว่าหน้าเว็บโหลดเร็วขึ้น
หลักการที่ 7 หลีกเลี่ยงการใช้นิพจน์ CSS
ตรรกะสคริปต์ JavaScript ที่ซับซ้อนมากเกินไป การค้นหา DOM และการดำเนินการเลือกจะลดประสิทธิภาพการประมวลผลเพจ
หลักการที่ 8 ใช้ Javascript และ CSS เป็นทรัพยากรภายนอก
สิ่งนี้ดูเหมือนจะตรงกันข้ามกับแนวคิดการรวมในหลักการที่ 1 แต่ไม่ใช่: เมื่อพิจารณาว่าแต่ละหน้าแนะนำทรัพยากร JavaScript สาธารณะ (เช่น jQuery หรือไลบรารี JavaScript เช่น ExtJS) โดยตัดสินจากประสิทธิภาพของหน้าเดียวเพียงอย่างเดียวแบบอินไลน์ (เช่น การฝัง JavaScript ลงใน HTML) หน้าจะโหลดได้เร็วกว่า (เนื่องจากมีคำขอ HTTP จำนวนน้อยกว่า) หน้าขาออก (แนะนำโดยใช้แท็ก <script>) แต่หากหลายเพจแนะนำทรัพยากร JavaScript สาธารณะนี้ รูปแบบอินไลน์จะทำให้เกิดการส่งข้อมูลซ้ำ (เนื่องจากทรัพยากรนี้ถูกฝังอยู่ในแต่ละหน้า ทรัพยากรส่วนนี้จะต้องถูกส่งทุกครั้งที่เปิดเพจ จึงทำให้สิ้นเปลืองการส่งผ่านเครือข่าย ทรัพยากร). ปัญหานี้สามารถแก้ไขได้ด้วยการทำให้ทรัพยากรนี้เป็นอิสระและอ้างอิงถึงทรัพยากรจากภายนอก
เนื่องจาก JavaScript และ CSS ค่อนข้างเสถียร เราจึงสามารถกำหนดวันหมดอายุที่นานขึ้นสำหรับทรัพยากรที่เกี่ยวข้องได้ (โปรดดูหลักการที่ 3)
หลักการที่ 9 ลดการค้นหา DNS
คำแนะนำของผู้เขียนคือ:
1. ใช้ Keep-Alive เพื่อเชื่อมต่อ
หากการเชื่อมต่อถูกตัดการเชื่อมต่อ การค้นหา DNS จะต้องดำเนินการในครั้งถัดไปที่ทำการเชื่อมต่อ แม้ว่าการแมปชื่อโดเมน-IP ที่เกี่ยวข้องจะถูกแคชไว้ การค้นหาจะใช้เวลาระยะหนึ่ง
2. ลดชื่อโดเมน
แต่ละครั้งที่คุณขอชื่อโดเมนใหม่ คุณจะต้องค้นหาชื่อโดเมนอื่นผ่าน DNS และแคช DNS ไม่สามารถทำงานได้ ดังนั้น คุณควรพยายามอย่างเต็มที่ในการจัดระเบียบไซต์ภายใต้ชื่อโดเมนแบบรวม และหลีกเลี่ยงการใช้ชื่อโดเมนย่อยมากเกินไป
หลักการที่ 10 ลดขนาด JavaScript ของคุณ
ใช้เครื่องมือบีบอัด JS เพื่อบีบอัด JavaScript ของคุณ ซึ่งมีประสิทธิภาพมาก เพียงดูการแจกแจง jQuery สองแบบที่แตกต่างกันเพื่อดูความแตกต่าง:
http://code.jquery.com/jquery-1.6.2.js กำลังอ่านโค้ด jQuery เวอร์ชัน 230KB
http://code.jquery.com/jquery-1.6.2.min.js เวอร์ชันบีบอัดของโค้ด jQuery (สำหรับการปรับใช้จริง) 89.4KB
หลักการที่ 11 พยายามหลีกเลี่ยงการเปลี่ยนเส้นทาง
การเปลี่ยนเส้นทางหมายความว่ามีการเพิ่มคำขอ HTTP รอบเพิ่มเติมก่อนที่คุณจะเข้าถึงหน้าเว็บที่คุณต้องการดู (ไคลเอนต์เริ่มคำขอ HTTP → เซิร์ฟเวอร์ HTTP ส่งคืนการตอบสนองการเปลี่ยนเส้นทาง → ไคลเอนต์เริ่มต้นคำขอสำหรับ URL ใหม่ → HTTP เซิร์ฟเวอร์ส่งคืนเนื้อหา ส่วนที่ขีดเส้นใต้เป็นคำขอเพิ่มเติม) ดังนั้นจึงใช้เวลานานกว่า (ซึ่งทำให้ผู้คนรู้สึกว่าการตอบสนองช้าลงด้วย) ดังนั้นอย่าใช้การเปลี่ยนเส้นทางเว้นแต่จำเป็น สถานการณ์ "จำเป็น" หลายประการ:
1. หลีกเลี่ยง URL ที่ไม่ถูกต้อง
หลังจากย้ายไซต์เก่าแล้ว เพื่อป้องกันไม่ให้ URL เก่ากลายเป็นไม่ถูกต้อง คำขอสำหรับ URL เก่ามักจะถูกเปลี่ยนเส้นทางไปยังที่อยู่ที่เกี่ยวข้องของระบบใหม่
2. การทำให้ URL สวยงาม
แปลงระหว่าง URL ที่อ่านได้กับ URL ของทรัพยากรจริง ตัวอย่างเช่น สำหรับ Google Toolbar ผู้ใช้จะจำ http://toolbar.google.com ซึ่งเป็นที่อยู่เชิงความหมายสำหรับมนุษย์ แต่เป็นการยากที่จะจดจำ http://www .com/tools/Firefox/toolbar/FT3/intl/en/index.html คือที่อยู่ทรัพยากรจริง ดังนั้นจึงจำเป็นต้องเก็บคำขอเดิมไว้และเปลี่ยนเส้นทางคำขอจากคำขอแรกไปยังคำขอหลัง
หลักการที่ 12 ลบสคริปต์ที่ซ้ำกัน
อย่าใส่สคริปต์เดียวกันซ้ำๆ บนหน้าเว็บ ตัวอย่างเช่น สคริปต์ B และ C ทั้งคู่ขึ้นอยู่กับ A ดังนั้นอาจมีการอ้างอิงซ้ำถึง A ในหน้าเว็บที่ใช้ B และ C วิธีแก้ไขคือการตรวจสอบการขึ้นต่อกันของไซต์แบบง่ายด้วยตนเอง และกำจัดการแนะนำซ้ำ ๆ สำหรับไซต์ที่ซับซ้อน คุณต้องสร้างกลไกการจัดการการขึ้นต่อกัน/การควบคุมเวอร์ชันของคุณเอง
หลักการที่ 13 จัดการ ETags ด้วยความระมัดระวัง
ETag เป็นอีกหนึ่งวิธี HTTP Cache นอกเหนือจาก Last-Modified ระบุว่าทรัพยากรได้รับการแก้ไขผ่านการแฮชหรือไม่ แต่มีปัญหาบางอย่างกับ ETag เช่น:
1. ความไม่สอดคล้องกัน: เว็บเซิร์ฟเวอร์ที่แตกต่างกัน (Apache, IIS ฯลฯ) กำหนดรูปแบบ ETag ที่แตกต่างกัน
2. การคำนวณ ETag ไม่เสถียร (เนื่องจากพิจารณาหลายปัจจัยมากเกินไป) เช่น:
1) ทรัพยากรเดียวกันมี ETags ที่แตกต่างกันซึ่งคำนวณบนเซิร์ฟเวอร์ที่แตกต่างกัน และแอปพลิเคชันเว็บขนาดใหญ่มักจะให้บริการโดยเซิร์ฟเวอร์มากกว่าหนึ่งเครื่อง ซึ่งทำให้ทรัพยากรที่แคชไว้ของไคลเอ็นต์บนเซิร์ฟเวอร์ A ยังคงใช้งานได้ แต่ในครั้งถัดไปที่ร้องขอ B เพราะ ETag แตกต่างออกไป ถือว่าไม่ถูกต้อง ส่งผลให้มีการส่งทรัพยากรเดียวกันซ้ำๆ
2) ทรัพยากรยังคงไม่เปลี่ยนแปลง แต่ ETag เปลี่ยนแปลงเนื่องจากการเปลี่ยนแปลงในปัจจัยอื่นๆ บางอย่าง เช่น การเปลี่ยนแปลงไฟล์การกำหนดค่า ผลที่ตามมาโดยตรงคือหลังจากการอัปเดตระบบ ความล้มเหลวแคชของไคลเอ็นต์จะเกิดขึ้นในวงกว้าง ส่งผลให้ปริมาณการรับส่งข้อมูลเพิ่มขึ้นอย่างมากและประสิทธิภาพของไซต์ลดลง
คำแนะนำของผู้เขียนคือ: ปรับปรุงวิธีการคำนวณ ETag ที่มีอยู่ตามลักษณะของแอปพลิเคชันของคุณ หรือเพียงแค่อย่าใช้ ETag และใช้ Last-Modified ที่ง่ายที่สุด
หลักการที่ 14 ใช้ประโยชน์จาก HTTP Cache ด้วย Ajax
Ajax เป็นคำขอแบบอะซิงโครนัส คำขอแบบอะซิงโครนัสจะไม่บล็อกการดำเนินการปัจจุบันของคุณ และเมื่อคำขอเสร็จสมบูรณ์ คุณจะเห็นผลลัพธ์ได้ทันที แต่แบบอะซิงโครนัสไม่ได้หมายความว่าสามารถดำเนินการให้เสร็จสิ้นได้ในทันที และไม่ได้หมายความว่าสามารถยอมรับได้และใช้เวลาอันไม่มีที่สิ้นสุดในการดำเนินการให้เสร็จสิ้น ดังนั้นจึงจำเป็นต้องให้ความสนใจกับประสิทธิภาพของคำขอ Ajax ด้วย มีคำขอ Ajax จำนวนมากที่เข้าถึงทรัพยากรที่ค่อนข้างเสถียร ดังนั้นอย่าลืมใช้ประโยชน์จากกลไก HTTP Cache สำหรับคำขอ Ajax สำหรับรายละเอียด โปรดดูหลักการที่ 3 และ 13
ผู้เขียน: หยาง เหม่งตง
แหล่งที่มาของบทความ: บล็อกของ Yang Mengdong โปรดระบุลิงก์แหล่งที่มาเมื่อพิมพ์ซ้ำ