अपनी HTML5 साइट को मोब करना

एरिक बिडेलमैन

Twitter GitHub होम पेज

शुरुआती जानकारी

आज के समय में, मोबाइल वेब को डेवलप करने का विषय काफ़ी बना हुआ है. इस साल, पहली बार स्मार्ट फ़ोन बेचे गए पीसी. ज़्यादातर उपयोगकर्ता वेब को एक्सप्लोर करने के लिए मोबाइल डिवाइस का इस्तेमाल कर रहे हैं. इसका मतलब है कि डेवलपर के लिए अपनी साइटों को मोबाइल ब्राउज़र के हिसाब से ऑप्टिमाइज़ करना ज़रूरी हो रहा है.

"मोबाइल" युद्ध का मैदान अब भी बड़ी संख्या में डेवलपर के लिए अनजान पानी है. बहुत से लोगों के पास ऐसी लेगसी साइटें हैं जो मोबाइल उपयोगकर्ताओं पर पूरी तरह से ध्यान नहीं देती हैं. इसके बजाय, साइट को मुख्य तौर पर डेस्कटॉप ब्राउज़िंग के लिए डिज़ाइन किया गया था और मोबाइल ब्राउज़र पर इसे खराब किया गया था. यह साइट (html5rocks.com) कोई अपवाद नहीं है. लॉन्च के समय, हमने साइट के मोबाइल वर्शन पर बहुत कम मेहनत की.

मोबाइल-फ़्रेंडली html5rocks.com बनाना

एक अभ्यास के रूप में, मैंने सोचा कि html5rocks (मौजूदा HTML5 साइट) को लेना और मोबाइल-फ़्रेंडली वर्शन से इसे बढ़ाना दिलचस्प होगा. मैं मुख्य रूप से इस बात को लेकर चिंतित थी कि स्मार्ट फ़ोन को टारगेट करने के लिए कम से कम कितना काम करना ज़रूरी है. मेरे अभ्यास का लक्ष्य एक पूरी तरह से नई मोबाइल साइट बनाकर दो कोडबेस बनाए रखना नहीं था. इसमें समय लगता है और इससे समय की बहुत बड़ी बर्बादी होती है. हमने पहले ही साइट का स्ट्रक्चर (मार्कअप) तय कर दिया था. हमारे पास एक नई पहचान (सीएसएस) है. इसमें मुख्य फ़ंक्शन (JS) काम करता था. पॉइंट की बात तो यह है कि कई जगहें एक ही नाव में मौजूद हैं.

इस लेख में बताया गया है कि हमने Android और iOS डिवाइसों के लिए, ऑप्टिमाइज़ किए गए html5rock का मोबाइल वर्शन कैसे बनाया है. अंतर देखने के लिए बस html5rocks.com को किसी ऐसे OS पर लोड करें जो उन OS में से किसी एक को सपोर्ट करता हो. m.html5rocks.com या इस तरह की किसी दूसरी बड़ी फ़ाइल पर रीडायरेक्ट नहीं किए जाते. आपको html5rocks मिलते हैं, जैसे कि... एक ऐसी चीज़ का अतिरिक्त लाभ जो शानदार दिखता है और मोबाइल डिवाइस पर अच्छा काम करता है.

डेस्कटॉप (बाएं) और मोबाइल (दाएं) पर html5rocks.com

सीएसएस मीडिया क्वेरी

HTML4 और CSS2 पर कुछ समय से मीडिया-निर्भर स्टाइल शीट का इस्तेमाल किया जा सकता है. उदाहरण के लिए:

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

यह प्रिंट डिवाइसों को टारगेट करेगा और प्रिंट किए जाने पर, पेज के कॉन्टेंट के लिए खास स्टाइल उपलब्ध कराएगा. CSS3, मीडिया टाइप के आइडिया को एक कदम आगे ले जाता है और मीडिया क्वेरी के साथ उसकी सुविधाओं को बेहतर बनाता है. मीडिया क्वेरी, स्टाइल शीट पर ज़्यादा सटीक लेबल लगाने की अनुमति देकर, मीडिया टाइप की अहमियत बढ़ाती है. इससे कॉन्टेंट को दिखाए जाने पर, कॉन्टेंट में बदलाव किए बिना उसे आउटपुट डिवाइसों की खास रेंज के मुताबिक बनाया जा सकता है. मौजूदा लेआउट के लिए यह बिलकुल सही है, जिसे बदलने की ज़रूरत है!

बाहरी स्टाइलशीट के media एट्रिब्यूट में मौजूद मीडिया क्वेरी का इस्तेमाल, स्क्रीन की चौड़ाई, डिवाइस की चौड़ाई, ओरिएंटेशन वगैरह को टारगेट करने के लिए किया जा सकता है. पूरी सूची के लिए, W3C मीडिया क्वेरी की खास बातें देखें.

टारगेटिंग स्क्रीन साइज़

नीचे दिए गए उदाहरण में, phone.css उन डिवाइसों पर लागू होगा जिन्हें ब्राउज़र "हैंडहेल्ड" मानता है या उन डिवाइसों पर लागू होगा जिनकी स्क्रीन की चौड़ाई <= 320 पिक्सल है.

 <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" को अनदेखा नहीं करता. media="handheld" को पहचानने के लिए Windows मोबाइल का तरीका यह है कि स्क्रीन स्टाइलशीट के लिए मीडिया एट्रिब्यूट की वैल्यू को कैपिटल में रखें:

 <!-- 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 का मुख्य लुक और स्टाइल तय किया है. हालांकि, अब हम 800 पिक्सल से कम चौड़ाई वाली स्क्रीन के लिए नई स्टाइल (mobile.css) लागू कर रहे हैं. इसकी मीडिया क्वेरी में, स्मार्ट फ़ोन (~320 पिक्सल) और iPad (~768 पिक्सल) को शामिल किया गया है. असर: हम base.css में स्टाइल को लगातार बदल रहे हैं (सिर्फ़ ज़रूरत के हिसाब से) ताकि मोबाइल में चीज़ों को बेहतर बनाया जा सके.

mobile.css की मदद से, स्टाइल में किए गए कुछ बदलाव लागू किए गए हैं:

• पूरी साइट पर अतिरिक्त खाली सफ़ेद जगह/पैडिंग को कम करता है. छोटी स्क्रीन का मतलब है कि जगह काफ़ी आकर्षक है!
• :hover राज्य हटा दिया जाता है. इन्हें छूने वाले डिवाइसों पर कभी नहीं देखा जाएगा.
• लेआउट को सिंगल कॉलम में अडजस्ट करता है. इस विषय पर ज़्यादा जानकारी बाद में.
• साइट के मुख्य कंटेनर डिव के आस-पास मौजूद box-shadow को हटा देता है. बॉक्स के बड़े शैडो पेज की परफ़ॉर्मेंस को कम करते हैं.
• होम पेज पर हर सेक्शन का क्रम बदलने के लिए, सीएसएस के फ़्लेक्स बॉक्स मॉडल box-ordinal-group का इस्तेमाल किया गया. आपको दिखेगा कि "मेजर HTML5 फ़ीचर ग्रुप से सीखें", होम पेज पर "ट्यूटोरियल" सेक्शन से पहले आता है, लेकिन मोबाइल वर्शन पर इसके बाद आता है. यह क्रम मोबाइल के लिए ज़्यादा काम का साबित हुआ और इसके लिए मार्कअप में बदलाव करने की ज़रूरत नहीं पड़ी. सीएसएस फ़्लेक्सबॉक्स 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 को सेट करने से iPhone पर width=device-width और कुछ अन्य स्मार्टफ़ोन पर जैसा नतीजा मिलेगा. ध्यान रखें कि हर फ़ोन की चौड़ाई इतनी सटीक नहीं होती, इसलिए बेहतर है कि आप device-width के साथ बने रहें और बाकी काम ब्राउज़र पर छोड़ दें.

Android, व्यूपोर्ट मेटा टैग का दायरा बढ़ाता है. ऐसा करने के लिए, डेवलपर यह तय कर सकते हैं कि साइट को किस स्क्रीन रिज़ॉल्यूशन के लिए बनाया गया है:

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

target-densitydpi की वैल्यू हो सकती हैं: device-dpi, high-dpi, medium-dpi, low-dpi.

अगर आपको अलग-अलग स्क्रीन डेंसिटी के लिए अपने वेब पेज में बदलाव करना है, तो -webkit-device-pixel-ratio सीएसएस मीडिया क्वेरी और/या JavaScript में window.devicePixelRatio प्रॉपर्टी का इस्तेमाल करें. इसके बाद, target-densitydpi मेटा प्रॉपर्टी को device-dpi पर सेट करें. यह Android को आपके वेब पेज में स्केलिंग करने से रोकता है और आपको CSS और JavaScript के ज़रिए, हर सघनता के लिए ज़रूरी समायोजन करने देता है.

डिवाइस रिज़ॉल्यूशन को टारगेट करने के बारे में ज़्यादा जानकारी के लिए, Android का वेबव्यू दस्तावेज़ देखें.

फ़ुल-स्क्रीन ब्राउज़िंग

दो अन्य मेटा वैल्यू हैं, जो iOS-sfix हैं. 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, मोबाइल मेटा टैग का इस्तेमाल कैसे करता है

सब कुछ एक साथ मिलाकर, यहां html5rocks के <head> सेक्शन से एक स्निपेट दिया गया है:

 <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/सीएसएस कंप्रेस करने, gzipping (App Engine पर मुफ़्त में मिलने), और DOM में होने वाले बदलाव कम करने जैसी चीज़ें. ये तरीके सबसे सही तरीके हैं. हालांकि, कभी-कभी इन तरीकों पर ध्यान नहीं दिया जाता.

पता बार अपने-आप छिपाएं

मोबाइल ब्राउज़र के डेस्कटॉप वर्शन की स्क्रीन रीयल एस्टेट में नहीं है. सबसे खराब स्थिति के लिए, अलग-अलग प्लैटफ़ॉर्म पर कभी-कभी आपको स्क्रीन पर सबसे ऊपर एक बड़ा पता बार दिखता है... पेज लोड होने के बाद भी.

इससे आसानी से बचने के लिए, JavaScript का इस्तेमाल करके पेज को स्क्रोल करना होगा. एक पिक्सल से भी ऐसा करने पर, समस्या वाले पता बार की समस्या हल हो जाएगी. html5rocks पर पता बार को ज़बरदस्ती छिपाने के लिए, मैंने window ऑब्जेक्ट में एक onload इवेंट हैंडलर अटैच किया और पेज को एक पिक्सल से वर्टिकल रूप से स्क्रोल किया:

Ugly पता बार, रीयल एस्टेट की स्क्रीन पर दिखता है.

  // 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 टेंप्लेट वैरिएबल के तौर पर भी रैप कर लिया है, क्योंकि डेस्कटॉप पर इसकी ज़रूरत नहीं है.

नेटवर्क के अनुरोध कम करें, बैंडविड्थ बचाएं

हम जानते हैं कि एचटीटीपी अनुरोधों की संख्या कम करने से, परफ़ॉर्मेंस में काफ़ी सुधार हो सकता है. मोबाइल डिवाइस, ब्राउज़र से एक साथ किए जाने वाले कनेक्शन की संख्या को और भी सीमित कर देते हैं, जिससे मोबाइल साइटों को इन बाहरी अनुरोधों को कम करने का और भी ज़्यादा फ़ायदा मिलेगा. इसके अलावा, हर बाइट को शेव करना बहुत ज़रूरी है क्योंकि फ़ोन पर बैंडविड्थ अक्सर सीमित होता है. आपसे उपयोगकर्ताओं के लिए पैसे खर्च किए जा सकते हैं!

नेटवर्क अनुरोधों को कम करने और html5rocks पर बैंडविड्थ को कम करने के लिए, हमने ये तरीके अपनाए हैं:

• iframe हटाएं - iframes धीमे होते हैं! हमारे ट्यूटोरियल पेजों पर तीसरे पक्ष के शेयर करने वाले विजेट (Zoom, Google Connect, Twitter, Facebook) से इंतज़ार के समय का एक बड़ा हिस्सा आया. ये एपीआई <script> टैग के ज़रिए शामिल किए गए थे और ऐसे iframe बनाए गए थे जो पेज की स्पीड कम कर देते हैं. मोबाइल से विजेट हटा दिए गए थे.

• display:none - कुछ मामलों में, अगर मार्कअप मोबाइल प्रोफ़ाइल के मुताबिक नहीं होता है, तो हम उसे छिपा देते थे. सबसे अच्छे उदाहरण में, होम पेज पर सबसे ऊपर मौजूद चार गोल बॉक्स हैं:

होम पेज पर मौजूद बॉक्स बटन.

वे मोबाइल साइट पर मौजूद नहीं हैं. यह याद रखना ज़रूरी है कि display:none के साथ छिपे हुए कंटेनर के बावजूद ब्राउज़र, हर आइकॉन के लिए अब भी अनुरोध करता है. इसलिए, सिर्फ़ इन बटनों को छिपाना काफ़ी नहीं था. इससे न सिर्फ़ बैंडविड्थ की बर्बादी होगी, बल्कि उपयोगकर्ता को इस बेकार बैंडविड्थ का फ़ायदा भी नहीं दिखेगा! इसका हल था कि हमारे Django टेंप्लेट में "is_mobile" बूलियन को बनाया जाए, ताकि एचटीएमएल के सेक्शन को शर्त के मुताबिक हटाया जा सके. जब उपयोगकर्ता किसी स्मार्ट डिवाइस पर साइट को देख रहा होता है, तब बटन नहीं दिखते.

• ऐप्लिकेशन कैश - इससे न सिर्फ़ हमें ऑफ़लाइन मदद मिलती है, बल्कि यह तेज़ी से शुरू होने वाला स्टार्टअप भी है.

• सीएसएस/JS कंप्रेशन - हम Closure कंपाइलर के बजाय YUI कंप्रेसर का इस्तेमाल कर रहे हैं, क्योंकि यह सीएसएस और JS, दोनों को हैंडल करता है. हमें एक समस्या का सामना करना पड़ा. यह था कि इनलाइन मीडिया क्वेरी (स्टाइलशीट के अंदर दिखने वाली मीडिया क्वेरी) को YUI कंप्रेसर 2.4.2 में फ़िल्टर किया गया था. यह समस्या देखें. YUI कंप्रेसर 2.4.4+ का उपयोग करने से समस्या ठीक हो गई.

• जहां संभव हो वहां सीएसएस इमेज स्प्राइट का इस्तेमाल किया जाता है.

• इमेज कंप्रेस करने के लिए, pngcrush का इस्तेमाल किया गया.

• छोटी इमेज के लिए dataयूआरआई का इस्तेमाल किया गया. Base64 एन्कोडिंग, इमेज में ~30%+ साइज़ जोड़ती है, लेकिन नेटवर्क के अनुरोध को सेव करती है.

• Google कस्टम खोज को 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 का मोबाइल वर्शन, शुरुआती लोड को तेज़ करने के लिए ऐप्लिकेशन कैश का इस्तेमाल करता है और उपयोगकर्ताओं को ऑफ़लाइन कॉन्टेंट पढ़ने की सुविधा देता है.

अपनी साइट पर Appकैश लागू करते समय, यह बहुत ज़रूरी है कि आप अपनी मेनिफ़ेस्ट फ़ाइल कैश मेमोरी में न सेव करें. आप चाहें, तो मेनिफ़ेस्ट फ़ाइल को साफ़ तौर पर कैश मेमोरी में सेव करें या किसी ऐसे तरीके से कैश मेमोरी में सेव न करें जिसमें भारी कैश कंट्रोल हेडर हो. अगर ब्राउज़र, आपका मेनिफ़ेस्ट कैश मेमोरी में सेव कर लेता है, तो इसे डीबग करना मुश्किल होता है. iOS और Android इस फ़ाइल को कैश मेमोरी में सेव करने का अच्छा काम करते हैं, लेकिन यह डेस्कटॉप ब्राउज़र की तरह कैश मेमोरी को साफ़ करने का आसान तरीका नहीं उपलब्ध कराते.

हमारी साइट को कैश मेमोरी में सेव करने का अनुरोध रोकने के लिए, हमने सबसे पहले App Engine को इस तरह सेट किया कि मेनिफ़ेस्ट फ़ाइलों को कैश मेमोरी में सेव न किया जाए:

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

दूसरा, नए मेनिफ़ेस्ट के डाउनलोड होने के बाद, हमने JS API का इस्तेमाल लोगों को सूचना देने के लिए किया. उन्हें पेज को रीफ़्रेश करने के लिए कहा जाता है:

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);

नेटवर्क ट्रैफ़िक बचाने के लिए, अपने मेनिफ़ेस्ट को आसान रखें. इसका मतलब है कि, अपनी साइट के हर पेज के बारे में कॉल न करें. बस ज़रूरी इमेज, सीएसएस, और JavaScript फ़ाइलों की सूची बनाएं. इसके लिए, आपको मोबाइल ब्राउज़र को हर बार कैश मेमोरी में होने वाले हर अपडेट के दौरान, बड़ी संख्या में एसेट डाउनलोड करने के लिए मजबूर करना होगा. इसके बजाय, ध्यान रखें कि जब उपयोगकर्ता इस पेज पर जाएगा, तब ब्राउज़र किसी एचटीएमएल पेज को कैश मेमोरी में सेव करेगा. (इसमें <html manifest="..."> एट्रिब्यूट शामिल है).