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