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

เกริ่นนำ

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

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

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

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

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

คำค้นหาสื่อ CSS

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

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

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

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

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

ในตัวอย่างต่อไปนี้ phone.css จะใช้กับอุปกรณ์ที่เบราว์เซอร์ถือว่า "ถือได้" หรืออุปกรณ์ที่มีหน้าจอกว้าง <= 320px

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

การใส่คำนำหน้าคำค้นหาสื่อด้วยคีย์เวิร์ด "only" จะทำให้เบราว์เซอร์ที่ไม่สอดคล้องกับ 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 ใช้คิวรี่สื่อ

คำค้นหาสื่อมีการใช้อย่างแพร่หลายใน 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 Flex Box box-ordinal-group เพื่อเปลี่ยนลำดับของแต่ละส่วนในหน้าแรก คุณจะสังเกตเห็น "เรียนรู้ตามกลุ่มคุณลักษณะ HTML5 หลัก" อยู่ก่อนส่วน "บทแนะนำ" ในหน้าแรก แต่ภายหลังในรุ่นสำหรับมือถือ การจัดเรียงแบบนี้ทำให้เหมาะกับอุปกรณ์เคลื่อนที่มากขึ้นและไม่จำเป็นต้องมีการเปลี่ยนแปลงมาร์กอัป CSS Flexbox FTW!
• นำการเปลี่ยนแปลง opacity รายการออก การเปลี่ยนค่าอัลฟ่าคือ Hit ประสิทธิภาพบนอุปกรณ์เคลื่อนที่

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

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

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

 <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-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 ในการสร้างเค้าโครงดังกล่าว ขอย้ำอีกครั้งโดยไม่ต้องเปลี่ยน มาร์กอัป

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

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

เรายังรวม Listener นี้เป็นตัวแปรเทมเพลต 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 แทนคอมไพเลอร์ Closure เนื่องจากจัดการทั้ง CSS และ JS ปัญหาหนึ่งที่เราพบคือ คำค้นหาสื่อแบบอินไลน์ (คำค้นหาสื่อที่ปรากฏในสไตล์ชีต) ที่แทรกขยายในคอมเพรสเซอร์ YUI 2.4.2 (ดู ปัญหานี้) การใช้ YUI Compressor 2.4.4+ ได้รับการแก้ไขแล้ว

• ใช้ภาพแบบ Sprite ของ CSS หากเป็นไปได้

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

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

• โหลด Google Custom 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 ที่มีส่วนหัวการควบคุมแคชจำนวนมาก) หากไฟล์ 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="...">)