কী পাঠানো হয়েছিল, কীভাবে প্রভাব পরিমাপ করা হয়েছিল এবং কী কী লেনদেন করা হয়েছিল তার গল্প।
প্রকাশিত: ২০ জুন, ২০১৯
গুগলে যেকোনো বিষয় অনুসন্ধান করুন, এবং আপনার সামনে অর্থপূর্ণ, প্রাসঙ্গিক ফলাফলের একটি তাৎক্ষণিকভাবে স্বীকৃত পৃষ্ঠা উপস্থিত হবে। আপনি সম্ভবত যা বুঝতে পারেননি তা হল, এই অনুসন্ধান ফলাফল পৃষ্ঠাটি, কিছু পরিস্থিতিতে, একটি শক্তিশালী ওয়েব প্রযুক্তি দ্বারা পরিবেশিত হয় যাকে বলা হয় একজন পরিষেবা কর্মী ।
কর্মক্ষমতার উপর নেতিবাচক প্রভাব না ফেলেই গুগল সার্চের জন্য পরিষেবা কর্মীদের সহায়তা চালু করার জন্য একাধিক দলে কয়েক ডজন ইঞ্জিনিয়ারের কাজ করতে হয়েছিল। এটি কী পাঠানো হয়েছিল, কীভাবে কর্মক্ষমতা পরিমাপ করা হয়েছিল এবং কী বিনিময় করা হয়েছিল তার গল্প।
পরিষেবা কর্মীদের অন্বেষণের মূল কারণগুলি
আপনার সাইটে যেকোনো স্থাপত্য পরিবর্তনের মতোই, একটি ওয়েব অ্যাপে একজন পরিষেবা কর্মী যোগ করার ক্ষেত্রেও একটি স্পষ্ট লক্ষ্য মাথায় রাখা উচিত। গুগল সার্চ টিমের জন্য, একজন পরিষেবা কর্মী যোগ করার কয়েকটি মূল কারণ অনুসন্ধান করা মূল্যবান ছিল।
সীমিত সার্চ ফলাফল ক্যাশিং
গুগল সার্চ টিম দেখেছে যে ব্যবহারকারীদের জন্য অল্প সময়ের মধ্যে একই শব্দ একাধিকবার অনুসন্ধান করা সাধারণ। একই ফলাফল পাওয়ার জন্য একটি নতুন ব্যাকএন্ড অনুরোধ ট্রিগার করার পরিবর্তে, সার্চ টিম ক্যাশিংয়ের সুবিধা নিতে এবং স্থানীয়ভাবে সেই পুনরাবৃত্তি অনুরোধগুলি পূরণ করতে চেয়েছিল।
সতেজতার গুরুত্বকে অস্বীকার করা যায় না, এবং কখনও কখনও ব্যবহারকারীরা একই শব্দ বারবার অনুসন্ধান করেন কারণ এটি একটি ক্রমবর্ধমান বিষয়, এবং তারা নতুন ফলাফল দেখতে আশা করে। একজন পরিষেবা কর্মী ব্যবহার করে অনুসন্ধান দল স্থানীয়ভাবে ক্যাশে করা অনুসন্ধান ফলাফলের জীবনকাল নিয়ন্ত্রণ করার জন্য সূক্ষ্ম যুক্তি প্রয়োগ করতে এবং গতি বনাম সতেজতার সঠিক ভারসাম্য অর্জন করতে সক্ষম হয় যা তারা বিশ্বাস করে যে ব্যবহারকারীদের সর্বোত্তম পরিষেবা দেয়।
অর্থপূর্ণ অফলাইন অভিজ্ঞতা
উপরন্তু, গুগল সার্চ টিম একটি অর্থবহ অফলাইন অভিজ্ঞতা প্রদান করতে চেয়েছিল। যখন কোনও ব্যবহারকারী কোনও বিষয় সম্পর্কে জানতে চান, তখন তারা সরাসরি গুগল সার্চ পৃষ্ঠায় যেতে চান এবং অনুসন্ধান শুরু করতে চান, সক্রিয় ইন্টারনেট সংযোগের বিষয়ে চিন্তা না করে।
কোনও পরিষেবা কর্মী ছাড়া, অফলাইনে থাকাকালীন গুগল অনুসন্ধান পৃষ্ঠায় গেলে কেবল ব্রাউজারের স্ট্যান্ডার্ড নেটওয়ার্ক ত্রুটি পৃষ্ঠায় চলে যাবে এবং ব্যবহারকারীদের তাদের সংযোগ ফিরে আসার পরে আবার চেষ্টা করতে হবে। একজন পরিষেবা কর্মীর সাহায্যে, একটি কাস্টম অফলাইন HTML প্রতিক্রিয়া পরিবেশন করা সম্ভব এবং ব্যবহারকারীদের তাৎক্ষণিকভাবে তাদের অনুসন্ধান অনুসন্ধান প্রবেশ করার অনুমতি দেওয়া সম্ভব।
ইন্টারনেট সংযোগ না থাকা পর্যন্ত ফলাফল পাওয়া যাবে না, তবে পরিষেবা কর্মী ব্যাকগ্রাউন্ড সিঙ্ক API ব্যবহার করে ডিভাইসটি আবার অনলাইনে ফিরে আসার সাথে সাথে অনুসন্ধানটি পিছিয়ে দেওয়ার এবং Google এর সার্ভারে পাঠানোর অনুমতি দেয়।
আরও স্মার্ট জাভাস্ক্রিপ্ট ক্যাশিং এবং পরিবেশন
আরেকটি অনুপ্রেরণা ছিল মডুলারাইজড জাভাস্ক্রিপ্ট কোডের ক্যাশিং এবং লোডিং অপ্টিমাইজ করা যা অনুসন্ধান ফলাফল পৃষ্ঠায় বিভিন্ন ধরণের বৈশিষ্ট্যগুলিকে শক্তিশালী করে। জাভাস্ক্রিপ্ট বান্ডলিং দ্বারা প্রদত্ত বেশ কয়েকটি সুবিধা রয়েছে যা কোনও পরিষেবা কর্মীর জড়িত না থাকলে তা বোধগম্য হয়, তাই অনুসন্ধান দলটি কেবল সম্পূর্ণরূপে বান্ডলিং বন্ধ করতে চায়নি।
রানটাইমে জাভাস্ক্রিপ্টের সূক্ষ্ম অংশগুলিকে সংস্করণ এবং ক্যাশে করার জন্য একজন পরিষেবা কর্মীর ক্ষমতা ব্যবহার করে, অনুসন্ধান দল সন্দেহ করেছিল যে তারা ক্যাশে চার্নের পরিমাণ কমাতে পারে এবং ভবিষ্যতে পুনঃব্যবহৃত জাভাস্ক্রিপ্ট দক্ষতার সাথে ক্যাশে করা যায় তা নিশ্চিত করতে পারে। তাদের পরিষেবা কর্মীর অভ্যন্তরীণ যুক্তি একাধিক জাভাস্ক্রিপ্ট মডিউল ধারণকারী একটি বান্ডেলের জন্য একটি বহির্গামী HTTP অনুরোধ বিশ্লেষণ করতে পারে এবং একাধিক, স্থানীয়ভাবে ক্যাশে করা মডিউলগুলিকে একত্রিত করে এটি পূরণ করতে পারে - যখন সম্ভব কার্যকরভাবে "আনবান্ডলিং" করে। এটি ব্যবহারকারীর ব্যান্ডউইথ সংরক্ষণ করে এবং সামগ্রিক প্রতিক্রিয়াশীলতা উন্নত করে।
একজন পরিষেবা কর্মী দ্বারা পরিবেশিত ক্যাশেড জাভাস্ক্রিপ্ট ব্যবহারের পারফরম্যান্স সুবিধাও রয়েছে: ক্রোমে, সেই জাভাস্ক্রিপ্টের একটি পার্সড, বাইট কোড উপস্থাপনা সংরক্ষণ করা হয় এবং পুনরায় ব্যবহার করা হয়, যার ফলে পৃষ্ঠায় জাভাস্ক্রিপ্ট চালানোর জন্য রানটাইমে কম কাজ করতে হয়।
চ্যালেঞ্জ এবং সমাধান
দলের ঘোষিত লক্ষ্য অর্জনের জন্য যেসব বাধা অতিক্রম করতে হবে তার কয়েকটি এখানে দেওয়া হল। যদিও এই চ্যালেঞ্জগুলির মধ্যে কিছু নির্দিষ্ট গুগল সার্চের জন্য, তবে এর মধ্যে অনেকগুলি বিস্তৃত পরিসরের সাইটের জন্য প্রযোজ্য যেখানে পরিষেবা কর্মী মোতায়েনের কথা বিবেচনা করা হতে পারে।
সমস্যা: পরিষেবা কর্মীর ওভারহেড
গুগল সার্চে কোনও পরিষেবা কর্মী চালু করার ক্ষেত্রে সবচেয়ে বড় চ্যালেঞ্জ এবং একমাত্র আসল বাধা ছিল, এটি নিশ্চিত করা যে এটি এমন কিছু করে না যা ব্যবহারকারী-অনুভূত ল্যাটেন্সি বৃদ্ধি করতে পারে। গুগল সার্চ পারফরম্যান্সকে খুব গুরুত্ব সহকারে নেয় এবং অতীতে, কোনও নির্দিষ্ট ব্যবহারকারীর জন্য দশ মিলিসেকেন্ড অতিরিক্ত ল্যাটেন্সি অবদান রাখলে নতুন কার্যকারিতা চালু করা ব্লক করেছে।
যখন দলটি তাদের প্রাথমিক পরীক্ষাগুলির সময় পারফরম্যান্স ডেটা সংগ্রহ করা শুরু করে, তখন স্পষ্ট হয়ে ওঠে যে কোনও সমস্যা হবে। অনুসন্ধান ফলাফল পৃষ্ঠার জন্য নেভিগেশন অনুরোধের প্রতিক্রিয়ায় ফিরে আসা HTML গতিশীল, এবং অনুসন্ধানের ওয়েব সার্ভারগুলিতে চালানোর জন্য প্রয়োজনীয় লজিকের উপর নির্ভর করে ব্যাপকভাবে পরিবর্তিত হয়। বর্তমানে পরিষেবা কর্মীর পক্ষে এই লজিকটি প্রতিলিপি করা এবং তাৎক্ষণিকভাবে ক্যাশে করা HTML ফেরত দেওয়ার কোনও উপায় নেই - এটি সবচেয়ে ভালভাবে করতে পারে তা হল ব্যাকএন্ড ওয়েব সার্ভারগুলিতে নেভিগেশন অনুরোধগুলি প্রেরণ করা, যার জন্য একটি নেটওয়ার্ক অনুরোধের প্রয়োজন হয়।
কোনও পরিষেবা কর্মী ছাড়া, ব্যবহারকারীর নেভিগেশনের সাথে সাথেই এই নেটওয়ার্ক অনুরোধটি ঘটে। যখন কোনও পরিষেবা কর্মী নিবন্ধিত হয়, তখন এটি সর্বদা শুরু করতে হবে এবং এর fetch ইভেন্ট হ্যান্ডলারগুলি কার্যকর করার সুযোগ দিতে হবে, এমনকি যখন সেই ফেচ হ্যান্ডলারগুলি নেটওয়ার্কে যাওয়া ছাড়া অন্য কিছু করার কোনও সম্ভাবনা থাকে না। পরিষেবা কর্মী কোডটি শুরু করতে এবং চালাতে যে পরিমাণ সময় লাগে তা প্রতিটি নেভিগেশনের উপরে অতিরিক্তভাবে যোগ করা হয়:
এর ফলে সার্ভিস ওয়ার্কার বাস্তবায়নে অন্য কোনও সুবিধার ন্যায্যতা প্রমাণ করার জন্য অত্যধিক লেটেন্সি অসুবিধা দেখা দেয়। উপরন্তু, দলটি দেখেছে যে, বাস্তব-বিশ্বের ডিভাইসগুলিতে সার্ভিস ওয়ার্কার বুট টাইম পরিমাপের উপর ভিত্তি করে, স্টার্টআপ সময়ের বিস্তৃত বন্টন ছিল, কিছু নিম্নমানের মোবাইল ডিভাইস পরিষেবা কর্মীকে শুরু করতে প্রায় ততটাই সময় নেয় যতটা ফলাফল পৃষ্ঠার HTML-এর জন্য নেটওয়ার্ক অনুরোধ করতে লাগে।
সমাধান: নেভিগেশন প্রিলোড ব্যবহার করুন
গুগল সার্চ টিমকে তাদের সার্ভিস ওয়ার্কার লঞ্চের সাথে এগিয়ে যাওয়ার জন্য সবচেয়ে গুরুত্বপূর্ণ যে বৈশিষ্ট্যটি ব্যবহার করা হয়েছিল তা হল নেভিগেশন প্রিলোড । নেভিগেশন প্রিলোড ব্যবহার করা যেকোনো সার্ভিস কর্মীর জন্য একটি গুরুত্বপূর্ণ পারফরম্যান্স জয়, যাদের নেভিগেশন অনুরোধগুলি পূরণ করার জন্য নেটওয়ার্ক থেকে প্রতিক্রিয়া ব্যবহার করতে হয়। এটি ব্রাউজারকে একটি ইঙ্গিত প্রদান করে যাতে পরিষেবা কর্মী শুরু করার সাথে সাথেই তাৎক্ষণিকভাবে নেভিগেশন অনুরোধ করা শুরু করা যায়:
যতক্ষণ পর্যন্ত পরিষেবা কর্মীর শুরু হতে যে পরিমাণ সময় লাগে, নেটওয়ার্ক থেকে প্রতিক্রিয়া পেতে যে পরিমাণ সময় লাগে তার চেয়ে কম, ততক্ষণ পর্যন্ত পরিষেবা কর্মীর দ্বারা কোনও বিলম্বিত ওভারহেড প্রবর্তন করা উচিত নয়।
সার্চ টিমকে এমন লো-এন্ড মোবাইল ডিভাইসে সার্ভিস ওয়ার্কার ব্যবহার করা এড়িয়ে চলতে হবে যেখানে সার্ভিস ওয়ার্কারের বুট টাইম নেভিগেশন রিকোয়েস্টের চেয়ে বেশি হতে পারে। যেহেতু "লো-এন্ড" ডিভাইস কী তা বোঝার জন্য কোনও কঠোর নিয়ম নেই, তাই তারা ডিভাইসে ইনস্টল করা মোট RAM পরীক্ষা করার হিউরিস্টিক পদ্ধতি নিয়ে এসেছিল। 2 গিগাবাইটের কম মেমরি তাদের লো-এন্ড ডিভাইস বিভাগে পড়ে, যেখানে সার্ভিস ওয়ার্কারের স্টার্টআপ সময় অগ্রহণযোগ্য হবে।
উপলব্ধ স্টোরেজ স্পেস আরেকটি বিবেচ্য বিষয়, কারণ ভবিষ্যতে ব্যবহারের জন্য ক্যাশে করা সম্পূর্ণ রিসোর্সগুলি বেশ কয়েক মেগাবাইট পর্যন্ত চলতে পারে। navigator.storage ইন্টারফেস Google অনুসন্ধান পৃষ্ঠাকে আগে থেকেই নির্ধারণ করতে দেয় যে ডেটা ক্যাশে করার তাদের প্রচেষ্টা স্টোরেজ কোটা ব্যর্থতার কারণে ব্যর্থ হওয়ার ঝুঁকি চালায় কিনা।
এর ফলে সার্চ টিমের কাছে একাধিক মানদণ্ড রয়েছে যা তারা কোনও পরিষেবা কর্মী ব্যবহার করবেন কিনা তা নির্ধারণ করতে ব্যবহার করতে পারে: যদি কোনও ব্যবহারকারী এমন একটি ব্রাউজার ব্যবহার করে গুগল সার্চ পৃষ্ঠায় আসেন যা নেভিগেশন প্রিলোড সমর্থন করে এবং কমপক্ষে 2 গিগাবাইট র্যাম এবং পর্যাপ্ত ফ্রি স্টোরেজ স্পেস থাকে, তাহলে একজন পরিষেবা কর্মী নিবন্ধিত হন । যেসব ব্রাউজার বা ডিভাইস এই মানদণ্ড পূরণ করে না, তারা কোনও পরিষেবা কর্মীর সাথে শেষ পর্যন্ত মিলবে না, তবে তারা এখনও আগের মতোই গুগল সার্চ অভিজ্ঞতা দেখতে পাবে।
এই নির্বাচনী নিবন্ধনের একটি পার্শ্ব সুবিধা হল ছোট, আরও দক্ষ পরিষেবা কর্মী পাঠানোর ক্ষমতা। পরিষেবা কর্মী কোড চালানোর জন্য মোটামুটি আধুনিক ব্রাউজারগুলিকে লক্ষ্য করে পুরানো ব্রাউজারগুলির জন্য ট্রান্সপিলেশন এবং পলিফিলের ওভারহেড দূর করে। এর ফলে পরিষেবা কর্মীর বাস্তবায়নের মোট আকার থেকে প্রায় 8 কিলোবাইট আনকম্প্রেসড জাভাস্ক্রিপ্ট কোড কেটে ফেলা হয়েছে।
সমস্যা: পরিষেবা কর্মীর সুযোগ
সার্চ টিম যখন পর্যাপ্ত ল্যাটেন্সি পরীক্ষা-নিরীক্ষা চালায় এবং নিশ্চিত হয় যে নেভিগেশন প্রিলোড ব্যবহার তাদের পরিষেবা কর্মীদের ব্যবহারের জন্য একটি কার্যকর, ল্যাটেন্সি-নিরপেক্ষ পথ প্রদান করে, তখন কিছু ব্যবহারিক সমস্যা সামনে আসতে শুরু করে। এই সমস্যাগুলির মধ্যে একটি হল পরিষেবা কর্মীর স্কোপিং নিয়মের সাথে সম্পর্কিত। একজন পরিষেবা কর্মীর স্কোপ নির্ধারণ করে যে এটি কোন পৃষ্ঠাগুলির সম্ভাব্য নিয়ন্ত্রণ নিতে পারে।
স্কোপিং URL পাথ প্রিফিক্সের উপর ভিত্তি করে কাজ করে। যে ডোমেনগুলি একটি একক ওয়েব অ্যাপ হোস্ট করে, তাদের জন্য এটি কোনও সমস্যা নয়, কারণ আপনি সাধারণত / এর সর্বাধিক সুযোগ সহ একটি পরিষেবা কর্মী ব্যবহার করেন, যা ডোমেনের অধীনে যেকোনো পৃষ্ঠার নিয়ন্ত্রণ নিতে পারে। কিন্তু Google Search এর URL কাঠামোটি একটু বেশি জটিল।
যদি পরিষেবা কর্মীকে / এর সর্বাধিক সুযোগ দেওয়া হয়, তাহলে তারা www.google.com (অথবা আঞ্চলিক সমতুল্য) এর অধীনে হোস্ট করা যেকোনো পৃষ্ঠার নিয়ন্ত্রণ নিতে সক্ষম হবে, এবং সেই ডোমেনের অধীনে এমন URL রয়েছে যার Google অনুসন্ধানের সাথে কোনও সম্পর্ক নেই। আরও যুক্তিসঙ্গত, সীমাবদ্ধ সুযোগ হবে /search , যা অন্তত অনুসন্ধান ফলাফলের সাথে সম্পূর্ণরূপে সম্পর্কিত URL গুলিকে বাদ দেবে।
দুর্ভাগ্যবশত, /search URL পাথটিও Google Search ফলাফলের বিভিন্ন ধরণের মধ্যে ভাগ করা হয়, যেখানে URL কোয়েরি প্যারামিটারগুলি নির্ধারণ করে যে কোন নির্দিষ্ট ধরণের অনুসন্ধান ফলাফল দেখানো হবে। এই ফ্লেভারগুলির মধ্যে কিছু প্রচলিত ওয়েব অনুসন্ধান ফলাফল পৃষ্ঠার থেকে সম্পূর্ণ ভিন্ন কোডবেস ব্যবহার করে। উদাহরণস্বরূপ, Image Search এবং Shopping Search উভয়ই /search URL পাথের অধীনে বিভিন্ন কোয়েরি প্যারামিটার সহ পরিবেশিত হয়, কিন্তু এই ইন্টারফেসের কোনওটিই (এখনও) তাদের নিজস্ব পরিষেবা কর্মী অভিজ্ঞতা সরবরাহ করতে প্রস্তুত ছিল না।
সমাধান: একটি প্রেরণ এবং রাউটিং কাঠামো তৈরি করুন
যদিও কিছু প্রস্তাব আছে যা URL পাথ প্রিফিক্সের চেয়ে আরও শক্তিশালী কিছুকে পরিষেবা কর্মীর স্কোপ নির্ধারণের অনুমতি দেয়, গুগল সার্চ টিম এমন একটি পরিষেবা কর্মী মোতায়েন করতে আটকে ছিল যারা তাদের নিয়ন্ত্রিত পৃষ্ঠাগুলির একটি উপসেটের জন্য কিছুই করেনি।
এই সমস্যা সমাধানের জন্য, গুগল সার্চ টিম একটি বেসপোক ডিসপ্যাচ এবং রাউটিং ফ্রেমওয়ার্ক তৈরি করেছে যা ক্লায়েন্ট পৃষ্ঠার কোয়েরি প্যারামিটারের মতো মানদণ্ড পরীক্ষা করার জন্য কনফিগার করা যেতে পারে এবং কোন নির্দিষ্ট কোড পাথটি নিচে যেতে হবে তা নির্ধারণ করতে সেগুলি ব্যবহার করতে পারে। হার্ডকোডিং নিয়মের পরিবর্তে, সিস্টেমটি নমনীয় হওয়ার জন্য তৈরি করা হয়েছিল এবং ইমেজ সার্চ এবং শপিং সার্চের মতো URL স্পেস ভাগ করে নেওয়া দলগুলিকে তাদের নিজস্ব পরিষেবা কর্মী লজিক লাইনে নামিয়ে দেওয়ার অনুমতি দেয়, যদি তারা এটি বাস্তবায়ন করার সিদ্ধান্ত নেয়।
সমস্যা: ব্যক্তিগতকৃত ফলাফল এবং মেট্রিক্স
ব্যবহারকারীরা তাদের গুগল অ্যাকাউন্ট ব্যবহার করে গুগল সার্চে সাইন ইন করতে পারেন এবং তাদের অনুসন্ধান ফলাফলের অভিজ্ঞতা তাদের নির্দিষ্ট অ্যাকাউন্ট ডেটার উপর ভিত্তি করে কাস্টমাইজ করা যেতে পারে। লগ ইন করা ব্যবহারকারীদের নির্দিষ্ট ব্রাউজার কুকিজ দ্বারা চিহ্নিত করা হয়, যা একটি সম্মানিত এবং ব্যাপকভাবে সমর্থিত মান।
ব্রাউজার কুকি ব্যবহারের একটি খারাপ দিক হল, এগুলো কোনও পরিষেবা কর্মীর ভেতরে প্রকাশ পায় না এবং ব্যবহারকারীর লগ আউট বা অ্যাকাউন্ট স্যুইচ করার কারণে এগুলোর মান স্বয়ংক্রিয়ভাবে পরীক্ষা করে নিশ্চিত করার কোনও উপায় নেই যে এগুলো পরিবর্তিত হয়নি। ( পরিষেবা কর্মীদের কাছে কুকি অ্যাক্সেস আনার প্রচেষ্টা চলছে, তবে এই লেখার সময় পর্যন্ত, পদ্ধতিটি পরীক্ষামূলক এবং ব্যাপকভাবে সমর্থিত নয়।)
বর্তমান লগ ইন করা ব্যবহারকারী এবং গুগল সার্চ ওয়েব ইন্টারফেসে লগ ইন করা প্রকৃত ব্যবহারকারীর পরিষেবা কর্মীর দৃষ্টিভঙ্গির মধ্যে অমিল থাকলে ভুলভাবে ব্যক্তিগতকৃত অনুসন্ধান ফলাফল বা ভুলভাবে বৈশিষ্ট্যযুক্ত মেট্রিক্স এবং লগিং হতে পারে। এই ব্যর্থতার যেকোনো পরিস্থিতি গুগল সার্চ টিমের জন্য একটি গুরুতর সমস্যা হবে।
সমাধান: postMessage ব্যবহার করে কুকিজ পাঠান
পরীক্ষামূলক API গুলি চালু হওয়ার এবং পরিষেবা কর্মীর ভিতরে ব্রাউজারের কুকিগুলিতে সরাসরি অ্যাক্সেস প্রদানের জন্য অপেক্ষা করার পরিবর্তে, Google অনুসন্ধান দল একটি স্টপ-গ্যাপ সমাধান নিয়েছিল: যখনই পরিষেবা কর্মী দ্বারা নিয়ন্ত্রিত কোনও পৃষ্ঠা লোড করা হয়, তখন পৃষ্ঠাটি প্রাসঙ্গিক কুকিগুলি পড়ে এবং পরিষেবা কর্মীর কাছে পাঠানোর জন্য postMessage() ব্যবহার করে।
এরপর পরিষেবা কর্মী বর্তমান কুকির মানটি তার প্রত্যাশিত মানের সাথে পরীক্ষা করে, এবং যদি কোনও অমিল থাকে, তবে এটি তার স্টোরেজ থেকে ব্যবহারকারী-নির্দিষ্ট ডেটা মুছে ফেলার জন্য পদক্ষেপ নেয় এবং কোনও ভুল ব্যক্তিগতকরণ ছাড়াই অনুসন্ধান ফলাফল পৃষ্ঠাটি পুনরায় লোড করে।
পরিষেবা কর্মীরা জিনিসগুলিকে বেসলাইনে রিসেট করার জন্য যে নির্দিষ্ট পদক্ষেপগুলি গ্রহণ করেন তা Google অনুসন্ধানের প্রয়োজনীয়তার সাথে নির্দিষ্ট, তবে একই সাধারণ পদ্ধতি অন্যান্য ডেভেলপারদের জন্য কার্যকর হতে পারে যারা ব্রাউজার কুকিজ থেকে ব্যক্তিগতকৃত ডেটা নিয়ে কাজ করেন।
সমস্যা: পরীক্ষা-নিরীক্ষা এবং গতিশীলতা
যেমনটি উল্লেখ করা হয়েছে, গুগল সার্চ টিম প্রোডাকশনে পরীক্ষা-নিরীক্ষা চালানোর উপর এবং ডিফল্টভাবে নতুন কোড এবং বৈশিষ্ট্যগুলি চালু করার আগে বাস্তব জগতে এর প্রভাব পরীক্ষা করার উপর অনেক বেশি নির্ভর করে। এটি একটি স্ট্যাটিক সার্ভিস কর্মীর জন্য কিছুটা চ্যালেঞ্জ হতে পারে যারা ক্যাশেড ডেটার উপর খুব বেশি নির্ভর করে, কারণ ব্যবহারকারীদের পরীক্ষা-নিরীক্ষায় অংশগ্রহণ করতে এবং বন্ধ করতে প্রায়শই ব্যাকএন্ড সার্ভারের সাথে যোগাযোগের প্রয়োজন হয়।
সমাধান: গতিশীলভাবে তৈরি পরিষেবা কর্মী স্ক্রিপ্ট
দলটি যে সমাধানটি নিয়েছিল তা হল একটি গতিশীলভাবে তৈরি পরিষেবা কর্মী স্ক্রিপ্ট ব্যবহার করা, যা প্রতিটি ব্যবহারকারীর জন্য ওয়েব সার্ভার দ্বারা কাস্টমাইজ করা হয়, একটি একক, স্ট্যাটিক পরিষেবা কর্মী স্ক্রিপ্টের পরিবর্তে যা আগে থেকে তৈরি করা হয়। পরিষেবা কর্মীর আচরণ বা সাধারণভাবে নেটওয়ার্ক অনুরোধগুলিকে প্রভাবিত করতে পারে এমন পরীক্ষা-নিরীক্ষার তথ্য সরাসরি এই কাস্টমাইজড পরিষেবা কর্মী স্ক্রিপ্টে অন্তর্ভুক্ত করা হয়েছে। ব্যবহারকারীর জন্য সক্রিয় অভিজ্ঞতার সেট পরিবর্তন করা ঐতিহ্যবাহী কৌশলগুলির সংমিশ্রণের মাধ্যমে করা হয়, যেমন ব্রাউজার কুকিজ, সেইসাথে নিবন্ধিত পরিষেবা কর্মী URL-এ আপডেট করা কোড পরিবেশন করা।
একটি গতিশীলভাবে জেনারেট করা সার্ভিস ওয়ার্কার স্ক্রিপ্ট ব্যবহার করলে একটি এস্কেপ হ্যাচ প্রদান করা সহজ হয় যদি কোনও সার্ভিস ওয়ার্কার বাস্তবায়নে কোনও মারাত্মক বাগ থাকে যা এড়ানো প্রয়োজন। ডায়নামিক সার্ভার ওয়ার্কার প্রতিক্রিয়া একটি নো-অপ বাস্তবায়ন হতে পারে, যা কার্যকরভাবে কিছু বা সমস্ত বর্তমান ব্যবহারকারীর জন্য পরিষেবা কর্মীকে অক্ষম করে।
সমস্যা: আপডেট সমন্বয় করা
বাস্তব জগতের যেকোনো পরিষেবা কর্মী মোতায়েনের মুখোমুখি হওয়া সবচেয়ে কঠিন চ্যালেঞ্জগুলির মধ্যে একটি হল ক্যাশের পক্ষে নেটওয়ার্ক এড়িয়ে যাওয়ার মধ্যে একটি যুক্তিসঙ্গত লেনদেন তৈরি করা, একই সাথে নিশ্চিত করা যে বিদ্যমান ব্যবহারকারীরা উৎপাদনে মোতায়েনের পরেই গুরুত্বপূর্ণ আপডেট এবং পরিবর্তনগুলি পান। সঠিক ভারসাম্য অনেকগুলি বিষয়ের উপর নির্ভর করে:
- আপনার ওয়েব অ্যাপটি কি দীর্ঘস্থায়ী একক পৃষ্ঠার অ্যাপ যা ব্যবহারকারী নতুন পৃষ্ঠাগুলিতে নেভিগেট না করেই অনির্দিষ্টকালের জন্য খোলা রাখেন?
- আপনার ব্যাকএন্ড ওয়েব সার্ভারের আপডেটের জন্য ডিপ্লয়মেন্ট ক্যাডেন্স কী।
- আপনার ওয়েব অ্যাপের কিছুটা পুরনো সংস্করণ ব্যবহার করা সাধারণ ব্যবহারকারীরা সহ্য করবেন কিনা, নাকি সতেজতাই সর্বোচ্চ অগ্রাধিকার?
পরিষেবা কর্মীদের উপর পরীক্ষা-নিরীক্ষা করার সময়, গুগল সার্চ টিম নিশ্চিত করেছে যে পরীক্ষাগুলি বেশ কয়েকটি নির্ধারিত ব্যাকএন্ড আপডেটের মাধ্যমে চলমান রাখা হয়েছে, যাতে মেট্রিক্স এবং ব্যবহারকারীর অভিজ্ঞতা বাস্তব জগতে রিটার্ন ব্যবহারকারীরা যা দেখবেন তার সাথে আরও ঘনিষ্ঠভাবে মিলবে।
সমাধান: সতেজতা এবং ক্যাশে-ব্যবহারের ভারসাম্য বজায় রাখুন
বিভিন্ন কনফিগারেশন বিকল্প পরীক্ষা করার পর, গুগল সার্চ টিম দেখতে পেল যে নিম্নলিখিত সেটআপটি সতেজতা এবং ক্যাশে-ব্যবহারের মধ্যে সঠিক ভারসাম্য প্রদান করেছে।
সার্ভিস ওয়ার্কার স্ক্রিপ্টের URLটি Cache-Control: private, max-age=1500 (1500 seconds, or 25 minutes) রেসপন্স হেডারের সাথে পরিবেশন করা হয় এবং হেডারটি যাতে সম্মানিত হয় তা নিশ্চিত করার জন্য updateViaCache 'all' তে সেট করা থাকে। গুগল সার্চ ওয়েব ব্যাকএন্ড হল, যেমনটি আপনি কল্পনা করতে পারেন, একটি বৃহৎ, বিশ্বব্যাপী বিতরণ করা সার্ভারের সেট যার জন্য যতটা সম্ভব 100% আপটাইম প্রয়োজন। এমন একটি পরিবর্তন স্থাপন করা যা সার্ভিস ওয়ার্কার স্ক্রিপ্টের বিষয়বস্তুকে প্রভাবিত করবে তা রোলিং পদ্ধতিতে করা হয়।
যদি কোনও ব্যবহারকারী এমন একটি ব্যাকএন্ডে যান যা আপডেট করা হয়েছে, এবং তারপর দ্রুত অন্য একটি পৃষ্ঠায় যান যেখানে এমন একটি ব্যাকএন্ডে যান যেখানে এখনও আপডেট করা পরিষেবা কর্মী পাওয়া যায়নি, তাহলে তাদের একাধিকবার সংস্করণগুলির মধ্যে উল্টে-পালটে যেতে হবে। অতএব, ব্রাউজারকে বলা যে শেষ চেকের পর থেকে 25 মিনিট অতিবাহিত হলেই কেবল একটি আপডেট করা স্ক্রিপ্ট পরীক্ষা করার ঝামেলা করতে হবে, এতে কোনও উল্লেখযোগ্য অসুবিধা নেই। এই আচরণটি বেছে নেওয়ার সুবিধা হল পরিষেবা কর্মী স্ক্রিপ্টটি গতিশীলভাবে তৈরি করে এমন এন্ডপয়েন্ট দ্বারা প্রাপ্ত ট্র্যাফিক উল্লেখযোগ্যভাবে হ্রাস করা।
অতিরিক্তভাবে, সার্ভিস ওয়ার্কার স্ক্রিপ্টের HTTP প্রতিক্রিয়াতে একটি ETag হেডার সেট করা থাকে, যা নিশ্চিত করে যে 25 মিনিট অতিবাহিত হওয়ার পরে যখন একটি আপডেট চেক করা হয়, তখন সার্ভারটি HTTP 304 প্রতিক্রিয়া দিয়ে দক্ষতার সাথে প্রতিক্রিয়া জানাতে পারে যদি অন্তর্বর্তীকালীন সময়ে মোতায়েন করা পরিষেবা কর্মীর কাছে কোনও আপডেট না থাকে।
যদিও গুগল সার্চ ওয়েব অ্যাপের মধ্যে কিছু ইন্টারঅ্যাকশন একক পৃষ্ঠার অ্যাপ-স্টাইল নেভিগেশন ব্যবহার করে (অর্থাৎ ইতিহাস API এর মাধ্যমে), বেশিরভাগ ক্ষেত্রে, গুগল সার্চ একটি ঐতিহ্যবাহী ওয়েব অ্যাপ যা "বাস্তব" নেভিগেশন ব্যবহার করে। এটি তখন কার্যকর হয় যখন টিম সিদ্ধান্ত নেয় যে পরিষেবা কর্মী আপডেট জীবনচক্রকে ত্বরান্বিত করে এমন দুটি বিকল্প ব্যবহার করা কার্যকর হবে: clients.claim() এবং skipWaiting() । গুগল সার্চের ইন্টারফেসের চারপাশে ক্লিক করলে সাধারণত নতুন HTML ডকুমেন্টে নেভিগেট করা হয়। skipWaiting কল করা নিশ্চিত করে যে একজন আপডেট করা পরিষেবা কর্মী ইনস্টলেশনের পরপরই সেই নতুন নেভিগেশন অনুরোধগুলি পরিচালনা করার সুযোগ পান। একইভাবে, clients.claim() কল করার অর্থ হল আপডেট করা পরিষেবা কর্মী পরিষেবা কর্মী সক্রিয়করণের পরে অনিয়ন্ত্রিত যে কোনও খোলা Google অনুসন্ধান পৃষ্ঠাগুলি নিয়ন্ত্রণ শুরু করার সুযোগ পান।
গুগল সার্চ যে পদ্ধতিটি ব্যবহার করেছে তা সকলের জন্য কার্যকর নয়—এটি বিভিন্ন ধরণের সার্ভিং অপশনের সংমিশ্রণ সাবধানতার সাথে A/B পরীক্ষা করার ফলাফল, যতক্ষণ না তারা তাদের জন্য সবচেয়ে ভালো কাজ করে তা খুঁজে পায়। যেসব ডেভেলপারদের ব্যাকএন্ড অবকাঠামো তাদের দ্রুত আপডেট স্থাপন করতে দেয় তারা HTTP ক্যাশে উপেক্ষা করে যতবার সম্ভব ব্রাউজারকে আপডেটেড সার্ভিস ওয়ার্কার স্ক্রিপ্ট পরীক্ষা করতে পছন্দ করতে পারেন। আপনি যদি এমন একটি একক পৃষ্ঠার অ্যাপ তৈরি করেন যা ব্যবহারকারীরা দীর্ঘ সময়ের জন্য খোলা রাখতে পারেন, তাহলে skipWaiting() ব্যবহার করা সম্ভবত আপনার জন্য সঠিক পছন্দ নয়—দীর্ঘস্থায়ী ক্লায়েন্ট থাকাকালীন আপনি যদি নতুন সার্ভিস ওয়ার্কারকে সক্রিয় করতে দেন তবে ক্যাশে অসঙ্গতির সম্মুখীন হওয়ার ঝুঁকি আপনার রয়েছে।
কী Takeaways
ডিফল্টরূপে, পরিষেবা কর্মীরা কর্মক্ষমতা নিরপেক্ষ নন।
আপনার ওয়েব অ্যাপে একজন সার্ভিস ওয়ার্কার যোগ করার অর্থ হল জাভাস্ক্রিপ্টের একটি অতিরিক্ত অংশ ঢোকানো যা আপনার ওয়েব অ্যাপের অনুরোধের প্রতিক্রিয়া পাওয়ার আগে লোড এবং কার্যকর করতে হবে। যদি সেই প্রতিক্রিয়াগুলি নেটওয়ার্কের পরিবর্তে স্থানীয় ক্যাশে থেকে আসে, তাহলে ক্যাশে-প্রথমে যাওয়ার পারফরম্যান্স জয়ের তুলনায় পরিষেবা কর্মী চালানোর ওভারহেড সাধারণত নগণ্য। কিন্তু যদি আপনি জানেন যে নেভিগেশন অনুরোধগুলি পরিচালনা করার সময় আপনার সার্ভিস ওয়ার্কারকে সর্বদা নেটওয়ার্কের সাথে পরামর্শ করতে হয়, তাহলে নেভিগেশন প্রিলোড ব্যবহার করা একটি গুরুত্বপূর্ণ পারফরম্যান্স জয়।
পরিষেবা কর্মীরা (এখনও!) একটি ক্রমবর্ধমান উন্নতি
সার্ভিস ওয়ার্কার সাপোর্টের গল্প আজ এক বছর আগের তুলনায় অনেক বেশি উজ্জ্বল। সকল আধুনিক ব্রাউজারেই এখন সার্ভিস ওয়ার্কারদের জন্য কিছু না কিছু সাপোর্ট রয়েছে, কিন্তু দুর্ভাগ্যবশত, কিছু উন্নত সার্ভিস ওয়ার্কার ফিচার আছে—যেমন ব্যাকগ্রাউন্ড সিঙ্ক এবং নেভিগেশন প্রিলোড—যা সর্বজনীনভাবে চালু করা হয় না। আপনার প্রয়োজনীয় ফিচারের নির্দিষ্ট সাবসেটের জন্য ফিচার চেক করা এবং শুধুমাত্র তখনই যখন সেগুলি উপস্থিত থাকে তখনই একজন সার্ভিস ওয়ার্কারকে নিবন্ধন করা এখনও যুক্তিসঙ্গত পন্থা।
একইভাবে, যদি আপনি আগে থেকেই পরীক্ষা-নিরীক্ষা চালিয়ে থাকেন এবং জানেন যে পরিষেবা কর্মীর অতিরিক্ত খরচের সাথে কম দামের ডিভাইসগুলি খারাপভাবে কাজ করে, তাহলে আপনি সেই পরিস্থিতিতেও পরিষেবা কর্মীর নিবন্ধন করা থেকে বিরত থাকতে পারেন।
আপনার পরিষেবা কর্মীদের একটি প্রগতিশীল বর্ধন হিসাবে বিবেচনা করা উচিত যা সমস্ত পূর্বশর্ত পূরণ হলে এবং পরিষেবা কর্মী ব্যবহারকারীর অভিজ্ঞতা এবং সামগ্রিক লোডিং কর্মক্ষমতায় ইতিবাচক কিছু যোগ করলে একটি ওয়েব অ্যাপে যুক্ত হয়।
সবকিছু পরিমাপ করো
একজন পরিষেবা কর্মীকে শিপিং করা আপনার ব্যবহারকারীদের অভিজ্ঞতার উপর ইতিবাচক বা নেতিবাচক প্রভাব ফেলেছে কিনা তা নির্ধারণ করার একমাত্র উপায় হল পরীক্ষা-নিরীক্ষা এবং ফলাফল পরিমাপ করা।
অর্থপূর্ণ পরিমাপ সেট আপ করার সুনির্দিষ্ট বৈশিষ্ট্যগুলি নির্ভর করে আপনি কোন বিশ্লেষণ সরবরাহকারী ব্যবহার করছেন এবং আপনার স্থাপনার সেটআপে আপনি সাধারণত কীভাবে পরীক্ষা-নিরীক্ষা করেন তার উপর। গুগল অ্যানালিটিক্স ব্যবহার করে মেট্রিক্স সংগ্রহ করার একটি পদ্ধতি, গুগল আই/ও ওয়েব অ্যাপে পরিষেবা কর্মীদের ব্যবহারের অভিজ্ঞতার উপর ভিত্তি করে এই কেস স্টাডিতে বিস্তারিতভাবে বর্ণনা করা হয়েছে।
লক্ষ্যহীন
ওয়েব ডেভেলপমেন্ট কমিউনিটির অনেকেই প্রোগ্রেসিভ ওয়েব অ্যাপসের সাথে পরিষেবা কর্মীদের যুক্ত করলেও, "গুগল সার্চ পিডব্লিউএ" তৈরি করা টিমের প্রাথমিক লক্ষ্য ছিল না। গুগল সার্চ ওয়েব অ্যাপটি ওয়েব অ্যাপ ম্যানিফেস্টে মেটাডেটা প্রদান করে না, এবং ব্যবহারকারীদের হোম স্ক্রিনে যোগ করার প্রবাহের মধ্য দিয়ে যেতে উৎসাহিত করে না। গুগল সার্চের জন্য ক্লাসিক এন্ট্রি পয়েন্ট নিয়ে ব্যবহারকারীরা তাদের ওয়েব অ্যাপে আসার ব্যাপারে সার্চ টিম সন্তুষ্ট।
গুগল সার্চ ওয়েব অভিজ্ঞতাকে একটি ইনস্টল করা অ্যাপ্লিকেশন থেকে আপনি যা আশা করেন তার সমতুল্য করার চেষ্টা করার পরিবর্তে, প্রাথমিক প্রকাশের উপর ফোকাস ছিল বিদ্যমান ওয়েবসাইটটিকে ধীরে ধীরে উন্নত করা।
স্বীকৃতি
সার্ভিস ওয়ার্কার বাস্তবায়নে তাদের কাজ এবং এটি লেখার পটভূমির উপাদান ভাগ করে নেওয়ার জন্য সমগ্র গুগল সার্চ ওয়েব ডেভেলপমেন্ট টিমকে ধন্যবাদ। বিশেষভাবে ধন্যবাদ ফিলিপ গোল, রাজেশ জগন্নাথন, আর. স্যামুয়েল ক্লাচকো, অ্যান্ডি মার্টোন, লিওনার্দো পেনা, র্যাচেল শিয়েরার, গ্রেগ টেরনো এবং ক্লে উলামকে।
আপডেট (অক্টোবর ২০২১): এই নিবন্ধটি মূলত প্রকাশিত হওয়ার পর থেকে, গুগল সার্চ টিম তাদের বর্তমান সার্ভিস ওয়ার্কার আর্কিটেকচারের সুবিধা এবং লেনদেন পুনর্মূল্যায়ন করেছে। উপরে বর্ণিত সার্ভিস ওয়ার্কারকে অবসর দেওয়া হচ্ছে। গুগল সার্চ ওয়েব অবকাঠামো বিকশিত হওয়ার সাথে সাথে, টিম তাদের সার্ভিস ওয়ার্কার ডিজাইন পুনর্বিবেচনা করতে পারে।