যেহেতু আমরা জাভাস্ক্রিপ্টের উপর অনেক বেশি নির্ভরশীল সাইট তৈরি করি, আমরা কখনও কখনও আমরা যা পাঠাই তার জন্য আমরা এমনভাবে অর্থ প্রদান করি যা আমরা সবসময় সহজে দেখতে পাই না। এই নিবন্ধে, আমরা কভার করব কেন একটু শৃঙ্খলা সাহায্য করতে পারে যদি আপনি চান যে আপনার সাইটটি মোবাইল ডিভাইসে দ্রুত লোড হোক এবং ইন্টারেক্টিভ হোক। কম জাভাস্ক্রিপ্ট প্রদানের অর্থ হল নেটওয়ার্ক ট্রান্সমিশনে কম সময়, কম খরচ করা কোড ডিকম্প্রেস করা এবং এই জাভাস্ক্রিপ্ট পার্সিং এবং কম্পাইল করা কম সময়।
অন্তর্জাল
যখন বেশিরভাগ ডেভেলপার জাভাস্ক্রিপ্টের খরচ সম্পর্কে চিন্তা করে, তখন তারা এটি ডাউনলোড এবং এক্সিকিউশন খরচের পরিপ্রেক্ষিতে চিন্তা করে। তারের উপর জাভাস্ক্রিপ্টের আরও বাইট পাঠাতে ব্যবহারকারীর সংযোগ যত ধীর হয় তত বেশি সময় নেয়।
এটি একটি সমস্যা হতে পারে, কারণ একজন ব্যবহারকারীর কার্যকরী নেটওয়ার্ক সংযোগের ধরন আসলে 3G, 4G বা Wi-Fi নাও হতে পারে৷ আপনি কফি-শপ ওয়াই-ফাইতে থাকতে পারেন তবে 2G গতির সাথে একটি সেলুলার হটস্পটের সাথে সংযুক্ত থাকতে পারেন৷
আপনি এর মাধ্যমে জাভাস্ক্রিপ্টের নেটওয়ার্ক ট্রান্সফার খরচ কমাতে পারেন:
- শুধুমাত্র একটি ব্যবহারকারীর প্রয়োজন কোড পাঠানো .
- আপনার জাভাস্ক্রিপ্টকে কোনটি গুরুত্বপূর্ণ এবং কোনটি নয় তা বিভক্ত করতে কোড-বিভাজন ব্যবহার করুন। মডিউল বান্ডলার যেমন ওয়েবপ্যাক সমর্থন কোড-বিভাজন ।
- অলসভাবে কোডে লোড হচ্ছে যা অ-গুরুত্বপূর্ণ।
- মিনিফিকেশন
- ES5 কোড ছোট করার জন্য UglifyJS ব্যবহার করুন।
- ES2015+ ছোট করতে babel-minify বা uglify-es ব্যবহার করুন।
- সঙ্কোচন
- অব্যবহৃত কোড সরানো হচ্ছে ।
- DevTools কোড কভারেজ দিয়ে সরানো বা অলসভাবে লোড করা যেতে পারে এমন কোডের সুযোগগুলি চিহ্নিত করুন৷
- আধুনিক ব্রাউজারে ইতিমধ্যে ট্রান্সপিলিং বৈশিষ্ট্যগুলি এড়াতে babel-preset-env এবং ব্রাউজারলিস্ট ব্যবহার করুন। উন্নত বিকাশকারীরা তাদের ওয়েবপ্যাক বান্ডিলগুলির যত্ন সহকারে বিশ্লেষণ খুঁজে পেতে পারে অপ্রয়োজনীয় নির্ভরতা ট্রিম করার সুযোগগুলি সনাক্ত করতে সহায়তা করে।
- স্ট্রিপিং কোডের জন্য, ট্রি-শেকিং , ক্লোজার কম্পাইলারের উন্নত অপ্টিমাইজেশান এবং লাইব্রেরি ট্রিমিং প্লাগইন যেমন lodash-babel-plugin অথবা Moment.js-এর মতো লাইব্রেরির জন্য ওয়েবপ্যাকের ContextReplacementPlugin দেখুন।
- নেটওয়ার্ক ট্রিপ কমাতে ক্যাশিং কোড।
- কার্যকরভাবে ব্রাউজার ক্যাশে প্রতিক্রিয়া নিশ্চিত করতে HTTP ক্যাশিং ব্যবহার করুন। অপরিবর্তিত বাইট স্থানান্তর এড়াতে স্ক্রিপ্ট (সর্বোচ্চ বয়স) এবং সরবরাহের বৈধতা টোকেন (ETag) এর জন্য সর্বোত্তম জীবনকাল নির্ধারণ করুন।
- সার্ভিস ওয়ার্কার ক্যাশিং আপনার অ্যাপ নেটওয়ার্ককে স্থিতিস্থাপক করে তুলতে পারে এবং আপনাকে V8 এর কোড ক্যাশের মতো বৈশিষ্ট্যগুলিতে আগ্রহী অ্যাক্সেস দিতে পারে৷
- পরিবর্তিত না হওয়া সংস্থানগুলিকে পুনঃআনয়ন করা এড়াতে দীর্ঘমেয়াদী ক্যাশিং ব্যবহার করুন৷ ওয়েবপ্যাক ব্যবহার করলে, ফাইলের নাম হ্যাশিং দেখুন।
পার্স/কম্পাইল
একবার ডাউনলোড হয়ে গেলে, জাভাস্ক্রিপ্টের সবচেয়ে ভারী খরচ হল একটি JS ইঞ্জিনের এই কোড পার্স/কম্পাইল করার সময়। Chrome DevTools- এ, পার্স এবং কম্পাইল হল পারফরম্যান্স প্যানেলে হলুদ "স্ক্রিপ্টিং" সময়ের অংশ৷
বটম-আপ এবং কল ট্রি ট্যাবগুলি আপনাকে সঠিক পার্স/কম্পাইলের সময় দেখায়:
কিন্তু, কেন এই ব্যাপার?
কোড পার্সিং/সংকলন করার জন্য দীর্ঘ সময় ব্যয় করলে একজন ব্যবহারকারী কত তাড়াতাড়ি আপনার সাইটের সাথে ইন্টারঅ্যাক্ট করতে পারে তা অনেক বেশি বিলম্ব করতে পারে। আপনি যত বেশি জাভাস্ক্রিপ্ট পাঠাবেন, আপনার সাইট ইন্টারেক্টিভ হওয়ার আগে এটি পার্স এবং কম্পাইল করতে তত বেশি সময় লাগবে।
বাইট-ফর-বাইট, জাভাস্ক্রিপ্ট ব্রাউজারের জন্য সমান আকারের চিত্র বা ওয়েব ফন্টের চেয়ে প্রক্রিয়াকরণের জন্য বেশি ব্যয়বহুল — টম ডেল
জাভাস্ক্রিপ্টের তুলনায়, সমতুল্য আকারের ছবি প্রক্রিয়াকরণে অনেক খরচ জড়িত (এগুলি এখনও ডিকোড করতে হবে!) কিন্তু গড় মোবাইল হার্ডওয়্যারে, JS একটি পৃষ্ঠার ইন্টারঅ্যাক্টিভিটিকে নেতিবাচকভাবে প্রভাবিত করার সম্ভাবনা বেশি।
যখন আমরা পার্স এবং কম্পাইল ধীর হওয়ার কথা বলি; প্রসঙ্গ গুরুত্বপূর্ণ — আমরা এখানে গড় মোবাইল ফোনের কথা বলছি। গড় ব্যবহারকারীদের কাছে ধীরগতির সিপিইউ এবং জিপিইউ সহ ফোন থাকতে পারে, কোনও L2/L3 ক্যাশে নেই এবং যা মেমরি সীমাবদ্ধও হতে পারে।
নেটওয়ার্ক ক্ষমতা এবং ডিভাইস ক্ষমতা সবসময় মেলে না। একটি আশ্চর্যজনক ফাইবার সংযোগ সহ একজন ব্যবহারকারীর কাছে তাদের ডিভাইসে পাঠানো জাভাস্ক্রিপ্ট পার্স এবং মূল্যায়ন করার জন্য সর্বোত্তম CPU থাকা আবশ্যক নয়। এটি বিপরীতেও সত্য... একটি ভয়ানক নেটওয়ার্ক সংযোগ, কিন্তু একটি জ্বলন্ত দ্রুত CPU। — ক্রিস্টোফার ব্যাক্সটার, লিঙ্কডইন
নীচে আমরা নিম্ন এবং উচ্চ-সম্পন্ন হার্ডওয়্যারে ~1MB ডিকম্প্রেসড (সরল) জাভাস্ক্রিপ্ট পার্স করার খরচ দেখতে পাচ্ছি। বাজারের দ্রুততম ফোন এবং গড় ফোনের মধ্যে কোড পার্স/কম্পাইল করার সময়ের মধ্যে 2-5x পার্থক্য রয়েছে ।
CNN.com এর মতো একটি বাস্তব-বিশ্বের সাইট সম্পর্কে কী?
হাই-এন্ড আইফোন 8-এ সিএনএন-এর জেএসকে পার্স/কম্পাইল করতে মাত্র ~4সেকেন্ড লাগে একটি গড় ফোনের (মোটো জি4) জন্য ~13s এর তুলনায়। এটি উল্লেখযোগ্যভাবে প্রভাবিত করতে পারে যে কত দ্রুত একজন ব্যবহারকারী এই সাইটের সাথে সম্পূর্ণভাবে ইন্টারঅ্যাক্ট করতে পারে।
এটি আপনার পকেটে থাকা ফোনের পরিবর্তে গড় হার্ডওয়্যার (যেমন Moto G4) পরীক্ষা করার গুরুত্ব তুলে ধরে। তবে প্রসঙ্গ গুরুত্বপূর্ণ: আপনার ব্যবহারকারীদের ডিভাইস এবং নেটওয়ার্ক অবস্থার জন্য অপ্টিমাইজ করুন।
আমরা কি সত্যিই খুব বেশি জাভাস্ক্রিপ্ট পাঠাচ্ছি? ভুল, সম্ভবত :)
মোবাইলে জাভাস্ক্রিপ্টের অবস্থা বিশ্লেষণ করতে HTTP আর্কাইভ (শীর্ষ ~500K সাইট) ব্যবহার করে, আমরা দেখতে পাচ্ছি যে 50% সাইট ইন্টারেক্টিভ হতে 14 সেকেন্ডের বেশি সময় নেয়। এই সাইটগুলি JS পার্সিং এবং কম্পাইল করতে 4 সেকেন্ড পর্যন্ত সময় ব্যয় করে।
JS এবং অন্যান্য সংস্থানগুলি আনতে এবং প্রক্রিয়া করতে যে সময় লাগে তার ফ্যাক্টর এবং এটি সম্ভবত আশ্চর্যজনক নয় যে পৃষ্ঠাগুলি ব্যবহারের জন্য প্রস্তুত অনুভব করার আগে ব্যবহারকারীদের কিছুক্ষণ অপেক্ষা করা যেতে পারে। আমরা অবশ্যই এখানে আরও ভাল করতে পারি।
আপনার পৃষ্ঠাগুলি থেকে অ-সমালোচনামূলক জাভাস্ক্রিপ্ট সরানো ট্রান্সমিশন সময়, CPU- নিবিড় পার্সিং এবং কম্পাইলিং এবং সম্ভাব্য মেমরি ওভারহেড কমাতে পারে। এটি আপনার পৃষ্ঠাগুলিকে দ্রুত ইন্টারেক্টিভ করতে সহায়তা করে৷
সঞ্চালনের সময়
এটি শুধুমাত্র পার্স এবং কম্পাইল নয় যে একটি খরচ থাকতে পারে. জাভাস্ক্রিপ্ট এক্সিকিউশন (কোড পার্স/কম্পাইল হয়ে গেলে রানিং) হল একটি অপারেশন যা মূল থ্রেডে ঘটতে হয়। একটি ব্যবহারকারী কত তাড়াতাড়ি আপনার সাইটের সাথে ইন্টারঅ্যাক্ট করতে পারে তাও দীর্ঘ কার্যকর করার সময় ধাক্কা দিতে পারে।
যদি স্ক্রিপ্ট 50ms এর বেশি সময় ধরে চালানো হয়, তাহলে JS ডাউনলোড, কম্পাইল এবং এক্সিকিউট করতে যে পরিমাণ সময় লাগে তার থেকে টাইম-টু-ইন্টারেক্টিভ বিলম্বিত হয় — অ্যালেক্স রাসেল
এটি মোকাবেলা করার জন্য, জাভাস্ক্রিপ্ট প্রধান থ্রেড লক করা এড়াতে ছোট খণ্ডে থাকা থেকে উপকৃত হয়। নির্বাহের সময় কতটা কাজ করা হচ্ছে তা আপনি কমাতে পারেন কিনা তা অন্বেষণ করুন।
অন্যান্য খরচাপাতি
জাভাস্ক্রিপ্ট অন্যান্য উপায়ে পৃষ্ঠার কর্মক্ষমতা প্রভাবিত করতে পারে:
- স্মৃতি. GC (আবর্জনা সংগ্রহ) এর কারণে পৃষ্ঠাগুলি ঘন ঘন জ্যাঙ্ক বা পজ হতে পারে। যখন একটি ব্রাউজার মেমরি পুনরুদ্ধার করে, তখন JS এক্সিকিউশন পজ করা হয় যাতে একটি ব্রাউজার ঘন ঘন আবর্জনা সংগ্রহ করে আমাদের পছন্দের চেয়ে বেশি ঘন ঘন এক্সিকিউশনকে থামাতে পারে। পৃষ্ঠাগুলিকে জ্যাঙ্ক মুক্ত রাখতে মেমরি লিক এবং ঘন ঘন জিসি বিরতি এড়িয়ে চলুন।
- রানটাইম চলাকালীন, দীর্ঘ সময় ধরে চলমান জাভাস্ক্রিপ্ট প্রধান-থ্রেডের কারণে পৃষ্ঠাগুলিকে ব্লক করতে পারে যা প্রতিক্রিয়াহীন। কাজকে ছোট ছোট টুকরোতে বিভক্ত করা (অনুরোধের জন্য
requestAnimationFrame()বাrequestIdleCallback()ব্যবহার করে প্রতিক্রিয়াশীলতার সমস্যাগুলি হ্রাস করতে পারে যা নেক্সট পেইন্ট (আইএনপি) এর সাথে ইন্টারঅ্যাকশন উন্নত করতে সহায়তা করতে পারে।
জাভাস্ক্রিপ্ট ডেলিভারি খরচ কমানোর জন্য নিদর্শন
আপনি যখন জাভাস্ক্রিপ্টের জন্য পার্স/কম্পাইল এবং নেটওয়ার্ক ট্রান্সমিট সময় ধীর রাখার চেষ্টা করছেন, তখন এমন প্যাটার্ন রয়েছে যা রুট-ভিত্তিক চঙ্কিং বা PRPL- এর মতো সাহায্য করতে পারে।
পিআরপিএল
PRPL (Push, Render, Pre-cache, Lazy-load) হল একটি প্যাটার্ন যা আক্রমনাত্মক কোড-বিভাজন এবং ক্যাশিংয়ের মাধ্যমে ইন্টারঅ্যাক্টিভিটির জন্য অপ্টিমাইজ করে:
এর প্রভাব কি হতে পারে তা কল্পনা করা যাক।
আমরা V8 এর রানটাইম কল পরিসংখ্যান ব্যবহার করে জনপ্রিয় মোবাইল সাইট এবং প্রগ্রেসিভ ওয়েব অ্যাপের লোড-টাইম বিশ্লেষণ করি। আমরা দেখতে পাচ্ছি, পার্স টাইম (কমলা রঙে দেখানো হয়েছে) হল একটি উল্লেখযোগ্য অংশ যেখানে এই সাইটগুলির মধ্যে অনেকগুলি তাদের সময় ব্যয় করে:
Wego , একটি সাইট যা PRPL ব্যবহার করে, তাদের রুটের জন্য একটি কম পার্স টাইম বজায় রাখে, খুব দ্রুত ইন্টারেক্টিভ হয়। উপরের অন্যান্য সাইটগুলির মধ্যে অনেকগুলি তাদের JS খরচ কমানোর চেষ্টা করার জন্য কোড-বিভাজন এবং কর্মক্ষমতা বাজেট গ্রহণ করেছে।
প্রগতিশীল বুটস্ট্র্যাপিং
অনেক সাইট ইন্টারঅ্যাক্টিভিটির ব্যয়বহুল কন্টেন্ট দৃশ্যমানতা অপ্টিমাইজ করে। আপনার কাছে বড় জাভাস্ক্রিপ্ট বান্ডিল থাকলে দ্রুত প্রথম পেইন্ট পেতে, ডেভেলপাররা কখনও কখনও সার্ভার-সাইড রেন্ডারিং নিযুক্ত করে; তারপর জাভাস্ক্রিপ্ট অবশেষে আনা হলে ইভেন্ট হ্যান্ডলার সংযুক্ত করতে এটি "আপগ্রেড" করুন।
সতর্ক থাকুন - এর নিজস্ব খরচ আছে। আপনি 1) সাধারণত একটি বৃহত্তর HTML প্রতিক্রিয়া পাঠান যা আমাদের ইন্টারঅ্যাক্টিভিটিকে ধাক্কা দিতে পারে, 2) ব্যবহারকারীকে একটি অদ্ভুত উপত্যকায় ছেড়ে যেতে পারে যেখানে জাভাস্ক্রিপ্ট প্রক্রিয়াকরণ শেষ না হওয়া পর্যন্ত অর্ধেক অভিজ্ঞতা আসলে ইন্টারেক্টিভ হতে পারে না।
প্রগতিশীল বুটস্ট্র্যাপিং একটি ভাল পদ্ধতি হতে পারে। একটি ন্যূনতম কার্যকরী পৃষ্ঠা পাঠান (বর্তমান রুটের জন্য প্রয়োজনীয় HTML/JS/CSS দিয়ে গঠিত)। যত বেশি সংস্থান আসে, অ্যাপটি অলস-লোড করতে পারে এবং আরও বৈশিষ্ট্য আনলক করতে পারে।
লোডিং কোডটি হলি গ্রেইলের সাথে সমানুপাতিক। পিআরপিএল এবং প্রগ্রেসিভ বুটস্ট্র্যাপিং এমন নিদর্শন যা এটি সম্পন্ন করতে সাহায্য করতে পারে।
উপসংহার
লো-এন্ড নেটওয়ার্কের জন্য ট্রান্সমিশন সাইজ গুরুত্বপূর্ণ। CPU আবদ্ধ ডিভাইসের জন্য পার্স সময় গুরুত্বপূর্ণ। এসব বিষয় কম রাখা।
দলগুলি তাদের জাভাস্ক্রিপ্ট ট্রান্সমিশন এবং পার্স/কম্পাইলের সময় কম রাখার জন্য কঠোর কর্মক্ষমতা বাজেট গ্রহণ করে সফলতা পেয়েছে। মোবাইলের জন্য বাজেটের দিকনির্দেশনার জন্য অ্যালেক্স রাসেলের " আপনি কি এটি বহন করতে পারেন?: বাস্তব-বিশ্বের ওয়েব পারফরম্যান্স বাজেট " দেখুন।
আপনি যদি মোবাইল ডিভাইসগুলিকে লক্ষ্য করে এমন একটি সাইট তৈরি করেন, তাহলে প্রতিনিধি হার্ডওয়্যারে বিকাশ করার জন্য আপনার যথাসাধ্য চেষ্টা করুন, আপনার জাভাস্ক্রিপ্ট পার্স/কম্পাইলের সময় কম রাখুন এবং আপনার দল তাদের JavaScript খরচের উপর নজর রাখতে সক্ষম তা নিশ্চিত করার জন্য একটি পারফরম্যান্স বাজেট গ্রহণ করুন।
আরও জানুন
- ক্রোম ডেভ সামিট 2017 - আধুনিক লোডিং সেরা অভ্যাস
- জাভাস্ক্রিপ্ট স্টার্ট আপ কর্মক্ষমতা
- ওয়েব পারফরম্যান্স সংকট সমাধান করা — নোলান লসন
- এটা করার কি তোমার সামর্থ্য আছে? বাস্তব-বিশ্বের কর্মক্ষমতা বাজেট — অ্যালেক্স রাসেল
- ওয়েব ফ্রেমওয়ার্ক এবং লাইব্রেরি মূল্যায়ন — ক্রিস্টোফার ব্যাক্সটার
- ক্লাউডফ্লেয়ারের সংকোচনের জন্য ব্রোটলির সাথে পরীক্ষা করার ফলাফল (দ্রষ্টব্য ডায়নামিক ব্রটলি উচ্চ মানের প্রাথমিক পৃষ্ঠা রেন্ডারে বিলম্ব করতে পারে তাই সাবধানে মূল্যায়ন করুন। আপনি সম্ভবত পরিবর্তে স্ট্যাটিকভাবে সংকুচিত করতে চান।)
- পারফরম্যান্স ফিউচার - স্যাম স্যাকোন