আমরা যেহেতু জাভাস্ক্রিপ্টের উপর অনেক বেশি নির্ভরশীল সাইট তৈরি করি, তাই কখনও কখনও আমরা যা পাঠাই তার জন্য এমনভাবে অর্থ প্রদান করি যা আমরা সবসময় সহজে দেখতে পাই না। এই নিবন্ধে, আমরা আলোচনা করব যে মোবাইল ডিভাইসে আপনার সাইট দ্রুত লোড এবং ইন্টারেক্টিভ করতে চাইলে, কেন একটু শৃঙ্খলা সাহায্য করতে পারে। কম জাভাস্ক্রিপ্ট ডেলিভার করার অর্থ হল নেটওয়ার্ক ট্রান্সমিশনে কম সময়, কোড ডিকম্প্রেস করতে কম সময় এবং এই জাভাস্ক্রিপ্ট পার্স ও কম্পাইল করতে কম সময় ব্যয় করা।
নেটওয়ার্ক
বেশিরভাগ ডেভেলপার যখন জাভাস্ক্রিপ্টের খরচ সম্পর্কে চিন্তা করেন, তখন তারা এটি ডাউনলোড এবং এক্সিকিউশন খরচ-এর হিসাবে চিন্তা করেন। ব্যবহারকারীর কানেকশন যত স্লো হবে, তারের মাধ্যমে আরও বেশি বাইটের জাভাস্ক্রিপ্ট পাঠাতে তত বেশি সময় লাগবে।
এটি সমস্যা হতে পারে, কারণ ব্যবহারকারীর কার্যকর নেটওয়ার্ক কানেকশনের ধরন আসলে 3G, 4G বা ওয়াই-ফাই নাও হতে পারে। আপনি কফি-শপের ওয়াই-ফাই ব্যবহার করতে পারেন, তবে 2G স্পিড সহ মোবাইল হটস্পটের সাথে কানেক্ট করা থাকতে হবে।
আপনি জাভাস্ক্রিপ্টের নেটওয়ার্ক ট্রান্সফার খরচ কমাতে পারবেন:
- ব্যবহারকারীর প্রয়োজন অনুযায়ী কোড পাঠানো।
- আপনার জাভাস্ক্রিপ্টকে গুরুত্বপূর্ণ ও অগুরুত্বপূর্ণ অংশে ভাগ করতে কোড-স্প্লিটিং ব্যবহার করুন। webpack-এর মতো মডিউল বান্ডলার কোড-স্প্লিটিং ফিচারকে সাপোর্ট করে।
- গুরুত্বপূর্ণ নয় এমন কোড ধীরে ধীরে লোড করা।
- ছোট করা
- ES5 কোড ছোট করতে UglifyJS ব্যবহার করুন।
- ES2015+ মিনিফাই করতে babel-minify বা uglify-es ব্যবহার করুন।
- কম্প্রেশন
- অব্যবহৃত কোড সরিয়ে দেওয়া।
- DevTools কোড কভারেজ-এর মাধ্যমে কোডের জন্য সুযোগ শনাক্ত করুন যা সরানো বা ধীরে ধীরে লোড করা যেতে পারে।
- আধুনিক ব্রাউজারে আগে থেকেই আছে এমন ফিচার ট্রান্সপাইল করা এড়াতে babel-preset-env এবং browserlist ব্যবহার করুন। উন্নত ডেভেলপাররা দেখতে পাবেন যে তাদের ওয়েবপ্যাক বান্ডেল সতর্কতার সাথে বিশ্লেষণ করলে অপ্রয়োজনীয় ডিপেন্ডেন্সি বাদ দেওয়ার সুযোগ শনাক্ত করতে সাহায্য করে।
- কোড স্ট্রিপ করার জন্য, ট্রি-শেকিং, ক্লোজার কম্পাইলার-এর উন্নত অপ্টিমাইজেশন এবং লাইব্রেরি ট্রিম করার প্লাগ-ইন যেমন lodash-babel-plugin অথবা Moment.js-এর মতো লাইব্রেরির জন্য webpack-এর ContextReplacementPlugin দেখুন।
- নেটওয়ার্ক ট্রিপ কমাতে কোড ক্যাশে করা।
- ব্রাউজার যাতে কার্যকরভাবে রেসপন্স ক্যাশে করতে পারে তা নিশ্চিত করতে HTTP ক্যাশিং ব্যবহার করুন। স্ক্রিপ্টের জন্য (সর্বাধিক-বয়স) সর্বোত্তম লাইফটাইম নির্ধারণ করুন এবং অপরিবর্তিত বাইট ট্রান্সফার করা এড়াতে যাচাইকরণ টোকেন (ETag) প্রদান করুন।
- সার্ভিস ওয়ার্কার ক্যাশিং আপনার অ্যাপ নেটওয়ার্ককে আরও স্থিতিস্থাপক করে তুলতে পারে এবং আপনাকে V8-এর কোড ক্যাশে-এর মতো ফিচারে দ্রুত অ্যাক্সেস দিতে পারে।
- পরিবর্তন হয়নি এমন রিসোর্স আবার ফেচ করা এড়াতে দীর্ঘমেয়াদী ক্যাশিং ব্যবহার করুন। Webpack ব্যবহার করলে, ফাইলের নাম হ্যাশিং দেখুন।
পার্স/কম্পাইল করুন
ডাউনলোড করার পরে, জাভাস্ক্রিপ্টের সবচেয়ে বেশি খরচ হয় JS ইঞ্জিনের এই কোড পার্স/কম্পাইল করার জন্য। Chrome DevTools-এ, পার্স ও কম্পাইল করা হল পারফর্ম্যান্স প্যানেলে হলুদ রঙের "স্ক্রিপ্টিং" সময়ের অংশ।
'বটম-আপ' ও 'কল ট্রি' ট্যাবে আপনি পার্স/কম্পাইল করার সঠিক সময় দেখতে পাবেন:
কিন্তু, এটি কেন গুরুত্বপূর্ণ?
কোড পার্স/কম্পাইল করতে অনেক সময় লাগলে, ব্যবহারকারী কত দ্রুত আপনার সাইটের সাথে ইন্টার্যাক্ট করতে পারবেন তাতে অনেক দেরি হতে পারে। আপনি যত বেশি জাভাস্ক্রিপ্ট পাঠাবেন, আপনার সাইট ইন্টার্যাক্টিভ হওয়ার আগে সেটি পার্স ও কম্পাইল করতে তত বেশি সময় লাগবে।
বাইট-ফর-বাইট, সম-আকারের ছবি বা ওয়েব ফন্টের তুলনায় ব্রাউজারের পক্ষে জাভাস্ক্রিপ্ট প্রসেস করা অনেক বেশি ব্যয়বহুল — টম ডেল
JavaScript-এর তুলনায়, একই সাইজের ছবি প্রসেস করার ক্ষেত্রে অনেক খরচ হয় (সেগুলি এখনও ডিকোড করতে হয়!) কিন্তু গড় মোবাইল হার্ডওয়্যারে, JS-এর কারণে কোনও পৃষ্ঠার ইন্টার্যাক্টিভিটির উপর নেতিবাচক প্রভাব পড়ার সম্ভাবনা বেশি থাকে।
পার্স ও কম্পাইল করার প্রসেস ধীরগতির হওয়ার ব্যাপারে কথা বলার সময়; প্রসঙ্গটি গুরুত্বপূর্ণ — আমরা এখানে গড় মোবাইল ফোনের ব্যাপারে কথা বলছি। সাধারণ ব্যবহারকারীদের কাছে এমন ফোন থাকতে পারে যেগুলির CPU এবং GPU ধীরগতির, L2/L3 ক্যাশে নেই এবং এমনকি মেমরিও সীমিত হতে পারে।
নেটওয়ার্কের ক্ষমতা ও ডিভাইসের ক্ষমতা সবসময় মেলে না। একজন ব্যবহারকারীর দুর্দান্ত ফাইবার কানেকশন থাকলেও, তার ডিভাইসে পাঠানো জাভাস্ক্রিপ্ট পার্স ও মূল্যায়ন করার জন্য সেরা সিপিইউ নাও থাকতে পারে। এর উল্টোটাও হতে পারে… নেটওয়ার্ক কানেকশন খুব খারাপ, কিন্তু CPU-এর স্পিড খুব বেশি। — ক্রিস্টোফার ব্যাক্সটার, LinkedIn
কম ও বেশি ক্ষমতার হার্ডওয়্যারে ~১ এমবি ডিকম্প্রেস করা (সহজ) জাভাস্ক্রিপ্ট পার্স করার খরচ নিচে দেখানো হল। বাজারে সবচেয়ে দ্রুত কাজ করে এমন ফোন এবং গড় ফোনের মধ্যে কোড পার্স/কম্পাইল করার সময়ের মধ্যে ২–৫ গুণ পার্থক্য থাকে।
CNN.com-এর মতো বাস্তব-জগতের সাইটের ক্ষেত্রে কী হবে?
হাই-এন্ড iPhone 8-এ CNN-এর JS পার্স/কম্পাইল করতে মাত্র ~৪ সেকেন্ড সময় লাগে, যেখানে সাধারণ ফোনে (Moto G4) ~১৩ সেকেন্ড সময় লাগে। এটি কোনও ব্যবহারকারী কত দ্রুত এই সাইটের সাথে সম্পূর্ণভাবে ইন্টার্যাক্ট করতে পারবেন তার উপর উল্লেখযোগ্য প্রভাব ফেলতে পারে।
এটি আপনার পকেটে থাকা ফোনের পরিবর্তে গড় হার্ডওয়্যারে (যেমন Moto G4) পরীক্ষা করার গুরুত্বকে হাইলাইট করে। প্রসঙ্গ গুরুত্বপূর্ণ তবে: আপনার ব্যবহারকারীদের ডিভাইস এবং নেটওয়ার্কের অবস্থা অনুযায়ী অপ্টিমাইজ করুন।
আমরা কি সত্যিই খুব বেশি জাভাস্ক্রিপ্ট পাঠাচ্ছি? হুম, হতে পারে :)
মোবাইলে জাভাস্ক্রিপ্ট-এর অবস্থা বিশ্লেষণ করতে HTTP আর্কাইভ (সেরা ~৫০০K সাইট) ব্যবহার করে আমরা দেখতে পাই যে ৫০% সাইট ইন্টার্যাক্টিভ হতে ১৪ সেকেন্ডের বেশি সময় নেয়। এইসব সাইট JS পার্স ও কম্পাইল করতে ৪ সেকেন্ড পর্যন্ত সময় নেয়।
JS ও অন্যান্য রিসোর্স ফেচ ও প্রসেস করতে যে সময় লাগে তা বিবেচনা করলে, ব্যবহারকারীদের পৃষ্ঠা ব্যবহার করার জন্য প্রস্তুত হওয়ার আগে কিছুক্ষণ অপেক্ষা করতে হতে পারে, যা অস্বাভাবিক নয়। আমরা অবশ্যই এখানে আরও ভালো করতে পারি।
আপনার পৃষ্ঠা থেকে অপ্রয়োজনীয় জাভাস্ক্রিপ্ট সরিয়ে দিলে ট্রান্সমিশন টাইম, CPU-ইনটেনসিভ পার্সিং ও কম্পাইলিং এবং সম্ভাব্য মেমরি ওভারহেড কমে যেতে পারে। এছাড়াও, এটি আপনার পৃষ্ঠাগুলিকে আরও দ্রুত ইন্টার্যাক্টিভ করে তুলতে সাহায্য করে।
এক্সিকিউশনের সময়
শুধু পার্স ও কম্পাইল করার জন্যই খরচ হয় না। জাভাস্ক্রিপ্ট এক্সিকিউশন (পার্স/কম্পাইল করার পরে কোড রান করা) হল এমন একটি অপারেশন যা মূল থ্রেডে করতে হয়। এছাড়াও, এক্সিকিউশন টাইম বেশি হলে, ব্যবহারকারী কত তাড়াতাড়ি আপনার সাইটের সাথে ইন্টার্যাক্ট করতে পারবেন তা প্রভাবিত হতে পারে।
স্ক্রিপ্ট যদি ৫০ মিলিসেকেন্ডের বেশি সময় ধরে চলে, তাহলে JS ডাউনলোড, কম্পাইল ও এক্সিকিউট করতে যতটা সময় লাগে, টাইম-টু-ইন্টার্যাক্টিভ ততটাই দেরি হয় — অ্যালেক্স রাসেল
এই সমস্যা সমাধান করতে, জাভাস্ক্রিপ্ট ছোট চাঙ্কে থাকলে সুবিধা হয়, যাতে মূল থ্রেড লক হয়ে না যায়। এক্সিকিউশনের সময় কতটা কাজ করা হচ্ছে তা আপনি কমাতে পারবেন কিনা তা এক্সপ্লোর করুন।
অন্যান্য খরচ
জাভাস্ক্রিপ্ট অন্যান্য উপায়ে পৃষ্ঠার পারফর্ম্যান্সের উপর প্রভাব ফেলতে পারে:
- মেমরি। GC (গার্বেজ কালেকশন)-এর কারণে পৃষ্ঠাগুলি প্রায়ই জ্যাঙ্ক বা পজ হয়ে যেতে পারে। ব্রাউজার মেমরি রিক্লেম করার সময় JS এক্সিকিউশন পজ করা হয়, তাই ব্রাউজার ঘন ঘন গার্বেজ সংগ্রহ করলে এক্সিকিউশন আমাদের পছন্দের চেয়ে বেশি ঘন ঘন পজ হতে পারে। মেমরি লিক এবং ঘন ঘন gc পজ এড়িয়ে চলুন যাতে পৃষ্ঠা জ্যাঙ্ক ফ্রি থাকে।
- রানটাইমের সময়, দীর্ঘ সময় ধরে চলা জাভাস্ক্রিপ্ট মূল-থ্রেডকে ব্লক করতে পারে যার ফলে
পৃষ্ঠাগুলি কাজ করে না। কাজকে ছোট ছোট অংশে ভাগ করে নিলে (শিডিউল করার জন্য
requestAnimationFrame()বাrequestIdleCallback()ব্যবহার করে) রেসপন্সিভনেস সংক্রান্ত সমস্যা কমানো যেতে পারে, যা Interaction to Next Paint (INP) উন্নত করতে সাহায্য করতে পারে।
জাভাস্ক্রিপ্ট ডেলিভারি খরচ কমানোর প্যাটার্ন
আপনি যখন জাভাস্ক্রিপ্টের জন্য পার্স/কম্পাইল এবং নেটওয়ার্ক ট্রান্সমিট টাইম কম রাখার চেষ্টা করছেন, তখন রুট-ভিত্তিক চাঙ্কিং বা PRPL-এর মতো প্যাটার্নগুলি সাহায্য করতে পারে।
PRPL
PRPL (পুশ, রেন্ডার, প্রি-ক্যাশে, লেজি-লোড) হল এমন একটি প্যাটার্ন যা অ্যাগ্রেসিভ কোড-স্প্লিটিং এবং ক্যাশিংয়ের মাধ্যমে ইন্টারঅ্যাক্টিভিটির জন্য অপ্টিমাইজ করে:
এর ফলে কী প্রভাব পড়তে পারে তা কল্পনা করা যাক।
V8-এর রানটাইম কল স্ট্যাটস ব্যবহার করে আমরা জনপ্রিয় মোবাইল সাইট ও প্রোগ্রেসিভ ওয়েব অ্যাপের লোড-টাইম বিশ্লেষণ করি। আমরা দেখতে পাচ্ছি যে, পার্স করার সময় (কমলা রঙে দেখানো হয়েছে) এইসব সাইটের বেশিরভাগ সময় ব্যয় করার একটি উল্লেখযোগ্য অংশ:
Wego, PRPL ব্যবহার করে এমন একটি সাইট, তাদের রুটের জন্য কম পার্স টাইম বজায় রাখতে পারে, খুব দ্রুত ইন্ট্যার্যাক্টিভ হয়ে ওঠে। উপরে উল্লেখ করা অন্যান্য সাইটের মধ্যে অনেকগুলিই JS-এর খরচ কমানোর জন্য কোড-স্প্লিটিং ও পারফর্ম্যান্স বাজেট ব্যবহার করেছে।
প্রোগ্রেসিভ বুটস্ট্র্যাপিং
অনেক সাইট ইন্টার্যাক্টিভিটির খরচেই কন্টেন্টের দৃশ্যমানতা অপ্টিমাইজ করে। আপনার কাছে বড় জাভাস্ক্রিপ্ট বান্ডেল থাকলে, দ্রুত ফার্স্ট পেইন্ট পেতে, ডেভেলপাররা কখনও কখনও সার্ভার-সাইড রেন্ডারিং ব্যবহার করেন; তারপর জাভাস্ক্রিপ্ট শেষ পর্যন্ত ফেচ করা হলে, ইভেন্ট হ্যান্ডলার অ্যাটাচ করার জন্য এটি "আপগ্রেড" করেন।
সাবধান — এর জন্য খরচ করতে হবে। আপনি ১) সাধারণত আরও বড় HTML রেসপন্স পাঠান যা আমাদের ইন্টার্যাক্টিভিটি পুশ করতে পারে, ২) ব্যবহারকারীকে এমন এক অদ্ভুত পরিস্থিতিতে ফেলে দিতে পারেন যেখানে JavaScript প্রসেসিং শেষ না হওয়া পর্যন্ত অর্ধেক অভিজ্ঞতা আসলে ইন্টার্যাক্টিভ হতে পারে না।
প্রোগ্রেসিভ বুটস্ট্র্যাপিং আরও ভালো পদ্ধতি হতে পারে। একটি ন্যূনতম কার্যকরী পৃষ্ঠা পাঠান (বর্তমান রুটের জন্য প্রয়োজনীয় HTML/JS/CSS দিয়ে গঠিত)। আরও রিসোর্স উপলভ্য হলে, অ্যাপটি ধীরে ধীরে লোড হতে পারে এবং আরও ফিচার আনলক করতে পারে।
ভিউতে যা আছে তার অনুপাতে কোড লোড করা হল সবচেয়ে গুরুত্বপূর্ণ বিষয়। PRPL এবং প্রোগ্রেসিভ বুটস্ট্র্যাপিং হল এমন প্যাটার্ন যা এটি করতে সাহায্য করতে পারে।
উপসংহার
লো-এন্ড নেটওয়ার্কের জন্য ট্রান্সমিশন সাইজ খুবই গুরুত্বপূর্ণ। CPU বাউন্ড ডিভাইসের জন্য পার্স টাইম গুরুত্বপূর্ণ। এগুলি কম রাখা গুরুত্বপূর্ণ।
JavaScript ট্রান্সমিশন এবং পার্স/কম্পাইল করার সময় কম রাখার জন্য কঠোর পারফর্ম্যান্স বাজেট গ্রহণ করে টিমগুলি সাফল্য পেয়েছে। অ্যালেক্স রাসেলের "Can You Afford It?: Real-world Web Performance Budgets" লিঙ্ক থেকে মোবাইল ডিভাইসের জন্য বাজেট সংক্রান্ত নির্দেশিকা দেখুন।
আপনি যদি মোবাইল ডিভাইসের জন্য কোনও সাইট তৈরি করেন, তাহলে রিপ্রেজেন্টেটিভ হার্ডওয়্যারে ডেভেলপ করার জন্য যথাসাধ্য চেষ্টা করুন, আপনার জাভাস্ক্রিপ্ট পার্স/কম্পাইল করার সময় কম রাখুন এবং আপনার টিম যাতে তাদের জাভাস্ক্রিপ্ট খরচের উপর নজর রাখতে পারে তা নিশ্চিত করার জন্য একটি পারফর্ম্যান্স বাজেট গ্রহণ করুন।
আরও জানুন
- Chrome Dev Summit 2017 - Modern Loading Best Practices
- জাভাস্ক্রিপ্ট স্টার্ট-আপ পারফর্ম্যান্স
- ওয়েব পারফর্ম্যান্সের সমস্যা সমাধান করা — নোলান লসন
- আপনি কি এটি কিনতে পারবেন? বাস্তব জগতে পারফর্ম্যান্স বাজেট — অ্যালেক্স রাসেল
- ওয়েব ফ্রেমওয়ার্ক ও লাইব্রেরি মূল্যায়ন করা — ক্রিস্টোফার ব্যাক্সটার
- Cloudflare-এর Brotli-র সাথে পরীক্ষা করার ফলাফল কম্প্রেশনের জন্য (মনে রাখবেন, উচ্চ কোয়ালিটিতে ডায়নামিক Brotli প্রাথমিক পৃষ্ঠা রেন্ডার করতে দেরি করতে পারে, তাই সাবধানে মূল্যায়ন করুন। আপনি সম্ভবত স্ট্যাটিক্যালি কম্প্রেস করতে চান।)
- পারফর্ম্যান্স ফিউচার — স্যাম স্যাকোন