জাভাস্ক্রিপ্ট স্টার্ট আপ অপ্টিমাইজেশান

আদ্দি ওসমানী
Addy Osmani

যেহেতু আমরা জাভাস্ক্রিপ্টের উপর অনেক বেশি নির্ভরশীল সাইট তৈরি করি, আমরা কখনও কখনও আমরা যা পাঠাই তার জন্য আমরা এমনভাবে অর্থ প্রদান করি যা আমরা সবসময় সহজে দেখতে পাই না। এই নিবন্ধে, আমরা কভার করব কেন একটু শৃঙ্খলা সাহায্য করতে পারে যদি আপনি চান যে আপনার সাইটটি মোবাইল ডিভাইসে দ্রুত লোড হোক এবং ইন্টারেক্টিভ হোক। কম জাভাস্ক্রিপ্ট প্রদানের অর্থ হল নেটওয়ার্ক ট্রান্সমিশনে কম সময়, কম খরচ করা কোড ডিকম্প্রেস করা এবং এই জাভাস্ক্রিপ্ট পার্সিং এবং কম্পাইল করা কম সময়।

যখন বেশিরভাগ ডেভেলপার জাভাস্ক্রিপ্টের খরচ সম্পর্কে চিন্তা করে, তখন তারা এটি ডাউনলোড এবং এক্সিকিউশন খরচের পরিপ্রেক্ষিতে চিন্তা করে। তারের উপর জাভাস্ক্রিপ্টের আরও বাইট পাঠাতে ব্যবহারকারীর সংযোগ যত ধীর হয় তত বেশি সময় নেয়।

যখন একটি ব্রাউজার একটি সম্পদের জন্য অনুরোধ করে, তখন সেই সংস্থানটি আনতে হবে এবং তারপর ডিকম্প্রেস করতে হবে। জাভাস্ক্রিপ্টের মতো সংস্থানগুলির ক্ষেত্রে, সেগুলি সম্পাদনের আগে অবশ্যই পার্স এবং কম্পাইল করা উচিত।

এটি একটি সমস্যা হতে পারে, কারণ একজন ব্যবহারকারীর কার্যকরী নেটওয়ার্ক সংযোগের ধরন আসলে 3G, 4G বা Wi-Fi নাও হতে পারে৷ আপনি কফি-শপ ওয়াই-ফাইতে থাকতে পারেন তবে 2G গতির সাথে একটি সেলুলার হটস্পটের সাথে সংযুক্ত থাকতে পারেন৷

আপনি এর মাধ্যমে জাভাস্ক্রিপ্টের নেটওয়ার্ক ট্রান্সফার খরচ কমাতে পারেন:

  • শুধুমাত্র একটি ব্যবহারকারীর প্রয়োজন কোড পাঠানো .
    • আপনার জাভাস্ক্রিপ্টকে কোনটি গুরুত্বপূর্ণ এবং কোনটি নয় তা বিভক্ত করতে কোড-বিভাজন ব্যবহার করুন। মডিউল বান্ডলার যেমন ওয়েবপ্যাক সমর্থন কোড-বিভাজন
    • অলসভাবে কোডে লোড হচ্ছে যা অ-গুরুত্বপূর্ণ।
  • মিনিফিকেশন
  • সঙ্কোচন
    • ন্যূনতম, পাঠ্য-ভিত্তিক সংস্থানগুলি সংকুচিত করতে gzip ব্যবহার করুন।
    • Brotli ~ q11 ব্যবহার করার কথা বিবেচনা করুন। ব্রটলি কম্প্রেশন রেশিওতে জিজিপকে ছাড়িয়ে যায়। এটি CertSimple কে কম্প্রেসড JS বাইটের আকারে 17% এবং LinkedIn কে তাদের লোডের সময় 4% বাঁচাতে সাহায্য করেছে।
  • অব্যবহৃত কোড সরানো হচ্ছে
  • নেটওয়ার্ক ট্রিপ কমাতে ক্যাশিং কোড।
    • কার্যকরভাবে ব্রাউজার ক্যাশে প্রতিক্রিয়া নিশ্চিত করতে HTTP ক্যাশিং ব্যবহার করুন। অপরিবর্তিত বাইট স্থানান্তর এড়াতে স্ক্রিপ্ট (সর্বোচ্চ বয়স) এবং সরবরাহের বৈধতা টোকেন (ETag) এর জন্য সর্বোত্তম জীবনকাল নির্ধারণ করুন।
    • সার্ভিস ওয়ার্কার ক্যাশিং আপনার অ্যাপ নেটওয়ার্ককে স্থিতিস্থাপক করে তুলতে পারে এবং আপনাকে V8 এর কোড ক্যাশের মতো বৈশিষ্ট্যগুলিতে আগ্রহী অ্যাক্সেস দিতে পারে৷
    • পরিবর্তিত না হওয়া সংস্থানগুলিকে পুনঃআনয়ন করা এড়াতে দীর্ঘমেয়াদী ক্যাশিং ব্যবহার করুন৷ ওয়েবপ্যাক ব্যবহার করলে, ফাইলের নাম হ্যাশিং দেখুন।

পার্স/কম্পাইল

একবার ডাউনলোড হয়ে গেলে, জাভাস্ক্রিপ্টের সবচেয়ে ভারী খরচ হল একটি JS ইঞ্জিনের এই কোড পার্স/কম্পাইল করার সময়। Chrome DevTools- এ, পার্স এবং কম্পাইল হল পারফরম্যান্স প্যানেলে হলুদ "স্ক্রিপ্টিং" সময়ের অংশ৷

ALT_TEXT_HERE

বটম-আপ এবং কল ট্রি ট্যাবগুলি আপনাকে সঠিক পার্স/কম্পাইলের সময় দেখায়:

ALT_TEXT_HERE
Chrome DevTools পারফরম্যান্স প্যানেল > বটম-আপ। V8 এর রানটাইম কল পরিসংখ্যান সক্ষম করে, আমরা পার্স এবং কম্পাইলের মতো পর্যায়ক্রমে ব্যয় করা সময় দেখতে পারি

কিন্তু, কেন এই ব্যাপার?

ALT_TEXT_HERE

কোড পার্সিং/সংকলন করার জন্য দীর্ঘ সময় ব্যয় করলে একজন ব্যবহারকারী কত তাড়াতাড়ি আপনার সাইটের সাথে ইন্টারঅ্যাক্ট করতে পারে তা অনেক বেশি বিলম্ব করতে পারে। আপনি যত বেশি জাভাস্ক্রিপ্ট পাঠাবেন, আপনার সাইট ইন্টারেক্টিভ হওয়ার আগে এটি পার্স এবং কম্পাইল করতে তত বেশি সময় লাগবে।

বাইট-ফর-বাইট, জাভাস্ক্রিপ্ট ব্রাউজারের জন্য সমান আকারের চিত্র বা ওয়েব ফন্টের চেয়ে প্রক্রিয়াকরণের জন্য বেশি ব্যয়বহুল — টম ডেল

জাভাস্ক্রিপ্টের তুলনায়, সমতুল্য আকারের ছবি প্রক্রিয়াকরণে অনেক খরচ জড়িত (এগুলি এখনও ডিকোড করতে হবে!) কিন্তু গড় মোবাইল হার্ডওয়্যারে, JS একটি পৃষ্ঠার ইন্টারঅ্যাক্টিভিটিকে নেতিবাচকভাবে প্রভাবিত করার সম্ভাবনা বেশি।

ALT_TEXT_HERE
জাভাস্ক্রিপ্ট এবং ইমেজ বাইটের খরচ আলাদা। চিত্রগুলি সাধারণত মূল থ্রেডটিকে ব্লক করে না বা ডিকোড এবং রাস্টারাইজড হওয়ার সময় ইন্টারফেসগুলিকে ইন্টারেক্টিভ হতে বাধা দেয় না। JS যদিও পার্স, কম্পাইল এবং এক্সিকিউশন খরচের কারণে ইন্টারঅ্যাক্টিভিটি বিলম্ব করতে পারে।

যখন আমরা পার্স এবং কম্পাইল ধীর হওয়ার কথা বলি; প্রসঙ্গ গুরুত্বপূর্ণ — আমরা এখানে গড় মোবাইল ফোনের কথা বলছি। গড় ব্যবহারকারীদের কাছে ধীরগতির সিপিইউ এবং জিপিইউ সহ ফোন থাকতে পারে, কোনও L2/L3 ক্যাশে নেই এবং যা মেমরি সীমাবদ্ধও হতে পারে।

নেটওয়ার্ক ক্ষমতা এবং ডিভাইস ক্ষমতা সবসময় মেলে না। একটি আশ্চর্যজনক ফাইবার সংযোগ সহ একজন ব্যবহারকারীর কাছে তাদের ডিভাইসে পাঠানো জাভাস্ক্রিপ্ট পার্স এবং মূল্যায়ন করার জন্য সর্বোত্তম CPU থাকা আবশ্যক নয়। এটি বিপরীতেও সত্য... একটি ভয়ানক নেটওয়ার্ক সংযোগ, কিন্তু একটি জ্বলন্ত দ্রুত CPU। — ক্রিস্টোফার ব্যাক্সটার, লিঙ্কডইন

নীচে আমরা নিম্ন এবং উচ্চ-সম্পন্ন হার্ডওয়্যারে ~1MB ডিকম্প্রেসড (সরল) জাভাস্ক্রিপ্ট পার্স করার খরচ দেখতে পাচ্ছি। বাজারের দ্রুততম ফোন এবং গড় ফোনের মধ্যে কোড পার্স/কম্পাইল করার সময়ের মধ্যে 2-5x পার্থক্য রয়েছে

ALT_TEXT_HERE
এই গ্রাফটি বিভিন্ন শ্রেণীর ডেস্কটপ এবং মোবাইল ডিভাইস জুড়ে জাভাস্ক্রিপ্টের 1MB বান্ডেল (~250KB gzipped) এর জন্য পার্স বার হাইলাইট করে। পার্সের খরচের দিকে তাকানোর সময়, এটি ডিকম্প্রেস করা পরিসংখ্যানগুলিকে বিবেচনা করতে হবে যেমন ~250KB gzipped JS ডিকম্প্রেস করে ~1MB কোড।

CNN.com এর মতো একটি বাস্তব-বিশ্বের সাইট সম্পর্কে কী?

হাই-এন্ড আইফোন 8-এ সিএনএন-এর জেএসকে পার্স/কম্পাইল করতে মাত্র ~4সেকেন্ড লাগে একটি গড় ফোনের (মোটো জি4) জন্য ~13s এর তুলনায়। এটি উল্লেখযোগ্যভাবে প্রভাবিত করতে পারে যে কত দ্রুত একজন ব্যবহারকারী এই সাইটের সাথে সম্পূর্ণভাবে ইন্টারঅ্যাক্ট করতে পারে।

ALT_TEXT_HERE
উপরে আমরা আরও গড় অ্যান্ড্রয়েড হার্ডওয়্যারে স্ন্যাপড্রাগন 617-এর সাথে অ্যাপলের A11 বায়োনিক চিপের পারফরম্যান্সের তুলনা করার সময় পার্স দেখতে পাচ্ছি।

এটি আপনার পকেটে থাকা ফোনের পরিবর্তে গড় হার্ডওয়্যার (যেমন Moto G4) পরীক্ষা করার গুরুত্ব তুলে ধরে। তবে প্রসঙ্গ গুরুত্বপূর্ণ: আপনার ব্যবহারকারীদের ডিভাইস এবং নেটওয়ার্ক অবস্থার জন্য অপ্টিমাইজ করুন।

ALT_TEXT_HERE
গুগল অ্যানালিটিক্স মোবাইল ডিভাইস ক্লাসের অন্তর্দৃষ্টি প্রদান করতে পারে যা আপনার প্রকৃত ব্যবহারকারীরা আপনার সাইটে অ্যাক্সেস করছে। এটি বাস্তব সিপিইউ/জিপিইউ সীমাবদ্ধতা বোঝার সুযোগ প্রদান করতে পারে যার সাথে তারা কাজ করছে।

আমরা কি সত্যিই খুব বেশি জাভাস্ক্রিপ্ট পাঠাচ্ছি? ভুল, সম্ভবত :)

মোবাইলে জাভাস্ক্রিপ্টের অবস্থা বিশ্লেষণ করতে HTTP আর্কাইভ (শীর্ষ ~500K সাইট) ব্যবহার করে, আমরা দেখতে পাচ্ছি যে 50% সাইট ইন্টারেক্টিভ হতে 14 সেকেন্ডের বেশি সময় নেয়। এই সাইটগুলি JS পার্সিং এবং কম্পাইল করতে 4 সেকেন্ড পর্যন্ত সময় ব্যয় করে।

ALT_TEXT_HERE

JS এবং অন্যান্য সংস্থানগুলি আনতে এবং প্রক্রিয়া করতে যে সময় লাগে তার ফ্যাক্টর এবং এটি সম্ভবত আশ্চর্যজনক নয় যে পৃষ্ঠাগুলি ব্যবহারের জন্য প্রস্তুত অনুভব করার আগে ব্যবহারকারীদের কিছুক্ষণ অপেক্ষা করা যেতে পারে। আমরা অবশ্যই এখানে আরও ভাল করতে পারি।

আপনার পৃষ্ঠাগুলি থেকে অ-সমালোচনামূলক জাভাস্ক্রিপ্ট সরানো ট্রান্সমিশন সময়, CPU- নিবিড় পার্সিং এবং কম্পাইলিং এবং সম্ভাব্য মেমরি ওভারহেড কমাতে পারে। এটি আপনার পৃষ্ঠাগুলিকে দ্রুত ইন্টারেক্টিভ করতে সহায়তা করে৷

সঞ্চালনের সময়

এটি শুধুমাত্র পার্স এবং কম্পাইল নয় যে একটি খরচ থাকতে পারে. জাভাস্ক্রিপ্ট এক্সিকিউশন (কোড পার্স/কম্পাইল হয়ে গেলে রানিং) হল একটি অপারেশন যা মূল থ্রেডে ঘটতে হয়। একটি ব্যবহারকারী কত তাড়াতাড়ি আপনার সাইটের সাথে ইন্টারঅ্যাক্ট করতে পারে তাও দীর্ঘ কার্যকর করার সময় ধাক্কা দিতে পারে।

ALT_TEXT_HERE

যদি স্ক্রিপ্ট 50ms এর বেশি সময় ধরে চালানো হয়, তাহলে JS ডাউনলোড, কম্পাইল এবং এক্সিকিউট করতে যে পরিমাণ সময় লাগে তার থেকে টাইম-টু-ইন্টারেক্টিভ বিলম্বিত হয় — অ্যালেক্স রাসেল

এটি মোকাবেলা করার জন্য, জাভাস্ক্রিপ্ট প্রধান থ্রেড লক করা এড়াতে ছোট খণ্ডে থাকা থেকে উপকৃত হয়। নির্বাহের সময় কতটা কাজ করা হচ্ছে তা আপনি কমাতে পারেন কিনা তা অন্বেষণ করুন।

অন্যান্য খরচাপাতি

জাভাস্ক্রিপ্ট অন্যান্য উপায়ে পৃষ্ঠার কর্মক্ষমতা প্রভাবিত করতে পারে:

  • স্মৃতি. GC (আবর্জনা সংগ্রহ) এর কারণে পৃষ্ঠাগুলি ঘন ঘন জ্যাঙ্ক বা পজ হতে পারে। যখন একটি ব্রাউজার মেমরি পুনরুদ্ধার করে, তখন JS এক্সিকিউশন পজ করা হয় যাতে একটি ব্রাউজার ঘন ঘন আবর্জনা সংগ্রহ করে আমাদের পছন্দের চেয়ে বেশি ঘন ঘন এক্সিকিউশনকে থামাতে পারে। পৃষ্ঠাগুলিকে জ্যাঙ্ক মুক্ত রাখতে মেমরি লিক এবং ঘন ঘন জিসি বিরতি এড়িয়ে চলুন।
  • রানটাইম চলাকালীন, দীর্ঘ সময় ধরে চলমান জাভাস্ক্রিপ্ট প্রধান-থ্রেডের কারণে পৃষ্ঠাগুলিকে ব্লক করতে পারে যা প্রতিক্রিয়াহীন। কাজকে ছোট ছোট টুকরোতে বিভক্ত করা (অনুরোধের জন্য requestAnimationFrame() বা requestIdleCallback() ব্যবহার করে প্রতিক্রিয়াশীলতার সমস্যাগুলি হ্রাস করতে পারে যা নেক্সট পেইন্ট (আইএনপি) এর সাথে ইন্টারঅ্যাকশন উন্নত করতে সহায়তা করতে পারে।

জাভাস্ক্রিপ্ট ডেলিভারি খরচ কমানোর জন্য নিদর্শন

আপনি যখন জাভাস্ক্রিপ্টের জন্য পার্স/কম্পাইল এবং নেটওয়ার্ক ট্রান্সমিট সময় ধীর রাখার চেষ্টা করছেন, তখন এমন প্যাটার্ন রয়েছে যা রুট-ভিত্তিক চঙ্কিং বা PRPL- এর মতো সাহায্য করতে পারে।

পিআরপিএল

PRPL (Push, Render, Pre-cache, Lazy-load) হল একটি প্যাটার্ন যা আক্রমনাত্মক কোড-বিভাজন এবং ক্যাশিংয়ের মাধ্যমে ইন্টারঅ্যাক্টিভিটির জন্য অপ্টিমাইজ করে:

ALT_TEXT_HERE

এর প্রভাব কি হতে পারে তা কল্পনা করা যাক।

আমরা V8 এর রানটাইম কল পরিসংখ্যান ব্যবহার করে জনপ্রিয় মোবাইল সাইট এবং প্রগ্রেসিভ ওয়েব অ্যাপের লোড-টাইম বিশ্লেষণ করি। আমরা দেখতে পাচ্ছি, পার্স টাইম (কমলা রঙে দেখানো হয়েছে) হল একটি উল্লেখযোগ্য অংশ যেখানে এই সাইটগুলির মধ্যে অনেকগুলি তাদের সময় ব্যয় করে:

ALT_TEXT_HERE

Wego , একটি সাইট যা PRPL ব্যবহার করে, তাদের রুটের জন্য একটি কম পার্স টাইম বজায় রাখে, খুব দ্রুত ইন্টারেক্টিভ হয়। উপরের অন্যান্য সাইটগুলির মধ্যে অনেকগুলি তাদের JS খরচ কমানোর চেষ্টা করার জন্য কোড-বিভাজন এবং কর্মক্ষমতা বাজেট গ্রহণ করেছে।

প্রগতিশীল বুটস্ট্র্যাপিং

অনেক সাইট ইন্টারঅ্যাক্টিভিটির ব্যয়বহুল কন্টেন্ট দৃশ্যমানতা অপ্টিমাইজ করে। আপনার কাছে বড় জাভাস্ক্রিপ্ট বান্ডিল থাকলে দ্রুত প্রথম পেইন্ট পেতে, ডেভেলপাররা কখনও কখনও সার্ভার-সাইড রেন্ডারিং নিযুক্ত করে; তারপর জাভাস্ক্রিপ্ট অবশেষে আনা হলে ইভেন্ট হ্যান্ডলার সংযুক্ত করতে এটি "আপগ্রেড" করুন।

সতর্ক থাকুন - এর নিজস্ব খরচ আছে। আপনি 1) সাধারণত একটি বৃহত্তর HTML প্রতিক্রিয়া পাঠান যা আমাদের ইন্টারঅ্যাক্টিভিটিকে ধাক্কা দিতে পারে, 2) ব্যবহারকারীকে একটি অদ্ভুত উপত্যকায় ছেড়ে যেতে পারে যেখানে জাভাস্ক্রিপ্ট প্রক্রিয়াকরণ শেষ না হওয়া পর্যন্ত অর্ধেক অভিজ্ঞতা আসলে ইন্টারেক্টিভ হতে পারে না।

প্রগতিশীল বুটস্ট্র্যাপিং একটি ভাল পদ্ধতি হতে পারে। একটি ন্যূনতম কার্যকরী পৃষ্ঠা পাঠান (বর্তমান রুটের জন্য প্রয়োজনীয় HTML/JS/CSS দিয়ে গঠিত)। যত বেশি সংস্থান আসে, অ্যাপটি অলস-লোড করতে পারে এবং আরও বৈশিষ্ট্য আনলক করতে পারে।

ALT_TEXT_HERE
পল লুইস দ্বারা প্রগতিশীল বুটস্ট্র্যাপিং

লোডিং কোডটি হলি গ্রেইলের সাথে সমানুপাতিক। পিআরপিএল এবং প্রগ্রেসিভ বুটস্ট্র্যাপিং এমন নিদর্শন যা এটি সম্পন্ন করতে সাহায্য করতে পারে।

উপসংহার

লো-এন্ড নেটওয়ার্কের জন্য ট্রান্সমিশন সাইজ গুরুত্বপূর্ণ। CPU আবদ্ধ ডিভাইসের জন্য পার্স সময় গুরুত্বপূর্ণ। এসব বিষয় কম রাখা।

দলগুলি তাদের জাভাস্ক্রিপ্ট ট্রান্সমিশন এবং পার্স/কম্পাইলের সময় কম রাখার জন্য কঠোর কর্মক্ষমতা বাজেট গ্রহণ করে সফলতা পেয়েছে। মোবাইলের জন্য বাজেটের দিকনির্দেশনার জন্য অ্যালেক্স রাসেলের " আপনি কি এটি বহন করতে পারেন?: বাস্তব-বিশ্বের ওয়েব পারফরম্যান্স বাজেট " দেখুন।

ALT_TEXT_HERE
আমরা যে আর্কিটেকচারাল সিদ্ধান্তগুলি করি তা আমাদের অ্যাপের যুক্তির জন্য কতটা JS "হেডরুম" ছেড়ে দিতে পারে তা বিবেচনা করা দরকারী।

আপনি যদি মোবাইল ডিভাইসগুলিকে লক্ষ্য করে এমন একটি সাইট তৈরি করেন, তাহলে প্রতিনিধি হার্ডওয়্যারে বিকাশ করার জন্য আপনার যথাসাধ্য চেষ্টা করুন, আপনার জাভাস্ক্রিপ্ট পার্স/কম্পাইলের সময় কম রাখুন এবং আপনার দল তাদের JavaScript খরচের উপর নজর রাখতে সক্ষম তা নিশ্চিত করার জন্য একটি পারফরম্যান্স বাজেট গ্রহণ করুন।

আরও জানুন