গুগল আইও ২০১৮ তে, আমরা ওয়েব পারফরম্যান্স উন্নত করা সহজ করে এমন টুল, লাইব্রেরি এবং অপ্টিমাইজেশন কৌশলগুলির একটি সংক্ষিপ্তসার উপস্থাপন করেছি। এখানে আমরা The Oodles Theatre অ্যাপ ব্যবহার করে সেগুলি ব্যাখ্যা করব। আমরা ভবিষ্যদ্বাণীমূলক লোডিং এবং নতুন Guess.js উদ্যোগের সাথে আমাদের পরীক্ষা-নিরীক্ষা সম্পর্কেও কথা বলব।
গত এক বছর ধরে আমরা ওয়েবকে আরও দ্রুত এবং আরও কার্যকর করে তোলার উপায় খুঁজে বের করার চেষ্টায় বেশ ব্যস্ত ছিলাম। এর ফলে নতুন টুল, পদ্ধতি এবং লাইব্রেরি তৈরি হয়েছে যা আমরা এই প্রবন্ধে আপনার সাথে শেয়ার করতে চাই। প্রথম অংশে, আমরা আপনাকে The Oodles Theatre অ্যাপ তৈরির সময় ব্যবহার করা কিছু অপ্টিমাইজেশন কৌশল দেখাব। দ্বিতীয় অংশে, আমরা ভবিষ্যদ্বাণীমূলক লোডিং এবং নতুন Guess.js উদ্যোগ নিয়ে আমাদের পরীক্ষা-নিরীক্ষা সম্পর্কে কথা বলব।
কর্মক্ষমতার প্রয়োজনীয়তা
ইন্টারনেট প্রতি বছর ভারী থেকে ভারী হয়ে উঠছে। যদি আমরা ওয়েবের অবস্থা পরীক্ষা করি তাহলে আমরা দেখতে পাব যে মোবাইলে একটি গড় পৃষ্ঠার ওজন প্রায় 1.5MB, যার বেশিরভাগই জাভাস্ক্রিপ্ট এবং ছবি।
ওয়েবসাইটের ক্রমবর্ধমান আকার, নেটওয়ার্ক ল্যাটেন্সি, সিপিইউ সীমাবদ্ধতা, রেন্ডার-ব্লকিং প্যাটার্ন বা অতিরিক্ত থার্ড-পার্টি কোডের মতো অন্যান্য কারণগুলির সাথে, জটিল পারফরম্যান্স ধাঁধায় অবদান রাখে।
বেশিরভাগ ব্যবহারকারীই গতিকে তাদের চাহিদার UX শ্রেণিবিন্যাসের একেবারে শীর্ষে বলে মনে করেন। এটি খুব একটা আশ্চর্যজনক নয়, কারণ একটি পৃষ্ঠা লোড করা শেষ না হওয়া পর্যন্ত আপনি আসলে অনেক কিছু করতে পারবেন না। আপনি পৃষ্ঠা থেকে মূল্য অর্জন করতে পারবেন না, আপনি এর নান্দনিকতার প্রশংসা করতে পারবেন না।
আমরা জানি যে ব্যবহারকারীদের কাছে কর্মক্ষমতা গুরুত্বপূর্ণ, তবে এটি কোথা থেকে অপ্টিমাইজেশন শুরু করতে হবে তা আবিষ্কার করার একটি গোপন বিষয়ও মনে হতে পারে। সৌভাগ্যবশত, এমন কিছু সরঞ্জাম রয়েছে যা আপনাকে পথে সাহায্য করতে পারে।
বাতিঘর - কর্মক্ষমতা কর্মপ্রবাহের জন্য একটি ভিত্তি
লাইটহাউস হল Chrome DevTools-এর একটি অংশ যা আপনাকে আপনার ওয়েবসাইটের অডিট করার সুযোগ দেয় এবং এটিকে কীভাবে আরও ভালো করা যায় সে সম্পর্কে আপনাকে ইঙ্গিত দেয়।
আমরা সম্প্রতি বেশ কিছু নতুন পারফরম্যান্স অডিট চালু করেছি যা দৈনন্দিন উন্নয়ন কর্মপ্রবাহে সত্যিই কার্যকর।
আসুন একটি ব্যবহারিক উদাহরণ ব্যবহার করে আপনি কীভাবে এগুলি থেকে সুবিধা নিতে পারেন তা অন্বেষণ করি: ওডলস থিয়েটার অ্যাপ । এটি একটি ছোট ডেমো ওয়েব অ্যাপ, যেখানে আপনি আমাদের প্রিয় কিছু ইন্টারেক্টিভ গুগল ডুডল চেষ্টা করে দেখতে পারেন এবং এমনকি একটি বা দুটি গেম খেলতে পারেন।
অ্যাপটি তৈরি করার সময়, আমরা নিশ্চিত করতে চেয়েছিলাম যে এটি যতটা সম্ভব কার্যকর। অপ্টিমাইজেশনের সূচনা বিন্দু ছিল একটি লাইটহাউস রিপোর্ট।
লাইটহাউস রিপোর্টে দেখা গেছে, আমাদের অ্যাপের প্রাথমিক পারফরম্যান্স বেশ খারাপ ছিল। 3G নেটওয়ার্কে, ব্যবহারকারীকে প্রথম অর্থবহ পেইন্টের জন্য 15 সেকেন্ড অপেক্ষা করতে হত, অথবা অ্যাপটি ইন্টারেক্টিভ হওয়ার জন্য। লাইটহাউস আমাদের সাইটের সাথে অনেক সমস্যা তুলে ধরেছিল এবং 23 এর সামগ্রিক পারফরম্যান্স স্কোর ঠিক সেই প্রতিফলন করে।
পৃষ্ঠাটির ওজন প্রায় ৩.৪ এমবি ছিল - আমাদের কিছুটা কমানো খুব জরুরি ছিল।
এটি আমাদের প্রথম পারফর্ম্যান্স চ্যালেঞ্জ শুরু করে: এমন জিনিসগুলি খুঁজে বের করা যা আমরা সামগ্রিক অভিজ্ঞতাকে প্রভাবিত না করে সহজেই অপসারণ করতে পারি।
কর্মক্ষমতা অপ্টিমাইজেশনের সুযোগ
অপ্রয়োজনীয় সম্পদ অপসারণ করুন
কিছু স্পষ্ট জিনিস আছে যা নিরাপদে মুছে ফেলা যেতে পারে: হোয়াইটস্পেস এবং মন্তব্য।
লাইটহাউস আনমিনিফায়েড সিএসএস এবং জাভাস্ক্রিপ্ট অডিটে এই সুযোগটি তুলে ধরেছে। আমরা আমাদের বিল্ড প্রক্রিয়ার জন্য ওয়েবপ্যাক ব্যবহার করছিলাম, তাই মিনিফিকেশন পেতে আমরা কেবল Uglify JS প্লাগইন ব্যবহার করেছি।
মিনিফিকেশন একটি সাধারণ কাজ, তাই আপনি যে কোনও বিল্ড প্রক্রিয়া ব্যবহার করুন না কেন, তার জন্য একটি প্রস্তুত সমাধান খুঁজে পেতে সক্ষম হবেন।
এই ক্ষেত্রে আরেকটি কার্যকর অডিট হল টেক্সট কম্প্রেশন সক্ষম করুন । আনকম্প্রেসড ফাইল পাঠানোর কোনও কারণ নেই, এবং বেশিরভাগ সিডিএন আজকাল এটিকে বাইরে থেকে সমর্থন করে।
আমরা আমাদের কোড হোস্ট করার জন্য Firebase Hosting ব্যবহার করছিলাম, এবং Firebase ডিফল্টরূপে gzipping সক্ষম করে, তাই একটি যুক্তিসঙ্গত CDN-তে আমাদের কোড হোস্ট করার সুবিধার জন্য আমরা এটি বিনামূল্যে পেয়েছি।
যদিও gzip কম্প্রেস করার একটি খুব জনপ্রিয় উপায়, Zopfli এবং Brotli এর মতো অন্যান্য প্রক্রিয়াগুলিও ট্র্যাকশন পাচ্ছে। বেশিরভাগ ব্রাউজারেই Brotli সমর্থন পায় এবং আপনি সার্ভারে পাঠানোর আগে আপনার সম্পদগুলিকে প্রাক-সংকুচিত করার জন্য একটি বাইনারি ব্যবহার করতে পারেন।
দক্ষ ক্যাশে নীতি ব্যবহার করুন
আমাদের পরবর্তী পদক্ষেপ ছিল নিশ্চিত করা যে আমরা অপ্রয়োজনে দুবার রিসোর্স পাঠাবো না।
লাইটহাউসের ইনঅফিসিয়েন্ট ক্যাশে পলিসি অডিট আমাদের লক্ষ্য করতে সাহায্য করেছে যে আমরা ঠিক সেই লক্ষ্যে আমাদের ক্যাশিং কৌশলগুলি অপ্টিমাইজ করতে পারি। আমাদের সার্ভারে সর্বোচ্চ-বয়স মেয়াদ শেষ হওয়ার হেডার সেট করে, আমরা নিশ্চিত করেছি যে বারবার ভিজিটের সময় ব্যবহারকারীরা তাদের আগে ডাউনলোড করা রিসোর্সগুলি পুনরায় ব্যবহার করতে পারেন।
আদর্শভাবে আপনার লক্ষ্য রাখা উচিত যতটা সম্ভব নিরাপদে যতটা সম্ভব রিসোর্স ক্যাশে করা এবং আপডেট হওয়া রিসোর্সগুলির দক্ষ পুনঃপ্রমাণের জন্য বৈধতা টোকেন প্রদান করা।
অব্যবহৃত কোড সরান
এখন পর্যন্ত আমরা অপ্রয়োজনীয় ডাউনলোডের স্পষ্ট অংশগুলি সরিয়ে ফেলেছি, কিন্তু কম স্পষ্ট অংশগুলির কী হবে? উদাহরণস্বরূপ, অব্যবহৃত কোড।
কখনও কখনও আমরা আমাদের অ্যাপে এমন কোড অন্তর্ভুক্ত করি যা আসলে প্রয়োজনীয় নয়। এটি বিশেষ করে যদি আপনি আপনার অ্যাপে দীর্ঘ সময় ধরে কাজ করেন, আপনার টিম বা আপনার নির্ভরতা পরিবর্তিত হয়, এবং কখনও কখনও একটি অনাথ লাইব্রেরি পিছনে পড়ে যায়। আমাদের সাথে ঠিক এটিই ঘটেছে।
শুরুতে আমরা আমাদের অ্যাপটি দ্রুত প্রোটোটাইপ করার জন্য ম্যাটেরিয়াল কম্পোনেন্টস লাইব্রেরি ব্যবহার করছিলাম। সময়ের সাথে সাথে আমরা আরও কাস্টম লুক এবং ফিল ব্যবহার করতে শুরু করি এবং সেই লাইব্রেরিটি সম্পূর্ণরূপে ভুলে যাই। সৌভাগ্যবশত, কোড কভারেজ চেক আমাদের বান্ডেলে এটি পুনরায় আবিষ্কার করতে সাহায্য করেছে।
আপনি DevTools-এ আপনার কোড কভারেজের পরিসংখ্যান পরীক্ষা করতে পারেন, আপনার অ্যাপ্লিকেশনের রানটাইম এবং লোড টাইম উভয়ের জন্য। নীচের স্ক্রিনশটে আপনি দুটি বড় লাল স্ট্রাইপ দেখতে পাচ্ছেন - আমাদের 95% এরও বেশি CSS অব্যবহৃত ছিল, এবং জাভাস্ক্রিপ্টের একটি বড় অংশও ছিল।
অব্যবহৃত CSS রুলস অডিটেও Lighthouse এই সমস্যাটি তুলে ধরেছে। এতে 400kb এরও বেশি সাশ্রয় হওয়ার সম্ভাবনা দেখা গেছে। তাই আমরা আমাদের কোডে ফিরে এসেছি এবং সেই লাইব্রেরির JavaScript এবং CSS উভয় অংশই সরিয়ে ফেলেছি।
এর ফলে আমাদের CSS বান্ডেল ২০ গুণ কমে গেছে, যা একটি ছোট, দুই লাইনের কমিটের জন্য বেশ ভালো।
অবশ্যই, এটি আমাদের পারফরম্যান্স স্কোর বাড়িয়েছে, এবং টাইম টু ইন্টারেক্টিভও অনেক ভালো হয়েছে।
তবে, এই ধরণের পরিবর্তনের সাথে, কেবল আপনার মেট্রিক্স এবং স্কোর পরীক্ষা করা যথেষ্ট নয়। প্রকৃত কোড অপসারণ কখনই ঝুঁকিমুক্ত নয়, তাই আপনার সর্বদা সম্ভাব্য রিগ্রেশনের দিকে নজর রাখা উচিত।
আমাদের কোড ৯৫% তে অব্যবহৃত ছিল - এখনও এই ৫% কোথাও আছে। স্পষ্টতই আমাদের একটি উপাদান এখনও সেই লাইব্রেরির স্টাইলগুলি ব্যবহার করছিল - ডুডল স্লাইডারের ছোট তীরগুলি। যদিও এটি এত ছোট ছিল যে, আমরা কেবল ম্যানুয়ালি সেই স্টাইলগুলি আবার বোতামগুলিতে অন্তর্ভুক্ত করতে পারতাম।
তাই যদি আপনি কোডটি সরিয়ে ফেলেন, তাহলে নিশ্চিত করুন যে আপনার কাছে একটি সঠিক পরীক্ষার কর্মপ্রবাহ আছে যা আপনাকে সম্ভাব্য ভিজ্যুয়াল রিগ্রেশন থেকে রক্ষা করতে সাহায্য করবে।
বিশাল নেটওয়ার্ক পেলোড এড়িয়ে চলুন
আমরা জানি যে বৃহৎ রিসোর্স ওয়েব পৃষ্ঠা লোডের গতি কমাতে পারে। এতে আমাদের ব্যবহারকারীদের অর্থ ব্যয় হতে পারে এবং তাদের ডেটা প্ল্যানের উপর বড় প্রভাব পড়তে পারে, তাই এই বিষয়টি সম্পর্কে সচেতন থাকা সত্যিই গুরুত্বপূর্ণ।
Enormous নেটওয়ার্ক পেলোড অডিট ব্যবহার করে Lighthouse আমাদের কিছু নেটওয়ার্ক পেলোডের সাথে সমস্যা সনাক্ত করতে সক্ষম হয়েছে।
এখানে আমরা দেখতে পেলাম যে আমাদের কাছে ৩ মেগাবাইটেরও বেশি মূল্যের কোড পাঠানো হচ্ছিল - যা বেশ অনেক, বিশেষ করে মোবাইলে।
এই তালিকার একেবারে উপরে, লাইটহাউস হাইলাইট করেছে যে আমাদের কাছে একটি জাভাস্ক্রিপ্ট ভেন্ডর বান্ডেল রয়েছে যা 2 এমবি আনকম্প্রেসড কোডের। এটিও ওয়েবপ্যাক দ্বারা হাইলাইট করা একটি সমস্যা।
কথায় আছে: সবচেয়ে দ্রুত অনুরোধ হল সেই অনুরোধ যা করা হয় না।
আদর্শভাবে, আপনার ব্যবহারকারীদের কাছে পরিবেশন করা প্রতিটি সম্পদের মূল্য পরিমাপ করা উচিত, সেই সম্পদের কর্মক্ষমতা পরিমাপ করা উচিত এবং প্রাথমিক অভিজ্ঞতার সাথে এটি আসলে পাঠানোর যোগ্য কিনা তা নির্ধারণ করা উচিত। কারণ কখনও কখনও এই সম্পদগুলি বিলম্বিত হতে পারে, অথবা অলসভাবে লোড করা যেতে পারে, অথবা অলস সময়ে প্রক্রিয়াজাত করা যেতে পারে।
আমাদের ক্ষেত্রে, যেহেতু আমরা অনেক জাভাস্ক্রিপ্ট বান্ডেল নিয়ে কাজ করছি, আমরা ভাগ্যবান কারণ জাভাস্ক্রিপ্ট কমিউনিটিতে জাভাস্ক্রিপ্ট বান্ডেল অডিটিং টুলের একটি সমৃদ্ধ সেট রয়েছে।
আমরা ওয়েবপ্যাক বান্ডেল অ্যানালাইজার দিয়ে শুরু করেছিলাম, যা আমাদের জানিয়েছিল যে আমরা ইউনিকোড নামক একটি নির্ভরতা অন্তর্ভুক্ত করছি যা পার্সড জাভাস্ক্রিপ্টের 1.6mb ছিল, তাই বেশ কিছু।
এরপর আমরা আমাদের সম্পাদকের কাছে গেলাম এবং ভিজ্যুয়াল কোডের জন্য আমদানি খরচ প্লাগইন ব্যবহার করে আমরা প্রতিটি মডিউলের খরচ কল্পনা করতে সক্ষম হয়েছি যা আমরা আমদানি করছিলাম। এর ফলে আমরা আবিষ্কার করতে পেরেছিলাম যে কোন উপাদানটিতে এই মডিউলটি উল্লেখ করা কোড অন্তর্ভুক্ত ছিল।
এরপর আমরা আরেকটি টুল, BundlePhobia ব্যবহার করি। এটি এমন একটি টুল যা আপনাকে যেকোনো NPM প্যাকেজের নাম লিখতে এবং এর মিনিফায়েড এবং জিজিপড আকার কত তা দেখতে দেয়। আমরা যে স্লাগ মডিউলটি ব্যবহার করছিলাম তার জন্য আমরা একটি চমৎকার বিকল্প খুঁজে পেয়েছি যার ওজন মাত্র 2.2kb ছিল, তাই আমরা এটি পরিবর্তন করেছি।
এর ফলে আমাদের কর্মক্ষমতার উপর বিরাট প্রভাব পড়েছে। এই পরিবর্তন এবং আমাদের জাভাস্ক্রিপ্ট বান্ডেলের আকার কমানোর অন্যান্য সুযোগ আবিষ্কারের মধ্যে, আমরা ২.১ মেগাবাইট কোড সাশ্রয় করেছি।
এই বান্ডেলগুলির জিজিপড এবং মিনিফাইড আকার বিবেচনা করার পরে, আমরা সামগ্রিকভাবে 65% উন্নতি দেখতে পেয়েছি। এবং আমরা দেখেছি যে এটি একটি প্রক্রিয়া হিসাবে সত্যিই করার যোগ্য ছিল।
তাই, সাধারণভাবে, আপনার সাইট এবং অ্যাপগুলিতে অপ্রয়োজনীয় ডাউনলোডগুলি বাদ দেওয়ার চেষ্টা করুন। আপনার সম্পদের একটি তালিকা তৈরি করুন এবং তাদের কর্মক্ষমতার প্রভাব পরিমাপ করুন যা সত্যিই বড় পার্থক্য আনতে পারে, তাই নিশ্চিত করুন যে আপনি নিয়মিতভাবে আপনার সম্পদগুলি নিরীক্ষণ করছেন।
কোড বিভাজনের মাধ্যমে জাভাস্ক্রিপ্ট বুট-আপ সময় কমানো
যদিও বৃহৎ নেটওয়ার্ক পেলোড আমাদের অ্যাপের উপর বড় প্রভাব ফেলতে পারে, তবে আরেকটি জিনিস আছে যা সত্যিই বড় প্রভাব ফেলতে পারে, এবং তা হল জাভাস্ক্রিপ্ট।
জাভাস্ক্রিপ্ট আপনার সবচেয়ে দামি সম্পদ । মোবাইলে, যদি আপনি জাভাস্ক্রিপ্টের বিশাল বান্ডিল পাঠান, তাহলে আপনার ব্যবহারকারীরা আপনার ইউজার ইন্টারফেস উপাদানগুলির সাথে ইন্টারঅ্যাক্ট করতে কত তাড়াতাড়ি সক্ষম হবেন তা বিলম্বিত হতে পারে। এর অর্থ হল তারা কোনও অর্থপূর্ণ ঘটনা ছাড়াই UI-তে ট্যাপ করতে পারে। তাই আমাদের জন্য এটা বোঝা গুরুত্বপূর্ণ যে জাভাস্ক্রিপ্টের এত দাম কেন।
এইভাবে একটি ব্রাউজার জাভাস্ক্রিপ্ট প্রক্রিয়া করে।
আমাদের প্রথমে সেই স্ক্রিপ্টটি ডাউনলোড করতে হবে, আমাদের কাছে একটি জাভাস্ক্রিপ্ট ইঞ্জিন আছে যা তারপর সেই কোডটি পার্স করতে হবে, এটি কম্পাইল করতে হবে এবং এটি কার্যকর করতে হবে।
এখন এই ধাপগুলি এমন কিছু যা ডেস্কটপ মেশিন বা ল্যাপটপের মতো উচ্চমানের ডিভাইসে, এমনকি একটি উচ্চমানের ফোনেও খুব বেশি সময় নেয় না। কিন্তু একটি মাঝারি মোবাইল ফোনে এই প্রক্রিয়াটি পাঁচ থেকে দশ গুণ বেশি সময় নিতে পারে। এটিই ইন্টারঅ্যাক্টিভিটিকে বিলম্বিত করে, তাই আমাদের জন্য এটি কমিয়ে আনার চেষ্টা করা গুরুত্বপূর্ণ।
আপনার অ্যাপের এই সমস্যাগুলি খুঁজে বের করতে সাহায্য করার জন্য, আমরা Lighthouse-এ একটি নতুন JavaScript বুট-আপ টাইম অডিট চালু করেছি।
আর Oodle অ্যাপের ক্ষেত্রে, এটি আমাদের বলেছিল যে জাভাস্ক্রিপ্ট বুট-আপে আমাদের ১.৮ সেকেন্ড সময় ব্যয় হয়েছে। যা ঘটছিল তা হল আমরা আমাদের সমস্ত রুট এবং উপাদানগুলিকে একটি একক জাভাস্ক্রিপ্ট বান্ডেলে স্ট্যাটিকভাবে আমদানি করছিলাম।
এই সমস্যা সমাধানের একটি কৌশল হল কোড বিভাজন ব্যবহার করা।
কোড স্প্লিটিং হলো আপনার ব্যবহারকারীদের পুরো পিৎজার মতো জাভাস্ক্রিপ্ট দেওয়ার পরিবর্তে, যদি আপনি তাদের প্রয়োজন অনুসারে একবারে একটি স্লাইস দেন তবে কেমন হবে?
কোড স্প্লিটিং রুট লেভেল অথবা কম্পোনেন্ট লেভেলে প্রয়োগ করা যেতে পারে। এটি React এবং React Loadable, Vue.js, Angular, Polymer, Preact এবং আরও অনেক লাইব্রেরির সাথে দারুন কাজ করে।
আমরা আমাদের অ্যাপ্লিকেশনে কোড বিভাজন অন্তর্ভুক্ত করেছি, আমরা স্ট্যাটিক ইমপোর্ট থেকে ডাইনামিক ইমপোর্টে স্যুইচ করেছি, যার ফলে আমরা প্রয়োজন অনুসারে অ্যাসিঙ্ক্রোনাসলি অলসভাবে কোড লোড করতে পারি।
এর ফলে আমাদের বান্ডেলের আকার কমে গেল, একই সাথে জাভাস্ক্রিপ্ট বুট আপের সময়ও কমে গেল। এটি ০.৭৮ সেকেন্ডে নেমে এসেছে, যার ফলে অ্যাপটি ৫৬% দ্রুততর হয়েছে।
সাধারণভাবে, যদি আপনি জাভাস্ক্রিপ্ট-ভারী অভিজ্ঞতা তৈরি করেন, তাহলে নিশ্চিত করুন যে ব্যবহারকারীর কাছেই কেবল তাদের প্রয়োজনীয় কোড পাঠাবেন।
কোড স্প্লিটিং এর মতো ধারণাগুলি কাজে লাগান, ট্রি শেকিং এর মতো ধারণাগুলি অন্বেষণ করুন এবং ওয়েবপ্যাক ব্যবহার করলে আপনার লাইব্রেরির আকার কীভাবে কমানো যায় সে সম্পর্কে কিছু ধারণা পেতে webpack-libs-optimizations রেপো দেখুন।
ছবি অপ্টিমাইজ করুন
Oodle অ্যাপে আমরা অনেক ছবি ব্যবহার করছি। দুর্ভাগ্যবশত, Lighthouse আমাদের তুলনায় এটি নিয়ে অনেক কম উৎসাহী ছিল। বাস্তবে, আমরা তিনটি ছবি-সম্পর্কিত অডিটেই ব্যর্থ হয়েছি।
আমরা আমাদের ছবিগুলি অপ্টিমাইজ করতে ভুলে গেছি, আমরা সেগুলিকে সঠিকভাবে আকার দিচ্ছিলাম না, এবং অন্যান্য ছবির ফর্ম্যাট ব্যবহার করে আমরা কিছু লাভও পেতে পারি।
আমরা আমাদের ছবিগুলি অপ্টিমাইজ করে শুরু করেছি।
এককালীন অপ্টিমাইজেশন রাউন্ডের জন্য আপনি ImageOptim বা XNConvert এর মতো ভিজ্যুয়াল টুল ব্যবহার করতে পারেন।
আরও স্বয়ংক্রিয় পদ্ধতি হল আপনার বিল্ড প্রক্রিয়ায় একটি চিত্র অপ্টিমাইজেশন ধাপ যোগ করা, imagemin এর মতো লাইব্রেরি সহ।
এইভাবে আপনি নিশ্চিত করবেন যে ভবিষ্যতে যোগ করা ছবিগুলি স্বয়ংক্রিয়ভাবে অপ্টিমাইজ হয়ে যাবে। কিছু CDN, উদাহরণস্বরূপ Akamai অথবা তৃতীয় পক্ষের সমাধান যেমন Cloudinary , Fastly অথবা Uploadcare আপনাকে ব্যাপক চিত্র অপ্টিমাইজেশন সমাধান প্রদান করে। তাই আপনি সহজেই সেই পরিষেবাগুলিতে আপনার ছবিগুলি হোস্ট করতে পারেন।
খরচ বা লেটেন্সির সমস্যার কারণে যদি আপনি এটি করতে না চান, তাহলে থাম্বর বা ইমেজফ্লোর মতো প্রকল্পগুলি স্ব-হোস্টেড বিকল্পগুলি অফার করে।
আমাদের ব্যাকগ্রাউন্ড PNG ওয়েবপ্যাকে বড় হিসেবে চিহ্নিত করা হয়েছিল, এবং ঠিকই তাই। ভিউপোর্টে সঠিকভাবে সাইজ করার পর এবং ImageOptim-এর মাধ্যমে চালানোর পর, আমরা ১০০kb-এ নেমে এসেছি, যা গ্রহণযোগ্য।
আমাদের সাইটের একাধিক ছবির জন্য এটি পুনরাবৃত্তি করার ফলে আমরা সামগ্রিক পৃষ্ঠার ওজন উল্লেখযোগ্যভাবে কমাতে পেরেছি।
অ্যানিমেটেড কন্টেন্টের জন্য সঠিক ফর্ম্যাট ব্যবহার করুন
GIF গুলি সত্যিই ব্যয়বহুল হতে পারে। আশ্চর্যজনকভাবে, GIF ফর্ম্যাটটি প্রথমে কখনও অ্যানিমেশন প্ল্যাটফর্ম হিসাবে তৈরি করা হয়নি। অতএব, আরও উপযুক্ত ভিডিও ফর্ম্যাটে স্যুইচ করলে ফাইলের আকারের দিক থেকে আপনি প্রচুর সাশ্রয় পাবেন।
Oodle অ্যাপে, আমরা হোম পেজে একটি ভূমিকা ক্রম হিসেবে একটি GIF ব্যবহার করছিলাম। Lighthouse এর মতে, আরও দক্ষ ভিডিও ফর্ম্যাটে স্যুইচ করে আমরা 7mb এর বেশি সাশ্রয় করতে পারতাম। আমাদের ক্লিপটির ওজন ছিল প্রায় 7.3mb, যেকোনো যুক্তিসঙ্গত ওয়েবসাইটের জন্য অনেক বেশি, তাই আমরা এটিকে দুটি সোর্স ফাইল সহ একটি ভিডিও উপাদানে রূপান্তরিত করেছি - একটি mp4 এবং একটি বৃহত্তর ব্রাউজার সমর্থনের জন্য WebM।
আমরা আমাদের অ্যানিমেশন GIF কে mp4 ফাইলে রূপান্তর করার জন্য FFmpeg টুল ব্যবহার করেছি। WebM ফর্ম্যাট আপনাকে আরও বেশি সঞ্চয় প্রদান করে - ImageOptim API আপনার জন্য এই ধরনের রূপান্তর করতে পারে।
ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4
এই রূপান্তরের ফলে আমরা আমাদের মোট ওজনের ৮০% এরও বেশি সাশ্রয় করতে পেরেছি। এর ফলে আমাদের ওজন প্রায় ১ মেগাবাইট কমেছে।
তবুও, 1mb তারের সাহায্যে কাজ করার জন্য একটি বড় রিসোর্স, বিশেষ করে সীমিত ব্যান্ডউইথ ব্যবহারকারীর জন্য। ভাগ্যক্রমে আমরা Effective Type API ব্যবহার করে বুঝতে পারি যে তারা ধীর ব্যান্ডউইথ ব্যবহার করছে, এবং পরিবর্তে তাদের অনেক ছোট JPEG দিতে পারি।
এই ইন্টারফেসটি ব্যবহারকারীর ব্যবহৃত নেটওয়ার্কের ধরণ অনুমান করার জন্য কার্যকর রাউন্ড-ট্রিপ সময় এবং ডাউনিং মান ব্যবহার করে। এটি কেবল একটি স্ট্রিং প্রদান করে, ধীর 2G, 2G, 3G অথবা 4G। তাই এই মানের উপর নির্ভর করে, যদি ব্যবহারকারী 4G এর নিচে থাকে তবে আমরা ভিডিও উপাদানটিকে চিত্র দিয়ে প্রতিস্থাপন করতে পারি।
if (navigator.connection.effectiveType) { ... }
এটি অভিজ্ঞতা থেকে কিছুটা সরে যায়, তবে অন্তত ধীর সংযোগে সাইটটি ব্যবহারযোগ্য।
স্ক্রিনের বাইরের ছবিগুলো অলসভাবে লোড করা হচ্ছে
ক্যারোজেল, স্লাইডার, অথবা খুব লম্বা পৃষ্ঠাগুলি প্রায়শই ছবি লোড করে, যদিও ব্যবহারকারী সরাসরি পৃষ্ঠায় সেগুলি দেখতে পান না।
লাইটহাউস অফ-স্ক্রিন ইমেজ অডিটে এই আচরণটি চিহ্নিত করবে এবং আপনি DevTools-এর নেটওয়ার্ক প্যানেলেও এটি নিজেই দেখতে পাবেন। যদি আপনি পৃষ্ঠায় খুব বেশি ছবি দেখতে পান এবং কয়েকটি দৃশ্যমান হয়, তাহলে এর অর্থ হল আপনি সেগুলি অলসভাবে লোড করার কথা বিবেচনা করতে পারেন।
ব্রাউজারে এখনও অলস লোডিং সমর্থিত নয়, তাই এই ক্ষমতা যোগ করার জন্য আমাদের জাভাস্ক্রিপ্ট ব্যবহার করতে হবে। আমরা আমাদের Oodle কভারগুলিতে অলস লোডিং আচরণ যোগ করার জন্য Lazysizes লাইব্রেরি ব্যবহার করেছি।
<!-- Import library -->
import lazysizes from 'lazysizes' <!-- or -->
<script src="lazysizes.min.js"></script>
<!-- Use it -->
<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
data-sizes="auto"
data-src="image2.jpg"
data-srcset="image1.jpg 300w,
image2.jpg 600w,
image3.jpg 900w"/>
Lazysizes স্মার্ট কারণ এটি কেবল উপাদানের দৃশ্যমানতার পরিবর্তনগুলি ট্র্যাক করে না, বরং সর্বোত্তম ব্যবহারকারীর অভিজ্ঞতার জন্য দৃশ্যের কাছাকাছি থাকা উপাদানগুলিকে সক্রিয়ভাবে প্রিফেট করে। এটি IntersectionObserver এর একটি ঐচ্ছিক ইন্টিগ্রেশনও অফার করে, যা আপনাকে খুব দক্ষ দৃশ্যমানতা লুকআপ দেয়।
এই পরিবর্তনের পর আমাদের ছবিগুলি চাহিদা অনুযায়ী আনা হচ্ছে। আপনি যদি সেই বিষয়টি আরও গভীরভাবে জানতে চান, তাহলে images.guide দেখুন - এটি একটি খুব সহজ এবং ব্যাপক উৎস।
ব্রাউজারকে গুরুত্বপূর্ণ রিসোর্সগুলি তাড়াতাড়ি সরবরাহ করতে সাহায্য করুন
ব্রাউজারে পাঠানো প্রতিটি বাইট একই মাত্রার গুরুত্বপূর্ণ নয়, এবং ব্রাউজার এটি জানে। অনেক ব্রাউজারের হিউরিস্টিক থাকে যা তারা প্রথমে কী আনবে তা নির্ধারণ করে। তাই কখনও কখনও তারা ছবি বা স্ক্রিপ্টের আগে CSS আনবে।
পৃষ্ঠার লেখক হিসেবে, আমাদের জন্য আসলে কী গুরুত্বপূর্ণ তা ব্রাউজারকে জানানো আমাদের জন্য কার্যকর হতে পারে। সৌভাগ্যক্রমে, গত কয়েক বছর ধরে ব্রাউজার বিক্রেতারা এই ক্ষেত্রে আমাদের সাহায্য করার জন্য বেশ কয়েকটি বৈশিষ্ট্য যুক্ত করছেন, যেমন link rel=preconnect , অথবা preload অথবা prefetch মতো রিসোর্স ইঙ্গিত ।
ওয়েব প্ল্যাটফর্মে আনা এই ক্ষমতাগুলি ব্রাউজারকে সঠিক সময়ে সঠিক জিনিসটি আনতে সাহায্য করে এবং এগুলি স্ক্রিপ্ট ব্যবহার করে করা কিছু কাস্টম লোডিং, লজিক-ভিত্তিক পদ্ধতির তুলনায় কিছুটা বেশি দক্ষ হতে পারে।
আসুন দেখি কিভাবে লাইটহাউস আমাদের এই বৈশিষ্ট্যগুলির কিছু কার্যকরভাবে ব্যবহারের দিকে পরিচালিত করে।
লাইটহাউস আমাদের প্রথমেই যে কাজটি করতে বলে তা হল যেকোনো স্থানে একাধিক ব্যয়বহুল ভ্রমণ এড়িয়ে চলা।
Oodle অ্যাপের ক্ষেত্রে, আমরা আসলে Google Fonts ব্যবহার করি। যখনই আপনি আপনার পৃষ্ঠায় একটি Google Font স্টাইলশিট রাখবেন তখন এটি দুটি সাবডোমেনে সংযুক্ত হবে। এবং Lighthouse আমাদের যা বলছে তা হল যে যদি আমরা সেই সংযোগটি উষ্ণ করতে সক্ষম হই, তাহলে আমরা আমাদের প্রাথমিক সংযোগের সময় 300 মিলিসেকেন্ড পর্যন্ত সাশ্রয় করতে পারব।
লিংক রিল প্রি-কানেক্টের সুবিধা গ্রহণ করে, আমরা কার্যকরভাবে সংযোগের বিলম্বিতা মাস্ক করতে পারি।
বিশেষ করে গুগল ফন্টের মতো কিছুর ক্ষেত্রে যেখানে আমাদের ফন্ট ফেস সিএসএস googleapis.com এ হোস্ট করা হয় এবং আমাদের ফন্ট রিসোর্সগুলি Gstatic এ হোস্ট করা হয়, এটি সত্যিই বড় প্রভাব ফেলতে পারে। তাই আমরা এই অপ্টিমাইজেশনটি প্রয়োগ করেছি এবং কয়েকশ মিলিসেকেন্ড কমিয়েছি।
লাইটহাউস পরবর্তী যে জিনিসটির পরামর্শ দেয় তা হল আমরা মূল অনুরোধগুলি প্রিলোড করি।
<link rel=preload> সত্যিই শক্তিশালী, এটি ব্রাউজারকে জানায় যে বর্তমান নেভিগেশনের অংশ হিসেবে একটি রিসোর্স প্রয়োজন, এবং এটি ব্রাউজারকে যত তাড়াতাড়ি সম্ভব এটি আনতে চেষ্টা করে।
এখন এখানে লাইটহাউস আমাদের বলছে যে আমাদের মূল ওয়েব ফন্ট রিসোর্সগুলি প্রিলোড করা উচিত, কারণ আমরা দুটি ওয়েব ফন্ট লোড করছি।
একটি ওয়েব ফন্টে প্রিলোডিং এইরকম দেখায় - rel=preload উল্লেখ করলে, আপনি ফন্টের ধরণের as পাস করেন এবং তারপরে আপনি যে ধরণের ফন্ট লোড করার চেষ্টা করছেন তা নির্দিষ্ট করেন, যেমন woff2।
এর প্রভাব আপনার পৃষ্ঠায় বেশ তীব্র হতে পারে।
সাধারণত, লিঙ্ক রিল প্রিলোড ব্যবহার না করে, যদি ওয়েব ফন্টগুলি আপনার পৃষ্ঠার জন্য গুরুত্বপূর্ণ হয়ে ওঠে, তাহলে ব্রাউজারকে প্রথমে আপনার HTML আনতে হবে, আপনার CSS বিশ্লেষণ করতে হবে, এবং অনেক পরে, এটি অবশেষে আপনার ওয়েব ফন্টগুলি আনতে হবে।
লিঙ্ক রিল প্রিলোড ব্যবহার করে, ব্রাউজারটি আপনার HTML পার্স করার সাথে সাথেই এটি আসলে অনেক আগেই সেই ওয়েব ফন্টগুলি আনতে শুরু করতে পারে। আমাদের অ্যাপের ক্ষেত্রে, এটি আমাদের ওয়েব ফন্ট ব্যবহার করে টেক্সট রেন্ডার করতে যে সময় নেয় তা এক সেকেন্ড কমিয়ে আনতে সক্ষম হয়েছে।
এখন যদি আপনি গুগল ফন্ট ব্যবহার করে ফন্ট প্রিলোড করার চেষ্টা করতে চান, তাহলে এটা খুব একটা সহজ নয়, একটা সমস্যা আছে।
আমাদের স্টাইলশিটে ফন্ট ফেসে আমরা যে গুগল ফন্ট ইউআরএলগুলি নির্দিষ্ট করি তা হয়ে থাকে যা ফন্ট টিম নিয়মিত আপডেট করে। এই ইউআরএলগুলির মেয়াদ শেষ হতে পারে, অথবা নিয়মিত ফ্রিকোয়েন্সিতে আপডেট হতে পারে, তাই আপনার ফন্ট লোডিং অভিজ্ঞতার উপর সম্পূর্ণ নিয়ন্ত্রণ চাইলে আমরা যা করার পরামর্শ দেব তা হল আপনার ওয়েব ফন্টগুলি স্ব-হোস্ট করা। এটি দুর্দান্ত হতে পারে কারণ এটি আপনাকে লিঙ্ক রিল প্রিলোডের মতো জিনিসগুলিতে অ্যাক্সেস দেয়।
আমাদের ক্ষেত্রে আমরা গুগল ওয়েব ফন্টস হেল্পার টুলটি সত্যিই কার্যকর বলে মনে করেছি যা আমাদের কিছু ওয়েব ফন্ট অফলাইনে রাখতে এবং স্থানীয়ভাবে সেট আপ করতে সাহায্য করে, তাই টুলটি পরীক্ষা করে দেখুন।
আপনি আপনার গুরুত্বপূর্ণ রিসোর্সের অংশ হিসেবে ওয়েব ফন্ট ব্যবহার করুন, অথবা জাভাস্ক্রিপ্ট, যত তাড়াতাড়ি সম্ভব ব্রাউজারকে আপনার গুরুত্বপূর্ণ রিসোর্স সরবরাহ করতে সাহায্য করার চেষ্টা করুন।
পরীক্ষামূলক: অগ্রাধিকারের ইঙ্গিত
আজ আমরা আপনাদের সাথে বিশেষ কিছু শেয়ার করতে চাই। রিসোর্স ইঙ্গিত এবং প্রিলোডের মতো বৈশিষ্ট্য ছাড়াও, আমরা একটি নতুন পরীক্ষামূলক ব্রাউজার বৈশিষ্ট্য নিয়ে কাজ করছি যাকে আমরা অগ্রাধিকার ইঙ্গিত বলছি।
এটি একটি নতুন বৈশিষ্ট্য যা আপনাকে ব্রাউজারকে একটি রিসোর্স কতটা গুরুত্বপূর্ণ তা ইঙ্গিত করার সুযোগ দেয়। এটি একটি নতুন বৈশিষ্ট্য - গুরুত্ব - প্রকাশ করে যার মান নিম্ন, উচ্চ বা স্বয়ংক্রিয়।
এর ফলে আমরা কম গুরুত্বপূর্ণ রিসোর্স, যেমন নন-ক্রিটিক্যাল স্টাইল, ইমেজ, অথবা এপিআই কলের মাধ্যমে বিতর্ক কমাতে অগ্রাধিকার কমাতে পারি। আমরা আমাদের হিরো ইমেজের মতো আরও গুরুত্বপূর্ণ জিনিসের অগ্রাধিকারও বাড়াতে পারি।
আমাদের Oodle অ্যাপের ক্ষেত্রে, এটি আসলে এমন একটি ব্যবহারিক জায়গায় নিয়ে গেছে যেখানে আমরা অপ্টিমাইজ করতে পারি।
আমাদের ছবিতে অলস লোডিং যোগ করার আগে, ব্রাউজারটি যা করছিল তা হল, আমাদের সমস্ত ডুডলের সাথে এই চিত্র ক্যারোজেলটি ছিল এবং ব্রাউজারটি ক্যারোজেলের একেবারে শুরুতেই উচ্চ অগ্রাধিকার দিয়ে সমস্ত চিত্র আনছিল। দুর্ভাগ্যবশত, ক্যারোজেলের মাঝখানের চিত্রগুলিই ব্যবহারকারীর কাছে সবচেয়ে গুরুত্বপূর্ণ ছিল। তাই আমরা যা করেছি তা হল, আমরা সেই ব্যাকগ্রাউন্ড চিত্রগুলির গুরুত্ব খুব কম, অগ্রভাগের চিত্রগুলি খুব বেশি এবং এর ফলে ধীর 3G-তে দুই সেকেন্ডের প্রভাব এবং আমরা কত দ্রুত সেই চিত্রগুলি আনতে এবং রেন্ডার করতে সক্ষম হয়েছি তা নির্ধারণ করেছি। তাই একটি চমৎকার ইতিবাচক অভিজ্ঞতা।
আমরা আশা করছি কয়েক সপ্তাহের মধ্যে ক্যানারিতে এই বৈশিষ্ট্যটি নিয়ে আসব, তাই এটির দিকে নজর রাখুন।
একটি ওয়েব ফন্ট লোডিং কৌশল রাখুন
ভালো ডিজাইনের জন্য টাইপোগ্রাফি মৌলিক, এবং আপনি যদি ওয়েব ফন্ট ব্যবহার করেন তবে আদর্শভাবে আপনার লেখার রেন্ডারিং ব্লক করতে চাইবেন না এবং আপনি অবশ্যই অদৃশ্য লেখা দেখাতে চাইবেন না।
আমরা এখন Lighthouse-এ এটি হাইলাইট করব, ওয়েব ফন্ট লোড হওয়ার সময় অদৃশ্য টেক্সট এড়িয়ে চলুন অডিট সহ।
যদি আপনি আপনার ওয়েব ফন্টগুলি একটি ফন্ট ফেস ব্লক ব্যবহার করে লোড করেন, তাহলে আপনি ব্রাউজারকে সিদ্ধান্ত নিতে দিচ্ছেন যে ওয়েব ফন্টটি আনতে যদি দীর্ঘ সময় লাগে তবে কী করতে হবে। কিছু ব্রাউজার সিস্টেম ফন্টে ফিরে যাওয়ার আগে এটির জন্য তিন সেকেন্ড পর্যন্ত অপেক্ষা করে এবং ডাউনলোড হয়ে গেলে তারা অবশেষে এটিকে ফন্টে স্যুইপ করে।
আমরা এই অদৃশ্য লেখাটি এড়াতে চেষ্টা করছি, তাই এই ক্ষেত্রে যদি ওয়েব ফন্টটি খুব বেশি সময় নিত তাহলে আমরা এই সপ্তাহের ক্লাসিক ডুডলগুলি দেখতে পারতাম না। সৌভাগ্যক্রমে, font-display নামক একটি নতুন বৈশিষ্ট্যের সাহায্যে, আপনি আসলে এই প্রক্রিয়াটির উপর অনেক বেশি নিয়ন্ত্রণ পাবেন।
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-display: swap;
font-weight: 400;
src: local('Montserrat Regular'), local('Montserrat-Regular'),
/* Chrome 26+, Opera 23+, Firefox 39+ */
url('montserrat-v12-latin-regular.woff2') format('woff2'),
/* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
url('montserrat-v12-latin-regular.woff') format('woff');
}
ফন্ট ডিসপ্লে আপনাকে ওয়েব ফন্টগুলি কীভাবে রেন্ডার করবে বা ফলব্যাক করবে তা নির্ধারণ করতে সাহায্য করে, সেগুলি অদলবদল করতে কত সময় লাগে তার উপর ভিত্তি করে।
এই ক্ষেত্রে আমরা ফন্ট ডিসপ্লে সোয়াপ ব্যবহার করছি। সোয়াপ ফন্ট ফেসকে শূন্য সেকেন্ড ব্লক পিরিয়ড এবং অসীম সোয়াপ পিরিয়ড দেয়। এর অর্থ হল, যদি ফন্টটি লোড হতে কিছুটা সময় নেয়, তাহলে ব্রাউজারটি আপনার লেখাটি খুব তাৎক্ষণিকভাবে একটি ফলব্যাক ফন্ট দিয়ে আঁকবে। এবং ফন্ট ফেসটি উপলব্ধ হলে এটি সোয়াপ করবে।
আমাদের অ্যাপের ক্ষেত্রে, এটি কেন দুর্দান্ত ছিল তা হল এটি আমাদের খুব শুরুতেই কিছু অর্থপূর্ণ টেক্সট প্রদর্শন করতে এবং এটি প্রস্তুত হয়ে গেলে ওয়েব ফন্টে স্থানান্তর করতে সাহায্য করেছিল।
সাধারণভাবে, যদি আপনি ওয়েব ফন্ট ব্যবহার করেন, যেমনটি ওয়েবের একটি বৃহৎ শতাংশ ব্যবহার করে, তাহলে একটি ভালো ওয়েব ফন্ট লোডিং কৌশল তৈরি করুন।
ফন্ট লোড করার অভিজ্ঞতা অপ্টিমাইজ করার জন্য আপনি অনেক ওয়েব প্ল্যাটফর্ম বৈশিষ্ট্য ব্যবহার করতে পারেন, তবে জ্যাক লেদারম্যানের ওয়েব ফন্ট রেসিপি রেপোও দেখুন, কারণ এটি সত্যিই দুর্দান্ত।
রেন্ডার-ব্লকিং স্ক্রিপ্ট কমানো
আমাদের অ্যাপ্লিকেশনের আরও কিছু অংশ আছে যেগুলো ডাউনলোড চেইনে আমরা আরও আগে যোগ করতে পারি যাতে অন্তত কিছু মৌলিক ব্যবহারকারীর অভিজ্ঞতা একটু আগে দেওয়া যায়।
লাইটহাউস টাইমলাইন স্ট্রিপে আপনি দেখতে পাবেন যে এই প্রথম কয়েক সেকেন্ডের মধ্যে যখন সমস্ত রিসোর্স লোড হচ্ছে, ব্যবহারকারী আসলে কোনও কন্টেন্ট দেখতে পাচ্ছেন না।
বহিরাগত স্টাইলশিট ডাউনলোড এবং প্রক্রিয়াকরণ আমাদের রেন্ডারিং প্রক্রিয়ার অগ্রগতিতে বাধা সৃষ্টি করছে।
আমরা কিছু স্টাইল একটু আগে ডেলিভারি করে আমাদের সমালোচনামূলক রেন্ডারিং পাথকে অপ্টিমাইজ করার চেষ্টা করতে পারি।
যদি আমরা এই প্রাথমিক রেন্ডারের জন্য দায়ী স্টাইলগুলি বের করে আমাদের HTML-এ ইনলাইন করি, তাহলে ব্রাউজারটি বহিরাগত স্টাইলশিটগুলি আসার জন্য অপেক্ষা না করেই সরাসরি সেগুলি রেন্ডার করতে সক্ষম হবে।
আমাদের ক্ষেত্রে, আমরা একটি বিল্ড ধাপের সময় index.html-এ আমাদের গুরুত্বপূর্ণ বিষয়বস্তু ইনলাইন করার জন্য Critical নামক একটি NPM মডিউল ব্যবহার করেছি।
যদিও এই মডিউলটি আমাদের জন্য বেশিরভাগ ভারী জিনিসপত্র উত্তোলনের কাজটি করেছে, তবুও বিভিন্ন রুটে এটিকে সুচারুভাবে কাজ করা একটু কঠিন ছিল।
যদি আপনি সতর্ক না হন অথবা আপনার সাইটের কাঠামো সত্যিই জটিল হয়, তাহলে শুরু থেকেই অ্যাপ শেল আর্কিটেকচারের পরিকল্পনা না করলে এই ধরণের প্যাটার্ন প্রবর্তন করা সত্যিই কঠিন হতে পারে।
এই কারণেই শুরু থেকেই পারফরম্যান্স বিবেচনা করা খুবই গুরুত্বপূর্ণ। যদি আপনি শুরু থেকেই পারফরম্যান্সের জন্য ডিজাইন না করেন, তাহলে পরবর্তীতে এটি করতে গিয়ে সমস্যার সম্মুখীন হওয়ার সম্ভাবনা বেশি।
শেষ পর্যন্ত আমাদের ঝুঁকি সফল হয়েছে, আমরা এটি কার্যকর করতে সক্ষম হয়েছি এবং অ্যাপটি অনেক আগেই কন্টেন্ট সরবরাহ করা শুরু করেছে, আমাদের প্রথম অর্থপূর্ণ রঙ করার সময় উল্লেখযোগ্যভাবে উন্নত করেছে।
ফলাফল
আমাদের সাইটে আমরা যে পারফর্ম্যান্স অপ্টিমাইজেশন পদ্ধতি প্রয়োগ করেছি তার তালিকা ছিল দীর্ঘ। আসুন ফলাফলটি একবার দেখে নেওয়া যাক। অপ্টিমাইজেশনের আগে এবং পরে, 3G নেটওয়ার্কের একটি মাঝারি মোবাইল ডিভাইসে আমাদের অ্যাপটি এভাবেই লোড হয়েছিল।
লাইটহাউসের পারফরম্যান্স স্কোর ২৩ থেকে ৯১-এ উন্নীত হয়েছে। গতির দিক থেকে এটি বেশ ভালো অগ্রগতি। লাইটহাউস রিপোর্টটি ক্রমাগত পরীক্ষা এবং অনুসরণ করার মাধ্যমে সমস্ত পরিবর্তনগুলি ইন্ধন জোগায়। আপনি যদি দেখতে চান যে আমরা কীভাবে সমস্ত উন্নতি প্রযুক্তিগতভাবে বাস্তবায়ন করেছি, তাহলে আমাদের রেপো , বিশেষ করে সেখানে পৌঁছানো পিআরগুলিতে একবার দেখে নিতে দ্বিধা করবেন না।
ভবিষ্যদ্বাণীমূলক কর্মক্ষমতা - ডেটা-চালিত ব্যবহারকারীর অভিজ্ঞতা
আমরা বিশ্বাস করি যে মেশিন লার্নিং ভবিষ্যতের জন্য অনেক ক্ষেত্রেই একটি উত্তেজনাপূর্ণ সুযোগের প্রতিনিধিত্ব করে। ভবিষ্যতে আরও পরীক্ষা-নিরীক্ষার সূত্রপাত করবে বলে আমরা আশা করি, বাস্তব তথ্য আমাদের তৈরি করা ব্যবহারকারীর অভিজ্ঞতাকে সত্যিই পরিচালিত করতে পারে।
আজকাল, ব্যবহারকারী কী চাইবে বা কী প্রয়োজন, এবং কোনটি আগে থেকে আনা, প্রিলোড করা, অথবা আগে থেকে ক্যাশে করা মূল্যবান, সে সম্পর্কে আমরা অনেক ইচ্ছামত সিদ্ধান্ত নিই। যদি আমরা সঠিক অনুমান করি তবে আমরা অল্প পরিমাণে রিসোর্সকে অগ্রাধিকার দিতে সক্ষম হব, কিন্তু পুরো ওয়েবসাইটে এটি স্কেল করা সত্যিই কঠিন।
আমাদের কাছে আজ আমাদের অপ্টিমাইজেশনগুলিকে আরও ভালভাবে জানাতে ডেটা উপলব্ধ রয়েছে। গুগল অ্যানালিটিক্স রিপোর্টিং এপিআই ব্যবহার করে আমরা পরবর্তী শীর্ষ পৃষ্ঠাটি দেখে নিতে পারি এবং আমাদের সাইটের যেকোনো URL এর জন্য প্রস্থান শতাংশ দেখতে পারি এবং তাই কোন সংস্থানগুলিকে আমাদের অগ্রাধিকার দেওয়া উচিত সে সম্পর্কে সিদ্ধান্তে পৌঁছাতে পারি।
যদি আমরা এটিকে একটি ভালো সম্ভাব্যতা মডেলের সাথে একত্রিত করি, তাহলে আমরা আক্রমণাত্মকভাবে অতিরিক্ত প্রিফেচিং কন্টেন্টের মাধ্যমে আমাদের ব্যবহারকারীর ডেটা নষ্ট করা এড়াতে পারি। আমরা সেই গুগল অ্যানালিটিক্স ডেটার সুবিধা নিতে পারি এবং এই ধরনের মডেল বাস্তবায়নের জন্য মেশিন লার্নিং এবং মার্কভ চেইন বা নিউরাল নেটওয়ার্কের মতো মডেল ব্যবহার করতে পারি।
এই পরীক্ষা-নিরীক্ষা সহজতর করার জন্য, আমরা আনন্দের সাথে Guess.js নামে একটি নতুন উদ্যোগ ঘোষণা করছি।
Guess.js হলো ওয়েবের জন্য ডেটা-চালিত ব্যবহারকারীর অভিজ্ঞতার উপর দৃষ্টি নিবদ্ধ করে তৈরি একটি প্রকল্প। আমরা আশা করি এটি ওয়েব কর্মক্ষমতা উন্নত করতে এবং এর বাইরেও ডেটা ব্যবহারের অন্বেষণকে অনুপ্রাণিত করবে। এটি সম্পূর্ণ ওপেন সোর্স এবং আজ GitHub-এ উপলব্ধ। এটি মিনকো গেচেভ, গ্যাটসবির কাইল ম্যাথিউস, কেটি হেম্পেনিয়াস এবং আরও অনেকের দ্বারা ওপেন সোর্স সম্প্রদায়ের সহযোগিতায় তৈরি করা হয়েছে।
Guess.js দেখুন, আপনার মতামত আমাদের জানান।
সারাংশ
স্কোর এবং মেট্রিক্স ওয়েবের গতি উন্নত করতে সহায়ক, কিন্তু এগুলি কেবল উপায়, লক্ষ্য নয়।
আমরা সকলেই চলার পথে ধীর গতিতে পৃষ্ঠা লোড হওয়ার অভিজ্ঞতা পেয়েছি, কিন্তু এখন আমাদের ব্যবহারকারীদের আরও আনন্দদায়ক অভিজ্ঞতা দেওয়ার সুযোগ রয়েছে যা সত্যিই দ্রুত লোড হয়।
কর্মক্ষমতা উন্নত করা একটি যাত্রা। অনেক ছোট পরিবর্তনই বড় লাভের দিকে নিয়ে যেতে পারে। সঠিক অপ্টিমাইজেশন টুল ব্যবহার করে এবং লাইটহাউস রিপোর্টের উপর নজর রেখে, আপনি আপনার ব্যবহারকারীদের আরও ভালো এবং আরও অন্তর্ভুক্তিমূলক অভিজ্ঞতা প্রদান করতে পারেন।
বিশেষ ধন্যবাদ: ওয়ার্ড পিটার্স, মিনকো গেচেভ, কাইল ম্যাথিউস, কেটি হেম্পেনিয়াস, ডম ফারোলিনো, ইয়াভ ওয়েইস, সুসি লু, ইউসুকে উতসুনোমিয়া, টম অ্যাঙ্কার্স, লাইটহাউস এবং গুগল ডুডলস।