การปรับเปลี่ยนเว็บไซต์ HTML5

บทนำ

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

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

การสร้าง html5rocks.com ที่เหมาะกับอุปกรณ์เคลื่อนที่

เราคิดว่าการนํา html5rocks (เว็บไซต์ HTML5 ที่มีอยู่) มาเพิ่มเวอร์ชันที่เหมาะกับอุปกรณ์เคลื่อนที่จะเป็นการฝึกฝนที่น่าสนใจ ฉันกังวลเกี่ยวกับปริมาณงานขั้นต่ำที่จําเป็นในการกําหนดเป้าหมายไปยังสมาร์ทโฟน เป้าหมายของการฝึกนี้ไม่ใช่การสร้างเว็บไซต์เวอร์ชันอุปกรณ์เคลื่อนที่ใหม่ทั้งหมดและดูแลรักษาโค้ดเบส 2 เวอร์ชัน ซึ่งจะใช้เวลานานมากและเสียเวลาไปมาก เราได้กําหนดโครงสร้าง (มาร์กอัป) ของเว็บไซต์ไว้แล้ว เราได้ตรวจสอบรูปลักษณ์และความรู้สึก (CSS) ฟังก์ชันหลัก (JS) ในตอนนั้น ประเด็นคือ ไซต์หลายแห่ง อยู่ในเรือลำเดียวกัน

บทความนี้จะอธิบายวิธีที่เราสร้าง html5rocks เวอร์ชันอุปกรณ์เคลื่อนที่ซึ่งเพิ่มประสิทธิภาพสำหรับอุปกรณ์ Android และ iOS เพียงโหลด html5rocks.com ในอุปกรณ์ที่รองรับระบบปฏิบัติการหนึ่งเหล่านี้เพื่อดูความแตกต่าง ไม่มีการเปลี่ยนเส้นทางไปยัง m.html5rocks.com หรือกลโกงอื่นๆ ในลักษณะดังกล่าว คุณจะได้รับ html5rocks ตามที่ระบุไว้ พร้อมข้อดีเพิ่มเติมคือมีความสวยงามและใช้งานได้ดีบนอุปกรณ์เคลื่อนที่

html5rocks.com บนเดสก์ท็อป html5rocks.com เวอร์ชันอุปกรณ์เคลื่อนที่
html5rocks.com บนเดสก์ท็อป (ซ้าย) และอุปกรณ์เคลื่อนที่ (ขวา)

การค้นหาสื่อ CSS

HTML4 และ CSS2 รองรับชีตสไตล์แบบสื่อแบบเจาะจงมาระยะหนึ่งแล้ว เช่น

<link rel="stylesheet" media="print" href="printer.css">

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

คุณสามารถใช้ Media Query ในแอตทริบิวต์ media ของสไตลชีตภายนอกเพื่อกําหนดเป้าหมายความกว้างของหน้าจอ ความกว้างของอุปกรณ์ การวางแนว ฯลฯ ดูรายการทั้งหมดได้ที่ข้อกําหนดของ Media Query ของ W3C

การกำหนดเป้าหมายตามขนาดหน้าจอ

ในตัวอย่างต่อไปนี้ phone.css จะมีผลกับอุปกรณ์ที่เบราว์เซอร์พิจารณาว่าเป็น "อุปกรณ์พกพา" หรืออุปกรณ์ที่มีหน้าจอกว้างไม่เกิน 320 พิกเซล

 <link rel='stylesheet'
  media='handheld, only screen and (max-device-width: 320px)' href='phone.css'>

การวางคีย์เวิร์ด "only" ไว้หน้า Media Queries จะทำให้เบราว์เซอร์ที่ไม่เป็นไปตามข้อกำหนด CSS3 ละเว้นกฎ

รายการต่อไปนี้จะกําหนดเป้าหมายหน้าจอขนาดระหว่าง 641 ถึง 800 พิกเซล

 <link rel='stylesheet'
  media='only screen and (min-width: 641px) and (max-width: 800px)' href='ipad.css'>

การค้นหาสื่อยังปรากฏภายในแท็ก <style> ในบรรทัดได้ด้วย รายการต่อไปนี้กำหนดเป้าหมายสื่อ all ประเภทเมื่ออยู่ในแนวตั้ง

 <style>
  @media only all and (orientation: portrait) { ... }
 </style>

media="handheld"

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

คุณควรใช้ฟีเจอร์นี้เพื่อกําหนดเป้าหมายอุปกรณ์เคลื่อนที่ แต่เบราว์เซอร์ต่างๆ ใช้ฟีเจอร์นี้ในลักษณะที่แตกต่างกัน ดังนี้

  • บางเครื่องอ่านเฉพาะสไตล์ชีตสำหรับอุปกรณ์พกพา
  • บางรายการจะอ่านเฉพาะสไตล์ชีตสำหรับอุปกรณ์พกพา หากมี แต่จะใช้สไตล์ชีตสำหรับหน้าจอเป็นค่าเริ่มต้นหากไม่มี
  • บางรายการอ่านทั้งสไตล์ชีตสำหรับอุปกรณ์พกพาและสไตล์ชีตสำหรับหน้าจอ
  • บางรายการอ่านเฉพาะสไตลชีตหน้าจอ

Opera Mini ไม่สนใจ media="handheld" เคล็ดลับในการทำให้ Windows Mobile จดจำ media="handheld" ได้คือให้ใช้อักษรตัวพิมพ์ใหญ่สำหรับค่าแอตทริบิวต์สื่อสำหรับสไตล์ชีตหน้าจอ

 <!-- media="handheld" trick for Windows Mobile -->
 <link rel="stylesheet" href="screen.css" media="Screen">
 <link rel="stylesheet" href="mobile.css" media="handheld">

วิธีที่ html5rocks ใช้ Media Query

มีการใช้ Media Query อย่างมากใน html5rocks บนอุปกรณ์เคลื่อนที่ เครื่องมือนี้ช่วยให้เราปรับเลย์เอาต์ได้โดยไม่ต้องทำการเปลี่ยนแปลงที่สำคัญกับมาร์กอัปเทมเพลต Django… นี่เป็นเครื่องมือที่มีประโยชน์มาก นอกจากนี้ การสนับสนุนในเบราว์เซอร์ต่างๆ นั้นดีมาก

ใน <head> ของแต่ละหน้า คุณจะเห็นสไตล์ชีตต่อไปนี้

 <link rel='stylesheet'
  media='all' href='/static/css/base.min.css' />
 <link rel='stylesheet'
  media='only screen and (max-width: 800px)' href='/static/css/mobile.min.css' />

base.css ได้กำหนดรูปลักษณ์หลักของ html5rocks.com ไว้เสมอ แต่ตอนนี้เราจะใช้รูปแบบใหม่ (mobile.css) สำหรับความกว้างหน้าจอที่ต่ำกว่า 800 พิกเซล ข้อความค้นหาสื่อครอบคลุมสมาร์ทโฟน (~320 พิกเซล) และ iPad (~768 พิกเซล) ผลกระทบ: เราจะค่อยๆ ลบล้างรูปแบบใน base.css (ตามความจำเป็นเท่านั้น) เพื่อทำให้สิ่งต่างๆ ดูดีขึ้นในอุปกรณ์เคลื่อนที่

การเปลี่ยนแปลงการจัดรูปแบบบางอย่างที่ mobile.css บังคับใช้

  • ลดพื้นที่ว่าง/ระยะห่างจากขอบส่วนเกินในเว็บไซต์ หน้าจอขนาดเล็กหมายความว่าพื้นที่มีราคาแพง
  • นำสถานะ :hover ออก แต่จะไม่เห็นในอุปกรณ์แบบสัมผัส
  • ปรับเลย์เอาต์ให้เป็นคอลัมน์เดียว เราจะแจ้งข้อมูลเพิ่มเติมในภายหลัง
  • นำ box-shadow รอบ div คอนเทนเนอร์หลักของเว็บไซต์ออก เงากล่องขนาดใหญ่จะลดประสิทธิภาพของหน้า
  • ใช้รูปแบบกล่องยืดหยุ่น CSS box-ordinal-group เพื่อเปลี่ยนลําดับของแต่ละส่วนในหน้าแรก คุณจะเห็นส่วน "ดูตามกลุ่มฟีเจอร์ HTML5 หลัก" อยู่ก่อนส่วน "บทแนะนำ" ในหน้าแรก แต่อยู่หลังส่วนดังกล่าวในเวอร์ชันอุปกรณ์เคลื่อนที่ การจัดลำดับนี้เหมาะสำหรับอุปกรณ์เคลื่อนที่มากกว่าและไม่จำเป็นต้องมีการเปลี่ยนแปลงมาร์กอัป CSS flexbox FTW
  • นำการเปลี่ยนแปลง opacity รายการออก การเปลี่ยนค่าอัลฟ่าเป็น Hit ด้านประสิทธิภาพในอุปกรณ์เคลื่อนที่

เมตาแท็กสำหรับอุปกรณ์เคลื่อนที่

WebKit บนอุปกรณ์เคลื่อนที่รองรับฟีเจอร์บางอย่างที่ช่วยให้ผู้ใช้ได้รับประสบการณ์การท่องเว็บที่ดียิ่งขึ้นในอุปกรณ์บางรุ่น

การตั้งค่าวิวพอร์ต

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

 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">

บอกให้เบราว์เซอร์ตั้งค่าวิวพอร์ตเป็นความกว้างของอุปกรณ์โดยให้อัตราส่วนเริ่มต้นเป็น 1 ตัวอย่างนี้ยังอนุญาตให้ซูมได้ด้วย ซึ่งเป็นสิ่งที่อาจต้องการสำหรับเว็บไซต์ แต่ไม่ใช่สำหรับเว็บแอป เราอาจป้องกันไม่ให้มีการซูมด้วย user-scalable=no หรือจำกัดการปรับขนาดไว้ที่ระดับหนึ่ง

 <meta name=viewport
  content="width=device-width, initial-scale=1.0, minimum-scale=0.5 maximum-scale=1.0">

Android ขยายแท็กเมตาวิวพอร์ตโดยอนุญาตให้นักพัฒนาแอประบุความละเอียดของหน้าจอที่พัฒนาเว็บไซต์

 <meta name="viewport" content="target-densitydpi=device-dpi">

ค่าที่เป็นไปได้สำหรับ target-densitydpi คือ device-dpi, high-dpi, medium-dpi, low-dpi

หากต้องการแก้ไขหน้าเว็บสำหรับความหนาแน่นของหน้าจอที่แตกต่างกัน ให้ใช้-webkit-device-pixel-ratioคิวรีสื่อ CSS และ/หรือพร็อพเพอร์ตี้ window.devicePixelRatio ใน JavaScript จากนั้นตั้งค่าพร็อพเพอร์ตี้เมตา target-densitydpi เป็น device-dpi ซึ่งจะหยุดไม่ให้ Android ปรับขนาดในหน้าเว็บและช่วยให้คุณทำการปรับเปลี่ยนที่จำเป็นสำหรับความละเอียดแต่ละระดับผ่าน CSS และ JavaScript ได้

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

การเรียกดูแบบเต็มหน้าจอ

มีข้อมูลเมตาอีก 2 ค่าที่เป็น iOS-sfic apple-mobile-web-app-capable และ apple-mobile-web-app-status-bar-style จะแสดงผลเนื้อหาหน้าเว็บในโหมดเต็มหน้าจอที่เหมือนแอปและทำให้แถบสถานะโปร่งแสง

 <meta name="apple-mobile-web-app-capable" content="yes">
 <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับตัวเลือกเมตาทั้งหมดที่มี โปรดดูเอกสารอ้างอิง Safari

ไอคอนหน้าจอหลัก

อุปกรณ์ iOS และ Android ยังยอมรับ rel="apple-touch-icon" (iOS) และ rel="apple-touch-icon-precomposed" (Android) สำหรับลิงก์ด้วย สิ่งเหล่านี้จะสร้างไอคอนที่สะดุดตาซึ่งคล้ายกับแอปบนหน้าจอหลักของผู้ใช้เมื่อบุ๊กมาร์กเว็บไซต์ของคุณ

 <link rel="apple-touch-icon"
      href="/static/images/identity/HTML5_Badge_64.png" />
 <link rel="apple-touch-icon-precomposed"
      href="/static/images/identity/HTML5_Badge_64.png" />

วิธีที่ html5rocks ใช้เมตาแท็กสำหรับอุปกรณ์เคลื่อนที่

เมื่อรวมทุกอย่างเข้าด้วยกันแล้ว ข้อมูลโค้ดต่อไปนี้คือข้อมูลโค้ดจาก<head>ส่วน ของ html5rocks

 <head>
  ...
   <meta name="viewport"
        content="width=device-width, initial-scale=1.0, minimum-scale=1.0" />

   <link rel="apple-touch-icon"
        href="/static/images/identity/HTML5_Badge_64.png" />
   <link rel="apple-touch-icon-precomposed"
        href="/static/images/identity/HTML5_Badge_64.png" />
  ...
 </head>

เลย์เอาต์แนวตั้ง

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

ดัชนีบทแนะนำ บทแนะนำ หน้าฟีเจอร์ HTML5 หน้าโปรไฟล์ผู้เขียน
เลย์เอาต์แนวตั้งแบบคอลัมน์เดียวตลอดทั้งเว็บไซต์

การเพิ่มประสิทธิภาพสำหรับอุปกรณ์เคลื่อนที่

การเพิ่มประสิทธิภาพส่วนใหญ่ที่เราทำนั้นเป็นสิ่งที่ควรทำตั้งแต่แรก เช่น การลดจํานวนคําขอเครือข่าย การบีบอัด JS/CSS การบีบอัด gzip (มีให้ใช้งานฟรีใน App Engine) และการลดการจัดการ DOM เทคนิคเหล่านี้เป็นแนวทางปฏิบัติแนะนำที่พบบ่อย แต่บางครั้งก็ถูกมองข้ามเมื่อต้องรีบเปิดตัวเว็บไซต์

ซ่อนแถบที่อยู่อัตโนมัติ

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

วิธีง่ายๆ วิธีหนึ่งในการแก้ปัญหานี้คือเลื่อนหน้าเว็บโดยใช้ JavaScript แม้แต่การเลื่อนเพียง 1 พิกเซลก็ช่วยกำจัดแถบที่อยู่ที่น่ารำคาญได้ ในการบังคับซ่อนแถบที่อยู่บน html5rocks ฉันแนบเครื่องจัดการเหตุการณ์ onload เข้ากับออบเจ็กต์ window และเลื่อนหน้าเว็บในแนวตั้ง 1 พิกเซล

แถบที่อยู่
แถบที่อยู่ที่ไม่สวยกินพื้นที่หน้าจอ
  // Hides mobile browser's address bar when page is done loading.
  window.addEventListener('load', function(e) {
    setTimeout(function() { window.scrollTo(0, 1); }, 1);
  }, false);

นอกจากนี้ เรายังรวมตัวรับฟังนี้ไว้ในis_mobileตัวแปรเทมเพลตของเราด้วยเนื่องจากไม่จําเป็นต้องใช้บนเดสก์ท็อป

ลดคำขอเครือข่าย ประหยัดแบนด์วิดท์

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

ต่อไปนี้เป็นแนวทางที่เราใช้เพื่อลดคำขอของเครือข่ายและลดแบนด์วิดท์ใน html5rocks

  • นำ iframe ออก เนื่องจาก iframe ทําให้หน้าเว็บช้า เวลาในการตอบสนองส่วนใหญ่มาจากวิดเจ็ตการแชร์ของบุคคลที่สาม (Buzz, Google Friend Connect, Twitter, Facebook) ในหน้าบทแนะนำ API เหล่านี้รวมอยู่ในแท็ก <script> และสร้าง iframe ที่ลดความเร็วของหน้าเว็บ ระบบนำวิดเจ็ตออกสำหรับอุปกรณ์เคลื่อนที่แล้ว

  • display:none - ในบางกรณี เราจะซ่อนมาร์กอัปหากไม่เหมาะกับโปรไฟล์อุปกรณ์เคลื่อนที่ ตัวอย่างที่ดีคือช่องทรงกลม 4 กล่อง ที่ด้านบนของหน้าแรก

ปุ่มกล่องในหน้าแรก
ปุ่มกล่องในหน้าแรก

รายการดังกล่าวไม่อยู่ในเว็บไซต์เวอร์ชันอุปกรณ์เคลื่อนที่ โปรดทราบว่าเบราว์เซอร์จะยังคงส่งคำขอสำหรับไอคอนแต่ละรายการ แม้ว่าจะซ่อนคอนเทนเนอร์ด้วย display:none ก็ตาม ดังนั้น การซ่อนปุ่มเหล่านี้ เพียงอย่างเดียวไม่เพียงพอ ไม่เพียงแต่จะสิ้นเปลืองแบนด์วิดท์เท่านั้น แต่ผู้ใช้จะไม่เห็นผลลัพธ์จากแบนด์วิดท์ที่เสียไปอีกด้วย ทางออกคือการสร้างบูลีน "is_mobile" ในเทมเพลต Django เพื่อละเว้นส่วนต่างๆ ของ HTML ตามเงื่อนไข เมื่อผู้ใช้ดูเว็บไซต์บนอุปกรณ์อัจฉริยะ ระบบจะไม่แสดงปุ่ม

  • แคชแอปพลิเคชัน - แคชนี้ไม่เพียงช่วยให้เรารองรับการทำงานแบบออฟไลน์เท่านั้น แต่ยังช่วยให้การเริ่มต้นทำงานเร็วขึ้นด้วย

  • การบีบอัด CSS/JS - เราใช้ YUI Compressor แทน Closure Compiler เป็นหลักเนื่องจากสามารถจัดการทั้ง CSS และ JS ได้ ปัญหาอย่างหนึ่งที่เราพบคือ Media Query ในบรรทัด (Media Query ที่ปรากฏภายในสไตล์ชีต) แสดงผลไม่ถูกต้องใน YUI Compressor 2.4.2 (ดูปัญหานี้) การใช้ YUI Compressor 2.4.4 ขึ้นไปช่วยแก้ปัญหาได้

  • ใช้ CSS Image Sprite เมื่อเป็นไปได้

  • ใช้ pngcrush ในการบีบอัดรูปภาพ

  • ใช้ dataURI สำหรับรูปภาพขนาดเล็ก การเข้ารหัส Base64 จะเพิ่มขนาดรูปภาพประมาณ 30%ขึ้นไป แต่จะช่วยประหยัดคำขอเครือข่าย

  • โหลด Google Search ที่กําหนดเองโดยอัตโนมัติโดยใช้แท็กสคริปต์เดียวแทนการโหลดแบบไดนามิกด้วย google.load() ส่วนหลังจะส่งคําขอเพิ่มเติม

<script src="//www.google.com/jsapi?autoload={"modules":[{"name":"search","version":"1"}]}"> </script>
  • เครื่องพิมพ์โค้ดที่ดูดีและ Modernizr ของเรารวมอยู่ในทุกหน้า แม้ว่าจะไม่มีการใช้ก็ตาม Modernizr ยอดเยี่ยม แต่ทําการทดสอบหลายรายการทุกครั้งที่โหลด การทดสอบบางอย่างทําให้เกิดการเปลี่ยนแปลง DOM ที่มีค่าใช้จ่ายสูงและทําให้หน้าเว็บโหลดช้าลง ตอนนี้เราจะรวมเฉพาะไลบรารีเหล่านี้ในหน้าเว็บที่จำเป็นต้องใช้เท่านั้น -2 คำขอ :)

การปรับแต่งประสิทธิภาพเพิ่มเติม

  • ย้าย JS ทั้งหมดไปไว้ที่ด้านล่างของหน้า (หากเป็นไปได้)
  • นำแท็ก <style> ในบรรทัดออกแล้ว
  • การค้นหา DOM ที่แคชไว้และการดําเนินการ DOM ที่ลดลง - ทุกครั้งที่คุณแตะ DOM เบราว์เซอร์จะจัดเรียงใหม่ การจัดเรียงใหม่จะเสียค่าใช้จ่ายมากกว่าในอุปกรณ์เคลื่อนที่
  • ย้ายโค้ดฝั่งไคลเอ็นต์ที่ไม่จำเป็นไปยังเซิร์ฟเวอร์ โดยเฉพาะอย่างยิ่ง การตรวจสอบเพื่อดูการตั้งค่าสไตล์การนำทางของหน้าปัจจุบันมีดังนี้ js var lis = document.querySelectorAll('header nav li'); var i = lis.length; while (i--) { var a = lis[i].querySelector('a'); var section = a.getAttribute("data-section"); if (new RegExp(section).test(document.location.href)) { a.className = 'current'; } }
  • องค์ประกอบที่มีความกว้างคงที่ถูกแทนที่ด้วย width:100% หรือ width:auto แบบยืดหยุ่น

แคชของแอปพลิเคชัน

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

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

เพื่อป้องกันแคชดังกล่าวสำหรับเว็บไซต์ของเรา อันดับแรกเราตั้งค่า App Engine ไม่ให้แคชไฟล์ Manifest ดังนี้

- url: /(.*\.(appcache|manifest))
  static_files: \1
  mime_type: text/cache-manifest
  upload: (.*\.(appcache|manifest))
  expiration: "0s"

ประการที่ 2 เราใช้ JS API เพื่อแจ้งผู้ใช้เมื่อดาวน์โหลดไฟล์ Manifest ใหม่เสร็จแล้ว ระบบจะแจ้งให้ผู้ใช้รีเฟรชหน้าเว็บ

window.applicationCache.addEventListener('updateready', function(e) {
  if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
    window.applicationCache.swapCache();
    if (confirm('A new version of this site is available. Load it?')) {
      window.location.reload();
    }
  }
}, false);

เขียนไฟล์ Manifest ให้เรียบง่ายเพื่อประหยัดการรับส่งข้อมูลในเครือข่าย กล่าวคือ อย่าพูดถึงทุกหน้าในเว็บไซต์ เพียงระบุไฟล์รูปภาพ, CSS และ JavaScript ที่สำคัญ สิ่งสุดท้ายที่ไม่ควรทำคือบังคับให้เบราว์เซอร์บนอุปกรณ์เคลื่อนที่ดาวน์โหลดชิ้นงานจํานวนมากในการอัปเดต AppCache ทุกครั้ง แต่โปรดทราบว่าเบราว์เซอร์จะแคชหน้า html โดยปริยายเมื่อผู้ใช้เข้าชม (และมีแอตทริบิวต์ <html manifest="...">)