การปรับเว็บไซต์ HTML5 ให้เหมาะกับอุปกรณ์เคลื่อนที่

Eric Bidelman

บทนำ

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

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

การสร้าง html5rocks.com ที่เหมาะกับมือถือ

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

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

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

CSS Media Query

HTML4 และ CSS2 รองรับสไตล์ชีตที่ขึ้นอยู่กับสื่อมาเป็นระยะเวลาหนึ่งแล้ว เช่น

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

จะกำหนดเป้าหมายเป็นอุปกรณ์การพิมพ์และจัดรูปแบบเฉพาะสำหรับเนื้อหาของหน้าเมื่อพิมพ์ CSS3 นำแนวคิดเรื่องประเภทสื่อไปอีกขั้นหนึ่งและปรับปรุงฟังก์ชันการทำงานด้วย Media Queries 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'>

Media Query ยังปรากฏในแท็ก <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 อย่างมากใน 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 พิกเซล การสืบค้นสื่อครอบคลุมสมาร์ทโฟน (~320px) และ iPad (~768px) ผลลัพธ์: เรากำลังลบล้างสไตล์ใน base.css ทีละน้อย (เฉพาะที่จำเป็น) เพื่อให้สิ่งต่างๆ ดูดีขึ้นในอุปกรณ์เคลื่อนที่

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

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

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

Mobile 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">

หมายเหตุ: width สามารถใช้ค่าพิกเซลได้ด้วย การตั้งค่า width=320 จะให้ผลลัพธ์เหมือนกับ width=device-width ใน iPhone และสมาร์ทโฟนอื่นๆ บางรุ่น โปรดทราบว่าโทรศัพท์บางรุ่นอาจไม่ได้มีความกว้างเท่านี้ ดังนั้นจึงควรใช้ device-width และปล่อยให้เบราว์เซอร์จัดการส่วนที่เหลือ

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

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

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

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

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

การท่องเว็บแบบเต็มหน้าจอ

มีค่าเมตาอีก 2 ค่าที่เจาะจงสำหรับ iOS 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 Media Queries เพื่อสร้างเลย์เอาต์ดังกล่าว โดยไม่ต้องเปลี่ยนมาร์กอัป

เลย์เอาต์แนวตั้งแบบคอลัมน์เดียวทั่วทั้งเว็บไซต์

การเพิ่มประสิทธิภาพสำหรับมือถือ

การเพิ่มประสิทธิภาพส่วนใหญ่ที่เราทำเป็นสิ่งที่ควรทำตั้งแต่แรกอยู่แล้ว เช่น การลดจำนวนคำขอเครือข่าย การบีบอัด JS/CSS, gzipping (มีให้ใช้ฟรีใน 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);

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

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

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

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

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

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

ปุ่ม Box ในหน้าแรก

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

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

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

• ใช้ CSS Image Sprite หากเป็นไปได้

• ใช้ pngcrush เพื่อบีบอัดรูปภาพ

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

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

<script src="//www.google.com/jsapi?autoload={"modules":[{"name":"search","version":"1"}]}"> </script>

• โค้ด Pretty Printer และ 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="...">)