ভূমিকা
মোবাইল ওয়েবের জন্য ডেভেলপ করা আজকাল একটি হট টপিক। এই বছর, প্রথমবারের মতো, স্মার্ট ফোন পিসি-র চেয়ে বেশি বিক্রি হয়েছে। আরও বেশি সংখ্যক ব্যবহারকারী ওয়েব ব্রাউজ করার জন্য মোবাইল ডিভাইস ব্যবহার করছেন, যার অর্থ হল ডেভেলপারদের জন্য মোবাইল ব্রাউজারের জন্য তাদের সাইট অপ্টিমাইজ করা গুরুত্বপূর্ণ হয়ে উঠছে।
"মোবাইল" যুদ্ধক্ষেত্রটি এখনও বিপুল সংখ্যক ডেভেলপারদের কাছে অজানা। অনেকেরই পুরনো সাইট আছে যা মোবাইল ব্যবহারকারীদের জন্য উপযুক্ত নয়। পরিবর্তে, সাইটটি মূলত ডেস্কটপ ব্রাউজিংয়ের জন্য ডিজাইন করা হয়েছে এবং মোবাইল ব্রাউজারে খারাপভাবে কাজ করে। এই সাইট (html5rocks.com) এর ব্যতিক্রম নয়। লঞ্চের সময়, আমরা সাইটের মোবাইল ভার্সনের জন্য একটু পরিশ্রম করেছিলাম।
মোবাইলে সুবিধাজনক html5rocks.com তৈরি করা
অনুশীলন হিসেবে আমি ভেবেছিলাম html5rocks (একটি বর্তমান HTML5 সাইট) নিয়ে সেটিকে মোবাইল-ফ্রেন্ডলি ভার্সনে রূপান্তর করলে ভালো হয়। স্মার্টফোনকে টার্গেট করার জন্য ন্যূনতম কতটা কাজ করতে হবে, সেটি নিয়েই আমি মূলত চিন্তিত ছিলাম। আমার এই অনুশীলনের লক্ষ্য সম্পূর্ণ নতুন মোবাইল সাইট তৈরি করা এবং দুটি কোডবেস বজায় রাখা ছিল না। এতে অনেক সময় লেগে যেত এবং প্রচুর সময় নষ্ট হত। আমরা আগেই সাইটের স্ট্রাকচার (মার্কআপ) নির্ধারণ করে রেখেছিলাম। আমাদের কাছে লুক অ্যান্ড ফিল (CSS) ছিল। মূল কার্যকারিতা (JS) ছিল। আসল কথা হল, অনেক সাইটই এই একই সমস্যায় ভুগছে।
এই নিবন্ধে আমরা Android এবং iOS ডিভাইসের জন্য অপ্টিমাইজ করা html5rocks-এর একটি মোবাইল ভার্সন কীভাবে তৈরি করেছি তা পরীক্ষা করে। পার্থক্য দেখতে, এই OS-এর মধ্যে যেকোনও একটি কাজ করে এমন ডিভাইসে html5rocks.com লোড করুন। m.html5rocks.com বা এই ধরনের অন্য কোনও বোকা বোকা সাইটে রিডাইরেক্ট করা হয় না। আপনি html5rocks যেমন আছে তেমনই পাবেন… সাথে এমন কিছু অতিরিক্ত সুবিধা পাবেন যা মোবাইল ডিভাইসে দেখতে দারুণ লাগে এবং ভাল কাজ করে।
CSS মিডিয়া কোয়েরি
HTML4 এবং CSS2-এ কিছু সময়ের জন্য মিডিয়া-নির্ভর স্টাইল শিট কাজ করেছে। যেমন:
<link rel="stylesheet" media="print" href="printer.css">
প্রিন্ট ডিভাইসকে টার্গেট করবে এবং পৃষ্ঠার কন্টেন্ট প্রিন্ট করার সময় সেটির জন্য নির্দিষ্ট স্টাইলিং প্রদান করবে। CSS3 মিডিয়ার ধরন সংক্রান্ত ধারণাকে আরও এক ধাপ এগিয়ে নিয়ে যায় এবং মিডিয়া কোয়েরির মাধ্যমে সেগুলির কার্যকারিতা উন্নত করে। মিডিয়া কোয়েরি স্টাইল শিটের আরও নিখুঁত লেবেলিংয়ের অনুমতি দিয়ে মিডিয়ার ধরনের উপযোগিতা বাড়ায়। এর ফলে কন্টেন্ট পরিবর্তন না করেই নির্দিষ্ট রেঞ্জের আউটপুট ডিভাইসের জন্য কন্টেন্টের প্রেজেন্টেশন কাস্টমাইজ করা যায়। আগে থেকে থাকা লেআউট যা পরিবর্তন করতে হবে, তার জন্য এটি একদম উপযুক্ত!
স্ক্রিনের প্রস্থ, ডিভাইসের প্রস্থ, ওরিয়েন্টেশন ইত্যাদি টার্গেট করতে আপনি এক্সটার্নাল স্টাইলশিটের media অ্যাট্রিবিউটে মিডিয়া কোয়েরি ব্যবহার করতে পারেন। সম্পূর্ণ তালিকা দেখতে, W3C মিডিয়া কোয়েরি স্পেসিফিকেশন দেখুন।
স্ক্রিন সাইজ টার্গেট করা
নিচের উদাহরণে, phone.css সেইসব ডিভাইসে প্রযোজ্য হবে
যেগুলিকে ব্রাউজার "হ্যান্ডহেল্ড" বা <= ৩২০ পিক্সেল চওড়া স্ক্রিনযুক্ত ডিভাইস হিসেবে বিবেচনা করে।
<link rel='stylesheet'
media='handheld, only screen and (max-device-width: 320px)' href='phone.css'>
মিডিয়া কোয়েরির আগে "only" কীওয়ার্ড যোগ করলে,
CSS3-কমপ্লায়েন্ট নয় এমন ব্রাউজার নিয়মটি উপেক্ষা করবে।
নিম্নলিখিত কোডটি ৬৪১ পিক্সেল থেকে ৮০০ পিক্সেলের মধ্যে স্ক্রিনের সাইজকে টার্গেট করবে:
<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) প্রয়োগ করছি। এর মিডিয়া কোয়েরি স্মার্ট ফোন (~৩২০ পিক্সেল) এবং iPad (~৭৬৮ পিক্সেল) কভার করে।
এর ফলে: আমরা base.css-এ ধীরে ধীরে স্টাইল ওভাররাইড করছি (শুধুমাত্র প্রয়োজন অনুযায়ী)
যাতে মোবাইলে সবকিছু আরও ভাল দেখায়।
mobile.css-এর মাধ্যমে প্রয়োগ করা স্টাইলিং সংক্রান্ত কিছু পরিবর্তন:
- সাইট জুড়ে অতিরিক্ত হোয়াইটস্পেস/প্যাডিং কমায়। ছোট স্ক্রিন মানেই হল জায়গা কম!
:hoverটি রাজ্য সরিয়ে দেয়। টাচ ডিভাইসে সেগুলি কখনও দেখা যাবে না।- সিঙ্গেল কলামে লেআউট অ্যাডজাস্ট করে। এই বিষয়ে পরে আরও জানানো হবে।
- সাইটের মূল কন্টেনার div-এর চারপাশে থাকা
box-shadowসরিয়ে দেয়। বড় বক্স শ্যাডো পৃষ্ঠার পারফর্ম্যান্স কমিয়ে দেয়। - হোমপেজের প্রতিটি বিভাগের ক্রম পরিবর্তন করতে CSS ফ্লেক্স বক্স মডেল
box-ordinal-groupব্যবহার করা হয়েছে। আপনি লক্ষ্য করবেন যে "প্রধান HTML5 ফিচার গ্রুপ থেকে শিখুন" বিভাগটি হোমপেজে "টিউটোরিয়াল" বিভাগের আগে আসে, কিন্তু মোবাইল ভার্সনে এটি পরে আসে। এই ক্রমটি মোবাইলের জন্য আরও বেশি অর্থপূর্ণ ছিল এবং মার্কআপ পরিবর্তনের প্রয়োজন ছিল না। CSS flexbox FTW! opacityটি পরিবর্তন সরিয়ে দেয়। আলফা ভ্যালু পরিবর্তন করলে মোবাইলের পারফর্ম্যান্সের উপর প্রভাব পড়ে।
মোবাইল মেটা ট্যাগ
মোবাইল WebKit-এ এমন কিছু সুবিধা আছে যা নির্দিষ্ট কিছু ডিভাইসে ব্যবহারকারীদের আরও ভালো ব্রাউজিং অভিজ্ঞতা প্রদান করে।
ভিউপোর্ট সেটিংস
প্রথম মেটা সেটিং (এবং যেটি আপনি সবচেয়ে বেশি ব্যবহার করবেন) হল ভিউপোর্ট প্রপার্টি। ভিউ পোর্ট সেট করলে ব্রাউজার বুঝতে পারে যে ডিভাইসের স্ক্রিনে কন্টেন্ট কীভাবে ফিট করতে হবে এবং ব্রাউজারকে জানায় যে সাইটটি মোবাইলের জন্য অপ্টিমাইজ করা হয়েছে। যেমন:
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">
ব্রাউজারকে ডিভাইসের প্রস্থ অনুযায়ী ভিউপোর্ট সেট করতে বলে, যার প্রাথমিক স্কেল হল ১। এই উদাহরণে জুম করার সুবিধাও দেওয়া হয়েছে, যা কোনও ওয়েবসাইটের জন্য
প্রয়োজনীয় হলেও ওয়েব অ্যাপের জন্য নয়। আমরা 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
প্রপার্টি ব্যবহার করুন, তারপর target-densitydpi মেটা প্রপার্টি
device-dpi-এ সেট করুন। এটি আপনার ওয়েব পেজে Android-কে স্কেলিং করা থেকে আটকায় এবং CSS ও জাভাস্ক্রিপ্টের মাধ্যমে প্রতিটি ডেনসিটির জন্য প্রয়োজনীয় অ্যাডজাস্টমেন্ট করতে দেয়।
টার্গেট ডিভাইসের রেজোলিউশন সম্পর্কে আরও তথ্যের জন্য Android-এর WebView ডকুমেন্টেশন দেখুন।
ফুল-স্ক্রিন ব্রাউজিং
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 কীভাবে মোবাইল মেটা ট্যাগ ব্যবহার করে
সবকিছু একসাথে করে, 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/CSS কম্প্রেশন, gzipping (App Engine-এ ফ্রিতে পাওয়া যায়) এবং DOM ম্যানিপুলেশন কমানোর মতো বিষয়। এইসব টেকনিক হল সাধারণ পেশাদার পদ্ধতি কিন্তু তাড়াহুড়ো করে সাইট লঞ্চ করার সময় এগুলি মাঝে মাঝে এড়িয়ে যাওয়া হয়।
অ্যাড্রেস বার অটোমেটিক লুকান
মোবাইল ব্রাউজারে ডেস্কটপের মতো স্ক্রিন রিয়েল এস্টেট থাকে না। পরিস্থিতি আরও খারাপ করতে, বিভিন্ন প্ল্যাটফর্মে, আপনি কখনও কখনও স্ক্রিনের উপরে একটি বড় পুরানো অ্যাড্রেস বার দেখতে পান… এমনকি পৃষ্ঠাটি লোড হওয়ার পরেও।
এটি সমাধান করার একটি সহজ উপায় হল জাভাস্ক্রিপ্ট ব্যবহার করে পৃষ্ঠা স্ক্রল করা।
এমনকি এক পিক্সেল স্ক্রল করলেও বিরক্তিকর অ্যাড্রেস বার থেকে মুক্তি পাওয়া যাবে।
html5rocks-এ অ্যাড্রেস বার জোর করে লুকানোর জন্য, আমি window অবজেক্টে একটি onload
ইভেন্ট হ্যান্ডলার অ্যাটাচ করেছি এবং পৃষ্ঠাটি উল্লম্বভাবে
এক পিক্সেল স্ক্রল করেছি:
// 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- কিছু ক্ষেত্রে, আমরা মার্কআপ লুকিয়ে রাখছিলাম যদি এটি মোবাইল প্রোফাইলের সাথে মানানসই না হয়। হোমপেজের উপরে চারটি গোলাকার বক্স এর একটি ভালো উদাহরণ:
মোবাইল সাইটে সেগুলি নেই। মনে রাখবেন,
display:none ব্যবহার করে কন্টেনার লুকানো থাকলেও
ব্রাউজার প্রতিটি আইকনের জন্য অনুরোধ করে। তাই, শুধু এই বোতামগুলি লুকানোই
যথেষ্ট ছিল না। এতে শুধু ব্যান্ডউইথ নষ্ট হবে না, ব্যবহারকারী সেই নষ্ট হওয়া ব্যান্ডউইথের
ফলও দেখতে পাবেন না! সমাধানটি ছিল আমাদের Django টেমপ্লেটে একটি
"is_mobile" বুলিয়ান তৈরি করা যাতে শর্তসাপেক্ষে HTML-এর বিভাগগুলি বাদ দেওয়া যায়।
ব্যবহারকারী স্মার্ট ডিভাইসে সাইট দেখলে, বোতামগুলি বাদ দেওয়া হয়।
অ্যাপ্লিকেশন ক্যাশে - এটি আমাদের অফলাইন সহায়তা প্রদান করার পাশাপাশি দ্রুত স্টার্টআপও তৈরি করে।
CSS/JS কম্প্রেশন - আমরা Closure কম্পাইলার-এর পরিবর্তে YUI কম্প্রেসর ব্যবহার করছি প্রধানত কারণ এটি CSS এবং JS উভয়ই পরিচালনা করে। আমরা যে সমস্যার সম্মুখীন হয়েছিলাম তা হল ইনলাইন মিডিয়া কোয়েরি (মিডিয়া কোয়েরি যা স্টাইলশিটের মধ্যে দেখা যায়) YUI কম্প্রেসর 2.4.2-এ কাজ করেনি (এই সমস্যা দেখুন)। YUI Compressor 2.4.4+ ব্যবহার করে সমস্যার সমাধান করা হয়েছে।
সম্ভব হলে CSS ইমেজ স্প্রাইট ব্যবহার করা হয়েছে।
ছবি কম্প্রেস করার জন্য pngcrush ব্যবহার করা হয়েছে।
ছোট ছবির জন্য dataURI ব্যবহার করা হয়েছে। Base64 এনকোডিং ছবির সাইজ ~৩০%+ বাড়িয়ে দেয় কিন্তু নেটওয়ার্ক রিকোয়েস্ট সেভ করে।
google.load()-এর মাধ্যমে ডায়নামিকালি লোড করার পরিবর্তে একটি স্ক্রিপ্ট ট্যাগ ব্যবহার করে Google কাস্টম সার্চ অটোমেটিক লোড করা হয়েছে। পরেরটি অতিরিক্ত অনুরোধ করে।
<script src="//www.google.com/jsapi?autoload={"modules":[{"name":"search","version":"1"}]}"> </script>
- আমাদের কোড প্রিটি প্রিন্টার এবং Modernizr প্রতিটি পৃষ্ঠায় অন্তর্ভুক্ত করা হচ্ছিল, এমনকি সেগুলি কখনও ব্যবহার না করা হলেও। Modernizr খুব ভালো, কিন্তু এটি প্রতিবার লোড হওয়ার সময় অনেক টেস্ট রান করে। এইসব টেস্টের মধ্যে কিছু টেস্ট DOM-এ ব্যয়বহুল পরিবর্তন করে এবং পৃষ্ঠা লোড হওয়ার গতি কমিয়ে দেয়। এখন, আমরা শুধুমাত্র সেইসব পৃষ্ঠায় এই লাইব্রেরিগুলি অন্তর্ভুক্ত করছি যেখানে সেগুলি সত্যিই প্রয়োজন। -২টি অনুরোধ :)
পারফর্ম্যান্সের অতিরিক্ত রদবদল:
- সব 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 প্রয়োগ করার সময়, এটি খুবই গুরুত্বপূর্ণ যে আপনি যেন আপনার ম্যানিফেস্ট ফাইল ক্যাশে না করেন (ম্যানিফেস্ট ফাইলে স্পষ্টভাবে বা ভারী ক্যাশে কন্ট্রোল হেডারের সাথে অস্পষ্টভাবে)। ব্রাউজার আপনার ম্যানিফেস্ট ক্যাশে করলে, ডিবাগ করা খুব কঠিন হয়ে যায়। 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);
নেটওয়ার্ক ট্রাফিক বাঁচাতে আপনার ম্যানিফেস্ট সহজ রাখুন। অর্থাৎ, আপনার সাইটের প্রতিটি পৃষ্ঠার
নাম উল্লেখ করবেন না। শুধু গুরুত্বপূর্ণ ছবি, CSS এবং
JavaScript ফাইলের তালিকা তৈরি করুন। আপনি শেষ যে কাজটি করতে চান তা হল, প্রতিটি appcache আপডেটে
মোবাইল ব্রাউজারকে প্রচুর সংখ্যক অ্যাসেট ডাউনলোড করতে বাধ্য করা। পরিবর্তে, মনে রাখবেন
যে ব্যবহারকারী ভিজিট করলে ব্রাউজার অন্তর্নিহিতভাবে একটি html পৃষ্ঠা ক্যাশে করবে
(এবং এতে একটি <html manifest="..."> অ্যাট্রিবিউট অন্তর্ভুক্ত থাকে)।