স্বাক্ষরিত এক্সচেঞ্জ ব্যবহার করে LCP অপ্টিমাইজ করা

কিভাবে সাইনড এক্সচেঞ্জ পরিমাপ এবং অপ্টিমাইজ করা যায় যাতে সেগুলির মধ্যে সর্বাধিক উন্নতি হয়৷

Devin Mullins

সাইনড এক্সচেঞ্জ (SXGs) হল আপনার পৃষ্ঠার গতি উন্নত করার একটি মাধ্যম—প্রধানত Largest Contentful Paint (LCP) । একটি পৃষ্ঠায় সাইটগুলি (বর্তমানে Google অনুসন্ধান) লিঙ্ক উল্লেখ করার সময়, ব্যবহারকারী লিঙ্কটিতে ক্লিক করার আগে তারা এটিকে ব্রাউজার ক্যাশে প্রিফেচ করতে পারে।

এমন ওয়েব পৃষ্ঠাগুলি তৈরি করা সম্ভব যেগুলি, যখন প্রিফেচ করা হয়, পৃষ্ঠাটি রেন্ডার করার জন্য গুরুত্বপূর্ণ পথে কোনও নেটওয়ার্কের প্রয়োজন হয় না! একটি 4G সংযোগে, এই পৃষ্ঠা লোড 2.8s থেকে 0.9s হয় (বাকি 0.9s বেশিরভাগই CPU ব্যবহার করে):

বেশিরভাগ লোকেরা আজ SXG প্রকাশ করছে তারা ক্লাউডফ্লেয়ারের সহজে ব্যবহারযোগ্য স্বয়ংক্রিয় স্বাক্ষরিত এক্সচেঞ্জ (ASX) বৈশিষ্ট্যটি ব্যবহার করছে (যদিও ওপেন সোর্স বিকল্পগুলিও বিদ্যমান):

অনেক ক্ষেত্রে, এই বৈশিষ্ট্যটি সক্ষম করার জন্য বাক্সটি চেক করাই উপরে দেখানো যথেষ্ট উন্নতির জন্য যথেষ্ট। কখনও কখনও, এই এসএক্সজিগুলি পাইপলাইনের প্রতিটি পর্যায়ে উদ্দেশ্য অনুসারে কাজ করছে তা নিশ্চিত করতে এবং প্রিফেচের সম্পূর্ণ সুবিধা নিতে পৃষ্ঠাগুলিকে অপ্টিমাইজ করতে আরও কয়েকটি পদক্ষেপ রয়েছে৷

ক্লাউডফ্লেয়ার চালু হওয়ার পর থেকে গত কয়েক মাসে, আমি বিভিন্ন ফোরামে প্রশ্নগুলি পড়ছি এবং উত্তর দিচ্ছি এবং কীভাবে সাইটগুলিকে তাদের SXG স্থাপনার থেকে সর্বাধিক সুবিধা পাচ্ছে তা নিশ্চিত করতে কীভাবে পরামর্শ দিতে হয় তা শিখছি। এই পোস্টটি আমার পরামর্শের একটি সংগ্রহ। আমি ধাপে ধাপে হাঁটব:

• WebPageTest ব্যবহার করে SXG কর্মক্ষমতা বিশ্লেষণ করুন ।
• SXG পাইপলাইন ডিবাগ করুন যদি বিশ্লেষণ ধাপ দেখায় যে এটি কাজ করছে না।
• একটি সর্বোত্তম max-age সেট করা এবং রেন্ডার-ব্লকিং সাবরিসোর্স প্রিলোড করা সহ SXG প্রিফেচের জন্য পৃষ্ঠাগুলি অপ্টিমাইজ করুন ৷
• উপযুক্ত পরীক্ষা এবং নিয়ন্ত্রণ গোষ্ঠী নির্বাচন করে Google Analytics ব্যবহার করে SXG উন্নতি পরিমাপ করুন ।

ভূমিকা

একটি SXG হল একটি ফাইল যাতে একটি URL, HTTP প্রতিক্রিয়া শিরোনামের একটি সেট এবং একটি প্রতিক্রিয়া বডি—সবই একটি ওয়েব PKI শংসাপত্র দ্বারা ক্রিপ্টোগ্রাফিকভাবে স্বাক্ষরিত। যখন ব্রাউজার একটি SXG লোড করে, তখন এটি এই সবগুলি যাচাই করে:

• SXG এর মেয়াদ শেষ হয়নি।
• স্বাক্ষরটি URL, শিরোনাম, মূল অংশ এবং শংসাপত্রের সাথে মেলে।
• শংসাপত্রটি বৈধ এবং URL এর সাথে মেলে৷

যাচাইকরণ ব্যর্থ হলে, ব্রাউজার SXG ত্যাগ করে এবং পরিবর্তে স্বাক্ষরিত URL নিয়ে আসে। যাচাইকরণ সফল হলে, ব্রাউজার স্বাক্ষরিত প্রতিক্রিয়া লোড করে, এটিকে এমনভাবে আচরণ করে যেন এটি সরাসরি স্বাক্ষরিত URL থেকে এসেছে। এটি SXG গুলিকে যেকোনো সার্ভারে পুনঃহোস্ট করার অনুমতি দেয় যতক্ষণ না এটি স্বাক্ষরিত হওয়ার পর থেকে মেয়াদ উত্তীর্ণ বা পরিবর্তন না হয়৷

Google অনুসন্ধানের ক্ষেত্রে, SXG তার অনুসন্ধান ফলাফলগুলিতে পৃষ্ঠাগুলির প্রিফেচিং সক্ষম করে ৷ SXG-কে সমর্থন করে এমন পৃষ্ঠাগুলির জন্য, Google অনুসন্ধান ওয়েবpkgcache.com-এ হোস্ট করা পৃষ্ঠার ক্যাশড কপি প্রিফেচ করতে পারে। এই webpkgcache.com URLগুলি পৃষ্ঠার প্রদর্শন বা আচরণকে প্রভাবিত করে না, কারণ ব্রাউজারটি আসল, স্বাক্ষরিত URLকে সম্মান করে৷ প্রিফেচিং আপনার পৃষ্ঠাকে অনেক দ্রুত লোড করতে সক্ষম করে।

বিশ্লেষণ করুন

SXG-এর সুবিধা দেখতে, পুনরাবৃত্তিযোগ্য পরিস্থিতিতে SXG কর্মক্ষমতা বিশ্লেষণ করতে একটি ল্যাব টুল ব্যবহার করে শুরু করুন। আপনি SXG প্রিফেচ সহ এবং ছাড়া জলপ্রপাত-এবং LCP-এর তুলনা করতে WebPageTest ব্যবহার করতে পারেন।

নিম্নরূপ SXG ছাড়া একটি পরীক্ষা তৈরি করুন:

• WebPageTest- এ যান এবং সাইন ইন করুন। সাইন ইন করলে পরবর্তীতে তুলনা করার জন্য আপনার পরীক্ষার ইতিহাস সংরক্ষণ করা হয়।
• আপনি পরীক্ষা করতে চান URL লিখুন.
• অ্যাডভান্সড কনফিগারেশনে যান। (এসএক্সজি পরীক্ষার জন্য আপনার অ্যাডভান্সড কনফিগারেশনের প্রয়োজন হবে, তাই এটি এখানে ব্যবহার করা নিশ্চিত করতে সহায়তা করে যে পরীক্ষার বিকল্পগুলি একই।)
• টেস্ট সেটিংস ট্যাবে, 4G-তে সংযোগ সেট করা এবং "চালাতে পরীক্ষার সংখ্যা" 7-এ বৃদ্ধি করা সহায়ক হতে পারে।
• স্টার্ট টেস্টে ক্লিক করুন।

উপরের মত একই ধাপগুলি ব্যবহার করে SXG-এর সাথে একটি পরীক্ষা তৈরি করুন, কিন্তু Start Test এ ক্লিক করার আগে, স্ক্রিপ্ট ট্যাবে যান, নিম্নলিখিত WebPageTest স্ক্রিপ্টে পেস্ট করুন এবং নির্দেশিত হিসাবে দুটি navigate URL পরিবর্তন করুন:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

প্রথম navigate URL-এর জন্য, যদি আপনার পৃষ্ঠাটি এখনও কোনো Google অনুসন্ধান ফলাফলে প্রদর্শিত না হয়, তাহলে আপনি এই উদ্দেশ্যে একটি প্রেন্ড সার্চ ফলাফল পৃষ্ঠা তৈরি করতে এই প্রিফেচ পৃষ্ঠাটি ব্যবহার করতে পারেন৷

দ্বিতীয় navigate URL নির্ধারণ করতে, SXG ভ্যালিডেটর ক্রোম এক্সটেনশন ব্যবহার করে আপনার পৃষ্ঠায় যান এবং ক্যাশে URL দেখতে এক্সটেনশন আইকনে ক্লিক করুন:

একবার এই পরীক্ষাগুলি সম্পূর্ণ হলে, টেস্ট ইতিহাসে যান, দুটি পরীক্ষা নির্বাচন করুন এবং তুলনা ক্লিক করুন:

তুলনা URL-এ &medianMetric=LCP যুক্ত করুন যাতে WebPageTest তুলনার প্রতিটি দিকের জন্য মধ্যম LCP সহ রান নির্বাচন করে। (স্পিড ইনডেক্স দ্বারা ডিফল্ট মাঝারি।)

জলপ্রপাতের তুলনা করতে, জলপ্রপাতের অস্বচ্ছতা বিভাগটি প্রসারিত করুন এবং স্লাইডারটি টেনে আনুন। ভিডিওটি দেখতে, ফিল্মস্ট্রিপ সেটিংস সামঞ্জস্য করুন- এ ক্লিক করুন, সেই ডায়ালগের ভিতরে স্ক্রোল করুন এবং ভিডিও দেখুন ক্লিক করুন।

SXG প্রিফেচ সফল হলে, আপনি দেখতে পাবেন যে "With SXG" জলপ্রপাত HTML-এর জন্য একটি সারি অন্তর্ভুক্ত করে না এবং সাবরিসোর্সের জন্য ফেচগুলি তাড়াতাড়ি শুরু হয়৷ উদাহরণস্বরূপ, এখানে "আগে" এবং "পরে" তুলনা করুন:

ডিবাগ

যদি WebPageTest দেখায় যে SXG প্রিফেচ করা হচ্ছে, তাহলে পাইপলাইনের সমস্ত ধাপে এটি সফল হয়েছে; কিভাবে LCP আরও উন্নত করা যায় তা শিখতে আপনি অপ্টিমাইজ বিভাগে যেতে পারেন। অন্যথায়, আপনাকে খুঁজে বের করতে হবে কোথায় পাইপলাইনে এটি ব্যর্থ হয়েছে এবং কেন; কিভাবে শিখতে পড়ুন।

প্রকাশনা

নিশ্চিত করুন যে আপনার পৃষ্ঠাগুলি SXG হিসাবে তৈরি হচ্ছে৷ এটি করার জন্য, আপনাকে একজন ক্রলার হওয়ার ভান করতে হবে। সবচেয়ে সহজ উপায় হল SXG ভ্যালিডেটর ক্রোম এক্সটেনশন ব্যবহার করা:

এক্সটেনশনটি একটি Accept রিকোয়েস্ট হেডার সহ বর্তমান ইউআরএল নিয়ে আসে যা বলে যে এটি SXG সংস্করণটিকে পছন্দ করে। আপনি যদি Origin-এর পাশে একটি চেক মার্ক (✅) দেখতে পান, তার মানে একটি SXG ফেরত দেওয়া হয়েছে; আপনি ইনডেক্সিং বিভাগে যেতে পারেন।

আপনি যদি একটি ক্রস চিহ্ন (❌) দেখতে পান, তার মানে একটি SXG ফেরত দেওয়া হয়নি:

যদি Cloudflare ASX সক্ষম করা থাকে, তাহলে ক্রস চিহ্নের (❌) সম্ভাব্য কারণ হল একটি ক্যাশে নিয়ন্ত্রণ প্রতিক্রিয়া শিরোনাম এটিকে বাধা দেয়৷ ASX নিম্নলিখিত নামগুলির সাথে শিরোনামগুলি দেখে:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

যদি এই শিরোনামগুলির মধ্যে যেকোনো একটিতে নিম্নলিখিত হেডার মান থাকে, তাহলে এটি একটি SXG তৈরি হতে বাধা দেবে:

• private
• no-store
• no-cache
• max-age 120-এর কম, যদি না s-maxage 120-এর চেয়ে বেশি বা সমান দ্বারা ওভাররাইড না করা হয়

ASX এই ক্ষেত্রে একটি SXG তৈরি করে না কারণ SXG গুলি ক্যাশে করা হতে পারে এবং একাধিক ভিজিট এবং একাধিক ভিজিটরের জন্য পুনরায় ব্যবহার করা যেতে পারে ।

ক্রস মার্ক (❌) এর আরেকটি সম্ভাব্য কারণ হল Set-Cookie ব্যতীত এই স্টেটফুল রেসপন্স হেডারগুলির একটির উপস্থিতি। ASX SXG স্পেসিফিকেশন মেনে চলতে Set-Cookie হেডার সরিয়ে দেয়।

আরেকটি সম্ভাব্য কারণ হল একটি Vary: Cookie প্রতিক্রিয়া শিরোনাম। Googlebot ব্যবহারকারীর শংসাপত্র ছাড়াই SXG নিয়ে আসে এবং সেগুলি একাধিক দর্শকদের কাছে পরিবেশন করতে পারে। আপনি যদি বিভিন্ন ব্যবহারকারীকে তাদের কুকির উপর ভিত্তি করে বিভিন্ন HTML পরিবেশন করেন, তাহলে তারা একটি ভুল অভিজ্ঞতা যেমন লগ আউট ভিউ দেখতে পাবে।

ক্রোম এক্সটেনশনের বিকল্পভাবে, আপনি curl মত একটি টুল ব্যবহার করতে পারেন:

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

বা dump-signedexchange :

dump-signedexchange -verify -uri $URL

SXG উপস্থিত এবং বৈধ হলে, আপনি SXG-এর একটি মানব পাঠযোগ্য প্রিন্টআউট দেখতে পাবেন। অন্যথায়, আপনি একটি ত্রুটি বার্তা দেখতে পাবেন।

ইনডেক্সিং

নিশ্চিত করুন যে আপনার SXG সফলভাবে Google অনুসন্ধান দ্বারা সূচীকৃত হয়েছে৷ Chrome DevTools খুলুন, তারপর আপনার পৃষ্ঠার জন্য একটি Google অনুসন্ধান করুন৷ যদি এটি একটি SXG হিসাবে সূচিত করা হয়, তাহলে আপনার পৃষ্ঠায় Google-এর লিঙ্কটিতে webpkgcache.com-এর অনুলিপি নির্দেশ করে একটি data-sxg-url অন্তর্ভুক্ত থাকবে:

যদি Google অনুসন্ধান মনে করে যে ব্যবহারকারীর ফলাফলে ক্লিক করার সম্ভাবনা রয়েছে, তবে এটি এটিও প্রিফেচ করবে:

<link> উপাদানটি ব্রাউজারকে তার প্রিফেচ ক্যাশে SXG ডাউনলোড করার নির্দেশ দেয়। যখন ব্যবহারকারী <a> উপাদানটিতে ক্লিক করেন, ব্রাউজারটি সেই ক্যাশে করা SXG ব্যবহার করে পৃষ্ঠাটি রেন্ডার করবে।

এছাড়াও আপনি DevTools-এর নেটওয়ার্ক ট্যাবে গিয়ে এবং webpkgcache ধারণকারী URL গুলি অনুসন্ধান করে প্রিফেচের প্রমাণ দেখতে পারেন।

যদি <a> webpkgcache.com-এর দিকে নির্দেশ করে, তাহলে এর অর্থ হল স্বাক্ষরিত এক্সচেঞ্জের Google সার্চ ইন্ডেক্সিং কাজ করছে। আপনি ইনজেশন বিভাগে এগিয়ে যেতে পারেন।

অন্যথায়, এটি হতে পারে যে আপনি SXG সক্ষম করার পর থেকে Google এখনও আপনার পৃষ্ঠাটি পুনরায় ক্রল করেনি৷ Google অনুসন্ধান কনসোল URL পরিদর্শন টুল ব্যবহার করে দেখুন:

একটি digest: mi-sha256-03=... হেডার নির্দেশ করে যে Google সফলভাবে SXG সংস্করণটি ক্রল করেছে৷

যদি একটি digest শিরোনাম উপস্থিত না থাকে, তাহলে এটি একটি ইঙ্গিত হতে পারে যে Googlebot-এ একটি SXG পরিবেশন করা হয়নি বা আপনি SXG সক্ষম করার পর থেকে সূচকটি আপডেট করা হয়নি৷

যদি একটি SXG সফলভাবে ক্রল করা হয়, কিন্তু এটি এখনও লিঙ্ক করা না হয়, তাহলে এটি SXG ক্যাশে প্রয়োজনীয়তা পূরণ করতে ব্যর্থ হতে পারে। এগুলো পরবর্তী বিভাগে কভার করা হয়েছে।

ইনজেশন

যখন Google অনুসন্ধান একটি SXG সূচী করে, তখন এটি তার অনুলিপি Google SXG ক্যাশে পাঠায়, যা ক্যাশের প্রয়োজনীয়তার বিরুদ্ধে এটিকে যাচাই করে। ক্রোম এক্সটেনশন ফলাফল দেখায়:

আপনি যদি একটি টিক চিহ্ন (✅) দেখতে পান, তাহলে আপনি অপ্টিমাইজে এগিয়ে যেতে পারেন।

যদি এটি প্রয়োজনীয়তাগুলি পূরণ করতে ব্যর্থ হয়, তাহলে আপনি একটি ক্রস চিহ্ন (❌) এবং একটি সতর্কতা বার্তা দেখতে পাবেন যা নির্দেশ করে কেন:

এই ইভেন্টে, পৃষ্ঠাটি SXG সক্ষম করার আগে ঠিক যেমন কাজ করেছিল। Google একটি SXG প্রিফেচ ছাড়াই তার আসল হোস্টে পৃষ্ঠার সাথে লিঙ্ক করবে৷

ইভেন্টে যে ক্যাশড কপিটির মেয়াদ শেষ হয়ে গেছে এবং পটভূমিতে পুনরায় আনা হচ্ছে, আপনি একটি ঘন্টাঘড়ি দেখতে পাবেন (⌛):

SXG-এ Google ডেভেলপার ডকুমেন্টে ম্যানুয়ালি ক্যাশে অনুসন্ধান করার জন্য নির্দেশাবলী রয়েছে।

অপ্টিমাইজ করুন

যদি এসএক্সজি ভ্যালিডেটর ক্রোম এক্সটেনশনটি সমস্ত টিক চিহ্ন (✅) দেখায় তবে আপনার কাছে একটি SXG আছে যা ব্যবহারকারীদের পরিবেশন করা যেতে পারে! আপনার ওয়েব পৃষ্ঠাটি কীভাবে অপ্টিমাইজ করবেন তা জানতে পড়ুন যাতে আপনি SXG থেকে সর্বাধিক LCP উন্নতি পেতে পারেন।

সর্বোচ্চ বয়স

SXG-এর মেয়াদ শেষ হলে, Google SXG ক্যাশে ব্যাকগ্রাউন্ডে একটি নতুন কপি আনবে। সেই আনার জন্য অপেক্ষা করার সময়, ব্যবহারকারীদের মূল হোস্টের পৃষ্ঠায় নির্দেশিত করা হয়, যা প্রিফেচ করা হয় না। আপনি যত বেশি সময় Cache-Control: max-age , এই ব্যাকগ্রাউন্ড ফেচটি তত কম হয় এবং এইভাবে প্রায়শই প্রিফেচের মাধ্যমে LCP কমানো যায়।

এটি পারফরম্যান্স এবং সতেজতার মধ্যে একটি ট্রেডঅফ, এবং ক্যাশে সাইট মালিকদের প্রতিটি পৃষ্ঠার নির্দিষ্ট প্রয়োজনের জন্য 2 মিনিট থেকে 7 দিনের মধ্যে যে কোনও জায়গায় সর্বোচ্চ বয়সের সাথে SXG প্রদান করতে দেয়। উপাখ্যানগতভাবে, আমরা এটি খুঁজে পাই:

• max-age=86400 (1 দিন) বা তার বেশি সময় পারফরম্যান্সের জন্য ভাল কাজ করে
• max-age=120 (2 মিনিট) করে না

আমরা এই দুটির মধ্যে মান সম্পর্কে আরও জানতে আশা করি, যেহেতু আমরা ডেটা আরও অধ্যয়ন করি।

ব্যবহারকারী-এজেন্ট

একবার, প্রিফেচড SXG ব্যবহার করার সময় আমি LCP বৃদ্ধি দেখেছি। SXG প্রিফেচ ছাড়া এবং এর সাথে মধ্যমা ফলাফলের তুলনা করে আমি WebPageTest চালিয়েছি। নিচের After এ ক্লিক করুন:

আমি দেখেছি যে প্রিফেচ কাজ করছে। এইচটিএমএল সমালোচনামূলক পথ থেকে সরানো হয় এবং, এইভাবে, সমস্ত উপ-সম্পদ আগে লোড করতে সক্ষম হয়। কিন্তু এলসিপি—সেই সবুজ ড্যাশড লাইন —2s থেকে বেড়ে 2.1s হয়েছে ।

এটি নির্ণয় করতে, আমি ফিল্ম স্ট্রিপগুলি দেখেছিলাম। আমি খুঁজে পেয়েছি যে পৃষ্ঠাটি SXG-তে ভিন্নভাবে রেন্ডার হয়েছে। সাধারণ HTML-এ, Chrome নির্ধারণ করেছে যে LCP-এর জন্য "সবচেয়ে বড় উপাদান" শিরোনাম। যাইহোক, SXG সংস্করণে, পৃষ্ঠাটি একটি অলস-লোড করা ব্যানার যোগ করেছে, যা শিরোনামটিকে ভাঁজের নীচে ঠেলে দিয়েছে এবং নতুন বৃহত্তম উপাদানটিকে অলস-লোড করা কুকি সম্মতি ডায়ালগ হিসেবে তৈরি করেছে। সবকিছুই আগের চেয়ে দ্রুত রেন্ডার হয়েছে, কিন্তু লেআউটের পরিবর্তনের ফলে মেট্রিক এটিকে ধীর বলে রিপোর্ট করেছে।

আমি গভীরভাবে খনন করেছি এবং লেআউটের পার্থক্যের কারণ আবিষ্কার করেছি যে পৃষ্ঠাটি User-Agent দ্বারা পরিবর্তিত হয় এবং যুক্তিতে একটি ত্রুটি ছিল৷ এটি একটি ডেস্কটপ পৃষ্ঠা পরিবেশন করছিল যদিও SXG ক্রল শিরোলেখ মোবাইল নির্দেশ করে৷ এটি ঠিক করার পরে, ব্রাউজার সঠিকভাবে পৃষ্ঠার শিরোনামটিকে আবার তার বৃহত্তম উপাদান হিসাবে চিহ্নিত করেছে৷

এখন, "পরে" ক্লিক করে, আমি দেখেছি যে প্রিফেচড এলসিপি 1.3s এ নেমে গেছে :

SXG গুলি সমস্ত ফর্ম ফ্যাক্টরের জন্য সক্ষম। এর জন্য প্রস্তুত করতে, নিশ্চিত করুন যে এর মধ্যে একটি সত্য:

• আপনার পৃষ্ঠা User-Agent দ্বারা Vary হয় না (যেমন এটি প্রতিক্রিয়াশীল ডিজাইন বা পৃথক মোবাইল/ডেস্কটপ URL ব্যবহার করে)।
• যদি আপনার পৃষ্ঠাটি ডায়নামিক সার্ভিং ব্যবহার করে, তাহলে এটি <meta name=supported-media content=...> ব্যবহার করে নিজেকে মোবাইল- বা ডেস্কটপ-শুধুমাত্র টীকা দেয়।

উপসম্পদ

এইচটিএমএল সহ সাবরিসোর্স (ছবি সহ) প্রিফেচ করতে SXG ব্যবহার করা যেতে পারে। Cloudflare ASX একই-অরিজিন (প্রথম-পক্ষ) <link rel=preload> উপাদানগুলির জন্য HTML স্ক্যান করবে এবং সেগুলিকে SXG-সামঞ্জস্যপূর্ণ লিঙ্ক শিরোনামে রূপান্তর করবে। সোর্স কোডের বিশদ বিবরণ এখানে এবং এখানে ।

যদি এটি কাজ করে, আপনি Google অনুসন্ধান থেকে অতিরিক্ত প্রিফেচগুলি দেখতে পাবেন:

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

Google SXG ক্যাশে 20টি পর্যন্ত সাবরিসোর্স প্রিলোড করার অনুমতি দেয় এবং ASX নিশ্চিত করে যে এই সীমাটি অতিক্রম করা যাবে না। যাইহোক, অনেকগুলি সাবরিসোর্স প্রিলোড যোগ করার ঝুঁকি রয়েছে। ক্রস-সাইট ট্র্যাকিং প্রতিরোধ করার জন্য ব্রাউজারটি শুধুমাত্র প্রিলোড করা সাবরিসোর্স ব্যবহার করবে যদি সেগুলির সবগুলি আনা শেষ হয়ে যায় । যত বেশি সাবরিসোর্স আছে, ব্যবহারকারী আপনার পৃষ্ঠায় ক্লিক করার আগে সেগুলির সবকটিই প্রিফেচিং শেষ করার সম্ভাবনা কম।

SXG ভ্যালিডেটর বর্তমানে সাবরিসোর্স চেক করে না; ডিবাগ করতে, এর মধ্যে curl বা dump-signedexchange ব্যবহার করুন।

পরিমাপ

WebPageTest-এর অধীনে LCP উন্নতিকে অপ্টিমাইজ করার পর, আপনার সাইটের সামগ্রিক কর্মক্ষমতাতে SXG প্রিফেচিংয়ের প্রভাব পরিমাপ করা কার্যকর।

সার্ভার-সাইড মেট্রিক্স

টাইম টু ফার্স্ট বাইট (TTFB) এর মতো সার্ভার-সাইড মেট্রিক্স পরিমাপ করার সময়, এটা মনে রাখা গুরুত্বপূর্ণ যে আপনার সাইট শুধুমাত্র সেই ক্রলারদের কাছে SXG পরিবেশন করে যারা ফর্ম্যাট স্বীকার করে। আপনার TTFB এর পরিমাপকে প্রকৃত ব্যবহারকারীদের কাছ থেকে আসা অনুরোধের মধ্যে সীমাবদ্ধ করুন, বট নয়। আপনি দেখতে পারেন যে SXGs তৈরি করা ক্রলার অনুরোধের জন্য TTFB বৃদ্ধি করে, কিন্তু এটি আপনার দর্শকদের অভিজ্ঞতার উপর কোন প্রভাব ফেলে না।

ক্লায়েন্ট-সাইড মেট্রিক্স

SXGs ক্লায়েন্ট-সাইড মেট্রিক্স, বিশেষ করে LCP-এর জন্য সর্বাধিক গতির সুবিধা তৈরি করে। তাদের প্রভাব পরিমাপ করার সময়, আপনি কেবল Cloudflare ASX সক্ষম করতে পারেন, Googlebot দ্বারা এটি পুনরায় ক্রল করার জন্য অপেক্ষা করুন, Core Web Vitals (CWV) সমষ্টির জন্য অতিরিক্ত 28 দিন অপেক্ষা করুন এবং তারপরে আপনার নতুন CWV নম্বরগুলি দেখুন৷ যাইহোক, এই সময়ের ফ্রেমের মধ্যে অন্যান্য সমস্ত পরিবর্তনের মধ্যে মিশ্রিত হলে পরিবর্তনটি চিহ্নিত করা কঠিন হতে পারে।

পরিবর্তে, আমি সম্ভাব্যভাবে প্রভাবিত পৃষ্ঠা লোডগুলিতে "জুম ইন" করা সহায়ক বলে মনে করি এবং এটিকে এইভাবে ফ্রেম করি, "SXGs পৃষ্ঠা দর্শনের X% প্রভাবিত করে, তাদের LCP 75 তম শতাংশে Y মিলিসেকেন্ড দ্বারা উন্নত করে।"

বর্তমানে, SXG প্রিফেচ শুধুমাত্র কিছু শর্তের অধীনে ঘটে:

• Chromium ব্রাউজার (যেমন Chrome বা Edge iOS ছাড়া), সংস্করণ M98 বা উচ্চতর
• Referer: google.com বা অন্যান্য Google অনুসন্ধান ডোমেন । (উল্লেখ্য যে Google Analytics-এ, একটি রেফারেল ট্যাগ সেশনের সমস্ত পৃষ্ঠা দর্শনে প্রযোজ্য হয়, যেখানে SXG প্রিফেচ শুধুমাত্র প্রথম পৃষ্ঠার দৃশ্যে প্রযোজ্য হয়, সরাসরি Google অনুসন্ধান থেকে লিঙ্ক করা হয়৷)

কিভাবে "পৃষ্ঠা দর্শনের X%" পরিমাপ করা যায় এবং "Y মিলিসেকেন্ড দ্বারা তাদের LCP উন্নত করা" সম্পর্কে সমসাময়িক অধ্যয়ন বিভাগটি পড়ুন।

সমসাময়িক অধ্যয়ন

বাস্তব ব্যবহারকারী মনিটরিং (RUM) ডেটা দেখার সময়, আপনার পৃষ্ঠা লোডগুলিকে SXG এবং নন-SXG-এ বিভক্ত করা উচিত। এটি করার সময়, আপনি যে পৃষ্ঠা লোডগুলি দেখছেন তা সীমিত করা অপরিহার্য, তাই নির্বাচনের পক্ষপাত এড়াতে SXG-এর জন্য নন-SXG পাশ মেলে। অন্যথায়, নিম্নলিখিত সমস্তগুলি শুধুমাত্র নন-এসএক্সজি পৃষ্ঠা লোডের সেটে বিদ্যমান থাকবে, যার মধ্যে সহজাতভাবে ভিন্ন LCP থাকতে পারে:

• iOS ডিভাইস: এই ডিভাইসগুলি রয়েছে এমন ব্যবহারকারীদের মধ্যে হার্ডওয়্যার বা নেটওয়ার্ক গতির পার্থক্যের কারণে।
• পুরানো ক্রোমিয়াম ব্রাউজার: একই কারণে।
• ডেস্কটপ ডিভাইস: একই কারণে বা পৃষ্ঠার বিন্যাস একটি ভিন্ন "বৃহত্তর উপাদান" বেছে নেওয়ার কারণ।
• একই-সাইট নেভিগেশন (সাইটের মধ্যে লিঙ্ক অনুসরণকারী দর্শক): কারণ তারা পূর্ববর্তী পৃষ্ঠা লোড থেকে ক্যাশে করা উপ-সম্পদ পুনরায় ব্যবহার করতে পারে।

Google Analytics (UA) এ, "হিট" স্কোপ সহ দুটি কাস্টম মাত্রা তৈরি করুন , একটি নাম "isSXG" এবং একটি নাম "রেফারার"। (বিল্ট-ইন "উৎস" মাত্রার সেশন স্কোপ আছে, তাই এটি একই-সাইট নেভিগেশন বাদ দেয় না।)

নিম্নলিখিত ফিল্টার এবং একসাথে যুক্ত করে "SXG counterfactual" নামে একটি কাস্টম সেগমেন্ট তৈরি করুন:

• referrer শুরু হয় https://www.google.
• Browser হুবহু Chrome সাথে মেলে
• Browser সংস্করণ রেজেক্সের সাথে মেলে ^(9[8-9]|[0-9]{3})
• isSXG ঠিক false মেলে

"SXG" নামে এই সেগমেন্টের একটি অনুলিপি তৈরি করুন, isSXG ব্যতীত true সাথে হুবহু মেলে৷

আপনার সাইটের টেমপ্লেটে, Google Analytics স্নিপেটের উপরে নিম্নলিখিত স্নিপেট যোগ করুন। এটি একটি বিশেষ সিনট্যাক্স যা একটি SXG তৈরি করার সময় ASX false থেকে true পরিবর্তন করবে:

<script data-issxg-var>window.isSXG=false</script>

LCP রেকর্ড করার জন্য আপনার Google Analytics রিপোর্টিং স্ক্রিপ্ট কাস্টমাইজ করুন। আপনি যদি gtag.js ব্যবহার করেন, তাহলে কাস্টম ডাইমেনশন সেট করতে 'config' কমান্ডটি পরিবর্তন করুন (Google Analytics ব্যবহার করতে বলেছে এমন নাম দিয়ে 'dimension1' এবং 'dimension2' প্রতিস্থাপন করুন):

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

আপনি যদি analytics.js ব্যবহার করেন, এখানে নথিভুক্ত হিসাবে 'create' কমান্ডটি পরিবর্তন করুন।

কিছু ডেটা সংগ্রহ করার জন্য কয়েক দিন অপেক্ষা করার পর, Google Analytics ইভেন্ট রিপোর্টে যান এবং SXG সেগমেন্টের জন্য একটি ড্রিলডাউন যোগ করুন। এটি "SXGs পৃষ্ঠা দর্শনের X% প্রভাবিত করে" এর জন্য X পূরণ করা উচিত:

অবশেষে, ওয়েব ভাইটালস রিপোর্টে যান, "সেগমেন্ট বেছে নিন" এবং "SXG কাউন্টারফ্যাকচুয়াল" এবং "SXG" নির্বাচন করুন।

"জমা দিন" এ ক্লিক করুন এবং আপনি দুটি বিভাগের জন্য LCP বিতরণ দেখতে পাবেন। "75 তম পার্সেন্টাইলে Y মিলিসেকেন্ড দ্বারা তাদের LCP উন্নত করার" জন্য এটি Y পূরণ করা উচিত:

সতর্কতা

একবার আপনি উপরের সমস্ত ফিল্টার প্রয়োগ করার পরে, SXG কাউন্টারফ্যাকচুয়াল পৃষ্ঠা লোডগুলি এই ধরনের জিনিসগুলি নিয়ে গঠিত হওয়া উচিত:

• ক্যাশে মিস: যদি Google SXG ক্যাশে প্রদত্ত URL-এর জন্য SXG-এর একটি নতুন কপি না থাকে, তাহলে এটি আপনার সাইটের আসল URL-এ পুনঃনির্দেশিত হবে৷
• অন্যান্য ফলাফলের ধরন: বর্তমানে, Google অনুসন্ধান শুধুমাত্র স্ট্যান্ডার্ড ওয়েব ফলাফল এবং কিছু অন্যান্য প্রকারের জন্য SXG সমর্থন করে। অন্যান্য, যেমন ফিচারড স্নিপেট এবং টপ স্টোরিজ ক্যারাউজেল, আপনার সাইটের আসল ইউআরএলের সাথে লিঙ্ক করবে।
• অযোগ্য URL: যদি আপনার সাইটের কিছু পৃষ্ঠা SXG-এর জন্য যোগ্য না হয় (যেমন কারণ সেগুলি ক্যাশেযোগ্য নয়), তাহলে সেগুলি এই সেটে উপস্থিত হতে পারে৷

SXG পৃষ্ঠা লোড এবং নন-SXG পৃষ্ঠা লোডের উপরোক্ত সেটের মধ্যে অবশিষ্ট পক্ষপাত থাকতে পারে, তবে এটি সমসাময়িক অধ্যয়ন বিভাগের শীর্ষে উল্লিখিত পক্ষপাতের চেয়ে আকারে ছোট হওয়া উচিত। উদাহরণস্বরূপ, সম্ভবত আপনার ক্যাশেযোগ্য পৃষ্ঠাগুলি আপনার ক্যাশেযোগ্য পৃষ্ঠাগুলির চেয়ে ধীর বা দ্রুততর। আপনি যদি সন্দেহ করেন যে এটি একটি সমস্যা হতে পারে, তাহলে একটি নির্দিষ্ট SXG-যোগ্য URL-এর মধ্যে সীমিত ডেটার দিকে তাকানোর কথা বিবেচনা করুন যাতে এটির ফলাফল সামগ্রিক অধ্যয়নের সাথে মেলে কিনা।

যদি আপনার সাইটে কিছু AMP পৃষ্ঠা থাকে, তাহলে SXG সক্ষম করার ফলে তারা সম্ভবত পারফরম্যান্সের উন্নতি দেখতে পাবে না, কারণ সেগুলি ইতিমধ্যেই Google অনুসন্ধান থেকে প্রিফেচ করা যেতে পারে। প্রাসঙ্গিক পরিবর্তনগুলিকে আরও "জুম ইন" করতে এই জাতীয় পৃষ্ঠাগুলি বাদ দিতে একটি ফিল্টার যোগ করার কথা বিবেচনা করুন৷

সবশেষে, এমনকি সমস্ত নির্বাচনের পক্ষপাতিত্বকে সম্বোধন করেও, এমন ঝুঁকি রয়েছে যে বেঁচে থাকার পক্ষপাত LCP উন্নতিগুলিকে RUM পরিসংখ্যানে অবনতির মতো দেখায়। এই নিবন্ধটি সেই ঝুঁকিটি ব্যাখ্যা করার জন্য একটি দুর্দান্ত কাজ করে, এবং এটি ঘটছে কিনা তা সনাক্ত করার জন্য পরিত্যাগের মেট্রিকের কিছু রূপ দেখার পরামর্শ দেয়।

পড়াশোনার আগে/পরে

সমসাময়িক অধ্যয়নের ফলাফলগুলিকে সমর্থন করার জন্য, SXG সক্ষম করার আগে এবং পরে LCP-এর তুলনা করা কার্যকর হতে পারে। উপরে উল্লিখিত সম্ভাব্য পক্ষপাত দূর করতে, SXG পৃষ্ঠা দর্শনের মধ্যে সীমাবদ্ধ করবেন না। পরিবর্তে, SXG-যোগ্য ফলাফল দেখুন—উপরের সেগমেন্টের সংজ্ঞা কিন্তু isSXG সীমাবদ্ধতা ছাড়াই।

মনে রাখবেন যে Google অনুসন্ধান আপনার সাইটের সমস্ত পৃষ্ঠাগুলিকে পুনরায় ক্রল করতে কয়েক সপ্তাহ পর্যন্ত সময় নিতে পারে, যাতে তাদের জন্য SXG সক্ষম করা হয়েছে তা সনাক্ত করতে। এই কয়েক সপ্তাহে, অন্যান্য সম্ভাব্য পক্ষপাত ঘটতে পারে:

• নতুন ব্রাউজার রিলিজ বা ব্যবহারকারীদের হার্ডওয়্যারের উন্নতি পৃষ্ঠা লোডের গতি বাড়িয়ে দিতে পারে।
• ছুটির মতো একটি উল্লেখযোগ্য ঘটনা স্বাভাবিক থেকে ট্রাফিককে কমিয়ে দিতে পারে।

উপরের অধ্যয়নগুলি নিশ্চিত করার জন্য আগে এবং পরে সামগ্রিক 75 তম পার্সেন্টাইল LCP দেখাও সহায়ক। জনসংখ্যার একটি উপসেট সম্পর্কে শেখা অগত্যা আমাদের সামগ্রিক জনসংখ্যা সম্পর্কে জানায় না। উদাহরণস্বরূপ, ধরা যাক SXG পৃষ্ঠা লোডের 10% 800ms দ্বারা উন্নত করে।

• যদি এইগুলি ইতিমধ্যেই 10% দ্রুততম পৃষ্ঠা লোড হয়ে থাকে, তাহলে এটি 75 তম পার্সেন্টাইলকে মোটেও প্রভাবিত করবে না৷
• যদি সেগুলি 10% সবচেয়ে ধীর পৃষ্ঠা লোড হয়, কিন্তু সেগুলি শুরুতে 75তম পার্সেন্টাইল LCP থেকে 800ms এর বেশি ধীর হয়, তাহলে এটি 75তম পার্সেন্টাইলকে মোটেও প্রভাবিত করবে না৷

এগুলি চরম উদাহরণ, সম্ভবত বাস্তবতার প্রতিফলন নয়, তবে আশা করি সমস্যাটি ব্যাখ্যা করে৷ অনুশীলনে, এটি সম্ভবত যে SXG বেশিরভাগ সাইটের 75 তম পার্সেন্টাইলকে প্রভাবিত করবে৷ ক্রস-সাইট নেভিগেশনগুলি সবচেয়ে ধীরগতির হতে থাকে এবং প্রিফেচিং থেকে উন্নতিগুলি উল্লেখযোগ্য হতে থাকে৷

কিছু ইউআরএল অপ্ট-আউট করুন

শেষ পর্যন্ত, SXG পারফরম্যান্সের তুলনা করার একটি উপায় হতে পারে আপনার সাইটের কিছু উপসেটের জন্য SXG অক্ষম করা। উদাহরণস্বরূপ, আপনি একটি CDN-Cache-Control: no-store হেডার৷ আমি এই বিরুদ্ধে সুপারিশ.

অন্যান্য অধ্যয়ন পদ্ধতির তুলনায় এটির সম্ভবত নির্বাচন পক্ষপাতের একটি বড় ঝুঁকি রয়েছে। উদাহরণস্বরূপ, আপনার সাইটের হোম পৃষ্ঠা বা একইভাবে জনপ্রিয় URL কন্ট্রোল গ্রুপ বা এক্সপেরিমেন্ট গ্রুপে নির্বাচন করা হোক না কেন এটি একটি বড় পার্থক্য করতে পারে।

হোল্ডব্যাক অধ্যয়ন

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

একটি হোল্ডব্যাক অধ্যয়নের নিম্নলিখিত বৈশিষ্ট্য রয়েছে:

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

এটি নির্বাচন পক্ষপাতের পূর্বোক্ত সম্ভাব্য উত্সগুলিকে দূর করবে, যদিও এটি LCP বেঁচে থাকার পক্ষপাতের ঝুঁকি দূর করবে না। এই উভয় বৈশিষ্ট্যগুলির জন্য ব্রাউজার বা রেফারারের সক্রিয় করার প্রয়োজন হয়।

উপসংহার

ফাউ! যে অনেক ছিল. আশা করি এটি একটি ল্যাব টেস্টে কীভাবে SXG কার্যকারিতা পরীক্ষা করা যায়, ল্যাব পরীক্ষার সাথে একটি শক্ত প্রতিক্রিয়া লুপে কীভাবে এর কার্যকারিতা অপ্টিমাইজ করা যায় এবং অবশেষে বাস্তব বিশ্বে কীভাবে এর কার্যকারিতা পরিমাপ করা যায় তার একটি আরও সম্পূর্ণ ছবি আঁকা। এই সবগুলিকে একত্রিত করা আপনাকে SXGs থেকে সর্বাধিক লাভ করতে সাহায্য করবে এবং নিশ্চিত করবে যে তারা আপনার সাইট এবং আপনার ব্যবহারকারীদের উপকার করছে৷

SXG পারফরম্যান্স কীভাবে ক্যাপচার করবেন সে সম্পর্কে আপনার অতিরিক্ত পরামর্শ থাকলে, অনুগ্রহ করে আমাদের জানান! আপনার প্রস্তাবিত উন্নতি সহ developer.chrome.com এর বিরুদ্ধে একটি বাগ ফাইল করুন ৷

স্বাক্ষরিত এক্সচেঞ্জ সম্পর্কে আরও তথ্যের জন্য, web.dev ডকুমেন্টেশন এবং Google অনুসন্ধান ডকুমেন্টেশন দেখুন।

কিভাবে সাইনড এক্সচেঞ্জ পরিমাপ এবং অপ্টিমাইজ করা যায় যাতে সেগুলির মধ্যে সর্বাধিক উন্নতি হয়৷

Devin Mullins

সাইনড এক্সচেঞ্জ (SXGs) হল আপনার পৃষ্ঠার গতি উন্নত করার একটি মাধ্যম—প্রধানত Largest Contentful Paint (LCP) । একটি পৃষ্ঠায় সাইটগুলি (বর্তমানে Google অনুসন্ধান) লিঙ্ক উল্লেখ করার সময়, ব্যবহারকারী লিঙ্কটিতে ক্লিক করার আগে তারা এটিকে ব্রাউজার ক্যাশে প্রিফেচ করতে পারে।

এমন ওয়েব পৃষ্ঠাগুলি তৈরি করা সম্ভব যেগুলি, যখন প্রিফেচ করা হয়, পৃষ্ঠাটি রেন্ডার করার জন্য গুরুত্বপূর্ণ পথে কোনও নেটওয়ার্কের প্রয়োজন হয় না! একটি 4G সংযোগে, এই পৃষ্ঠা লোড 2.8s থেকে 0.9s হয় (বাকি 0.9s বেশিরভাগই CPU ব্যবহার করে):

বেশিরভাগ লোকেরা আজ SXG প্রকাশ করছে তারা ক্লাউডফ্লেয়ারের সহজে ব্যবহারযোগ্য স্বয়ংক্রিয় স্বাক্ষরিত এক্সচেঞ্জ (ASX) বৈশিষ্ট্যটি ব্যবহার করছে (যদিও ওপেন সোর্স বিকল্পগুলিও বিদ্যমান):

অনেক ক্ষেত্রে, এই বৈশিষ্ট্যটি সক্ষম করার জন্য বাক্সটি চেক করাই উপরে দেখানো যথেষ্ট উন্নতির জন্য যথেষ্ট। কখনও কখনও, এই এসএক্সজিগুলি পাইপলাইনের প্রতিটি পর্যায়ে উদ্দেশ্য অনুসারে কাজ করছে তা নিশ্চিত করতে এবং প্রিফেচের সম্পূর্ণ সুবিধা নিতে পৃষ্ঠাগুলিকে অপ্টিমাইজ করতে আরও কয়েকটি পদক্ষেপ রয়েছে৷

ক্লাউডফ্লেয়ার চালু হওয়ার পর থেকে গত কয়েক মাসে, আমি বিভিন্ন ফোরামে প্রশ্নগুলি পড়ছি এবং উত্তর দিচ্ছি এবং কীভাবে সাইটগুলিকে তাদের SXG স্থাপনার থেকে সর্বাধিক সুবিধা পাচ্ছে তা নিশ্চিত করতে কীভাবে পরামর্শ দিতে হয় তা শিখছি। এই পোস্টটি আমার পরামর্শের একটি সংগ্রহ। আমি ধাপে ধাপে হাঁটব:

• WebPageTest ব্যবহার করে SXG কর্মক্ষমতা বিশ্লেষণ করুন ।
• SXG পাইপলাইন ডিবাগ করুন যদি বিশ্লেষণ ধাপ দেখায় যে এটি কাজ করছে না।
• একটি সর্বোত্তম max-age সেট করা এবং রেন্ডার-ব্লকিং সাবরিসোর্স প্রিলোড করা সহ SXG প্রিফেচের জন্য পৃষ্ঠাগুলি অপ্টিমাইজ করুন ৷
• উপযুক্ত পরীক্ষা এবং নিয়ন্ত্রণ গোষ্ঠী নির্বাচন করে Google Analytics ব্যবহার করে SXG উন্নতি পরিমাপ করুন ।

ভূমিকা

একটি SXG হল একটি ফাইল যাতে একটি URL, HTTP প্রতিক্রিয়া শিরোনামের একটি সেট এবং একটি প্রতিক্রিয়া বডি—সবই একটি ওয়েব PKI শংসাপত্র দ্বারা ক্রিপ্টোগ্রাফিকভাবে স্বাক্ষরিত। যখন ব্রাউজার একটি SXG লোড করে, তখন এটি এই সবগুলি যাচাই করে:

• SXG এর মেয়াদ শেষ হয়নি।
• স্বাক্ষরটি URL, শিরোনাম, মূল অংশ এবং শংসাপত্রের সাথে মেলে।
• শংসাপত্রটি বৈধ এবং URL এর সাথে মেলে৷

যাচাইকরণ ব্যর্থ হলে, ব্রাউজার SXG ত্যাগ করে এবং পরিবর্তে স্বাক্ষরিত URL নিয়ে আসে। যাচাইকরণ সফল হলে, ব্রাউজার স্বাক্ষরিত প্রতিক্রিয়া লোড করে, এটিকে এমনভাবে আচরণ করে যেন এটি সরাসরি স্বাক্ষরিত URL থেকে এসেছে। এটি SXG গুলিকে যেকোনো সার্ভারে পুনঃহোস্ট করার অনুমতি দেয় যতক্ষণ না এটি স্বাক্ষরিত হওয়ার পর থেকে মেয়াদ উত্তীর্ণ বা পরিবর্তন না হয়৷

Google অনুসন্ধানের ক্ষেত্রে, SXG তার অনুসন্ধান ফলাফলগুলিতে পৃষ্ঠাগুলির প্রিফেচিং সক্ষম করে ৷ SXG-কে সমর্থন করে এমন পৃষ্ঠাগুলির জন্য, Google অনুসন্ধান ওয়েবpkgcache.com-এ হোস্ট করা পৃষ্ঠার ক্যাশড কপি প্রিফেচ করতে পারে। এই webpkgcache.com URLগুলি পৃষ্ঠার প্রদর্শন বা আচরণকে প্রভাবিত করে না, কারণ ব্রাউজারটি আসল, স্বাক্ষরিত URLকে সম্মান করে৷ প্রিফেচিং আপনার পৃষ্ঠাকে অনেক দ্রুত লোড করতে সক্ষম করে।

বিশ্লেষণ করুন

SXG-এর সুবিধা দেখতে, পুনরাবৃত্তিযোগ্য পরিস্থিতিতে SXG কর্মক্ষমতা বিশ্লেষণ করতে একটি ল্যাব টুল ব্যবহার করে শুরু করুন। আপনি SXG প্রিফেচ সহ এবং ছাড়া জলপ্রপাত-এবং LCP-এর তুলনা করতে WebPageTest ব্যবহার করতে পারেন।

নিম্নরূপ SXG ছাড়া একটি পরীক্ষা তৈরি করুন:

• WebPageTest- এ যান এবং সাইন ইন করুন। সাইন ইন করলে পরবর্তীতে তুলনা করার জন্য আপনার পরীক্ষার ইতিহাস সংরক্ষণ করা হয়।
• আপনি পরীক্ষা করতে চান URL লিখুন.
• অ্যাডভান্সড কনফিগারেশনে যান। (এসএক্সজি পরীক্ষার জন্য আপনার অ্যাডভান্সড কনফিগারেশনের প্রয়োজন হবে, তাই এটি এখানে ব্যবহার করা নিশ্চিত করতে সহায়তা করে যে পরীক্ষার বিকল্পগুলি একই।)
• টেস্ট সেটিংস ট্যাবে, 4G-তে সংযোগ সেট করা এবং "চালাতে পরীক্ষার সংখ্যা" 7-এ বৃদ্ধি করা সহায়ক হতে পারে।
• স্টার্ট টেস্টে ক্লিক করুন।

উপরের মত একই ধাপগুলি ব্যবহার করে SXG-এর সাথে একটি পরীক্ষা তৈরি করুন, কিন্তু Start Test এ ক্লিক করার আগে, স্ক্রিপ্ট ট্যাবে যান, নিম্নলিখিত WebPageTest স্ক্রিপ্টে পেস্ট করুন এবং নির্দেশিত হিসাবে দুটি navigate URL পরিবর্তন করুন:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

প্রথম navigate URL-এর জন্য, যদি আপনার পৃষ্ঠাটি এখনও কোনো Google অনুসন্ধান ফলাফলে প্রদর্শিত না হয়, তাহলে আপনি এই উদ্দেশ্যে একটি প্রেন্ড সার্চ ফলাফল পৃষ্ঠা তৈরি করতে এই প্রিফেচ পৃষ্ঠাটি ব্যবহার করতে পারেন৷

দ্বিতীয় navigate URL নির্ধারণ করতে, SXG ভ্যালিডেটর ক্রোম এক্সটেনশন ব্যবহার করে আপনার পৃষ্ঠায় যান এবং ক্যাশে URL দেখতে এক্সটেনশন আইকনে ক্লিক করুন:

একবার এই পরীক্ষাগুলি সম্পূর্ণ হলে, টেস্ট ইতিহাসে যান, দুটি পরীক্ষা নির্বাচন করুন এবং তুলনা ক্লিক করুন:

তুলনা URL-এ &medianMetric=LCP যুক্ত করুন যাতে WebPageTest তুলনার প্রতিটি দিকের জন্য মধ্যম LCP সহ রান নির্বাচন করে। (স্পিড ইনডেক্স দ্বারা ডিফল্ট মাঝারি।)

জলপ্রপাতের তুলনা করতে, জলপ্রপাতের অস্বচ্ছতা বিভাগটি প্রসারিত করুন এবং স্লাইডারটি টেনে আনুন। ভিডিওটি দেখতে, ফিল্মস্ট্রিপ সেটিংস সামঞ্জস্য করুন- এ ক্লিক করুন, সেই ডায়ালগের ভিতরে স্ক্রোল করুন এবং ভিডিও দেখুন ক্লিক করুন।

যদি এসএক্সজি প্রিফেচ সফল হয় তবে আপনি দেখতে পাবেন যে "এসএক্সজি" জলপ্রপাতটি এইচটিএমএল -এর জন্য একটি সারি অন্তর্ভুক্ত করে না এবং সাব্রেসোর্সগুলির জন্য ফেচগুলি শীঘ্রই শুরু হয়। উদাহরণস্বরূপ, এখানে "আগে" এবং "পরে" তুলনা করুন:

ডিবাগ

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

প্রকাশনা

আপনার পৃষ্ঠাগুলি এসএক্সজি হিসাবে উত্পন্ন হচ্ছে তা নিশ্চিত করুন। এটি করার জন্য, আপনাকে ক্রলার হওয়ার ভান করতে হবে। সবচেয়ে সহজ উপায় হ'ল এসএক্সজি ভ্যালিডেটর ক্রোম এক্সটেনশন ব্যবহার করা:

এক্সটেনশনটি একটি Accept অনুরোধ শিরোনাম সহ বর্তমান ইউআরএলটি নিয়ে আসে যা বলে যে এটি এসএক্সজি সংস্করণটিকে পছন্দ করে। আপনি যদি উত্সের পাশের একটি চেক চিহ্ন (✅) দেখতে পান তবে তার অর্থ একটি এসএক্সজি ফিরে এসেছে; আপনি ইনডেক্সিং বিভাগে এড়িয়ে যেতে পারেন।

আপনি যদি কোনও ক্রস চিহ্ন (❌) দেখতে পান তবে এর অর্থ একটি এসএক্সজি ফেরত দেওয়া হয়নি:

যদি ক্লাউডফ্লেয়ার এএসএক্স সক্ষম করা থাকে তবে ক্রস মার্ক (❌) এর সবচেয়ে সম্ভবত কারণ হ'ল ক্যাশে নিয়ন্ত্রণ প্রতিক্রিয়া শিরোনাম এটি প্রতিরোধ করে। এএসএক্স নিম্নলিখিত নামগুলি সহ শিরোনামগুলি দেখায়:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

যদি এই শিরোনামগুলির মধ্যে কোনওটিতে নিম্নলিখিত শিরোনামের মানগুলির মধ্যে থাকে তবে এটি একটি এসএক্সজি উত্পন্ন হতে বাধা দেবে:

• private
• no-store
• no-cache
• max-age 120 এরও কম, যদি না s-maxage দ্বারা ওভাররাইড করা হয় 120 এর চেয়ে বেশি বা সমান

এএসএক্স এই ক্ষেত্রে একটি এসএক্সজি তৈরি করে না কারণ এসএক্সজিগুলি একাধিক পরিদর্শন এবং একাধিক দর্শকদের জন্য ক্যাশে এবং পুনরায় ব্যবহার করা যেতে পারে।

ক্রস মার্ক (❌) এর আরেকটি সম্ভাব্য কারণ হ'ল Set-Cookie বাদে এই রাষ্ট্রীয় প্রতিক্রিয়া শিরোনামগুলির মধ্যে একটি উপস্থিতি। এসএক্সজি স্পেসিফিকেশন মেনে চলার জন্য এএসএক্স Set-Cookie শিরোনামটি সরিয়ে দেয়।

আর একটি সম্ভাব্য কারণ হ'ল একটি Vary: Cookie প্রতিক্রিয়া শিরোনাম। গুগলবট ব্যবহারকারীর শংসাপত্র ছাড়াই এসএক্সজি আনতে পারে এবং একাধিক দর্শনার্থীদের তাদের পরিবেশন করতে পারে। আপনি যদি তাদের কুকির উপর ভিত্তি করে বিভিন্ন ব্যবহারকারীদের কাছে বিভিন্ন এইচটিএমএল পরিবেশন করেন তবে তারা লগ আউট ভিউয়ের মতো একটি ভুল অভিজ্ঞতা দেখতে পেল।

বিকল্পভাবে ক্রোম এক্সটেনশনে, আপনি curl মতো একটি সরঞ্জাম ব্যবহার করতে পারেন:

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

বা dump-signedexchange :

dump-signedexchange -verify -uri $URL

যদি এসএক্সজি উপস্থিত এবং বৈধ থাকে তবে আপনি এসএক্সজির একটি মানব পঠনযোগ্য প্রিন্টআউট দেখতে পাবেন। অন্যথায়, আপনি একটি ত্রুটি বার্তা দেখতে পাবেন।

ইনডেক্সিং

নিশ্চিত করুন যে আপনার এসএক্সজিগুলি সফলভাবে গুগল অনুসন্ধান দ্বারা সূচকযুক্ত রয়েছে। ক্রোম ডিভটুলগুলি খুলুন, তারপরে আপনার পৃষ্ঠার জন্য একটি গুগল অনুসন্ধান করুন। যদি এটি কোনও এসএক্সজি হিসাবে সূচকযুক্ত করা হয় তবে আপনার পৃষ্ঠায় গুগলের লিঙ্কটিতে ওয়েবপিকিজিএইচসিএইসি.কমের অনুলিপিটির দিকে নির্দেশ করে একটি data-sxg-url অন্তর্ভুক্ত থাকবে:

গুগল অনুসন্ধান যদি মনে করে যে ব্যবহারকারী সম্ভবত ফলাফলটিতে ক্লিক করতে পারে তবে এটি এটি প্রিফেচও করবে:

<link> উপাদানটি ব্রাউজারটিকে তার প্রিফেচ ক্যাশে এসএক্সজি ডাউনলোড করার নির্দেশ দেয়। যখন ব্যবহারকারী <a> উপাদানটিতে ক্লিক করেন, ব্রাউজারটি পৃষ্ঠাটি রেন্ডার করতে সেই ক্যাশেড এসএক্সজি ব্যবহার করবে।

আপনি ডেভটুলগুলিতে নেটওয়ার্ক ট্যাবে গিয়ে এবং webpkgcache সহ ইউআরএলগুলি অনুসন্ধান করে প্রিফেইচের প্রমাণও দেখতে পারেন।

যদি <a> ওয়েবপিকেজিসিএইসিএইচই.কমকে নির্দেশ করে তবে এর অর্থ স্বাক্ষরিত এক্সচেঞ্জের গুগল অনুসন্ধান সূচক কাজ করছে। আপনি ইনজেশন বিভাগে এগিয়ে যেতে পারেন।

অন্যথায়, এটি এমন হতে পারে যে আপনি এসএক্সজি সক্ষম করেছেন বলে গুগল আপনার পৃষ্ঠাটি এখনও পুনরায় তৈরি করতে পারেনি। গুগল অনুসন্ধান কনসোল ইউআরএল পরিদর্শন সরঞ্জামটি ব্যবহার করে দেখুন:

একটি digest: mi-sha256-03=... শিরোনাম নির্দেশ করে যে গুগল সফলভাবে এসএক্সজি সংস্করণটি ক্রল করেছে।

যদি কোনও digest শিরোনাম উপস্থিত না থাকে তবে এটি একটি ইঙ্গিত হতে পারে যে কোনও এসএক্সজি গুগলবোটকে পরিবেশন করা হয়নি বা আপনি এসএক্সজিএস সক্ষম করার পর থেকে সূচকটি আপডেট করা হয়নি।

যদি কোনও এসএক্সজি সফলভাবে ক্রল করা হয়, তবে এটি এখনও যুক্ত হচ্ছে না, তবে এটি এসএক্সজি ক্যাশে প্রয়োজনীয়তাগুলি পূরণ করতে ব্যর্থ হতে পারে। এগুলি পরবর্তী বিভাগে আচ্ছাদিত।

ইনজেশন

যখন গুগল অনুসন্ধান একটি এসএক্সজি সূচক করে, এটি গুগল এসএক্সজি ক্যাশে এর অনুলিপিটি প্রেরণ করে, যা ক্যাশে প্রয়োজনীয়তার বিরুদ্ধে এটি বৈধ করে। ক্রোম এক্সটেনশন ফলাফল দেখায়:

আপনি যদি একটি চেক চিহ্ন (✅) দেখতে পান তবে আপনি অনুকূল করতে এগিয়ে যেতে পারেন।

যদি এটি প্রয়োজনীয়তাগুলি পূরণ করতে ব্যর্থ হয় তবে আপনি একটি ক্রস মার্ক (❌) এবং একটি সতর্কতা বার্তা দেখতে পাবেন কেন তা নির্দেশ করে:

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

ক্যাশেড অনুলিপিটির মেয়াদ শেষ হয়ে গেছে এবং ব্যাকগ্রাউন্ডে পুনরায় তৈরি করা হচ্ছে এমন ইভেন্টে আপনি একটি ঘন্টাঘড়ি (⌛) দেখতে পাবেন:

এসএক্সজিতে গুগল বিকাশকারী নথিতে ম্যানুয়ালি ক্যাশে জিজ্ঞাসা করার জন্য নির্দেশাবলীও রয়েছে।

অপ্টিমাইজ করুন

যদি এসএক্সজি ভ্যালিডেটর ক্রোম এক্সটেনশন সমস্ত চেক চিহ্ন (✅) দেখায় তবে আপনার কাছে একটি এসএক্সজি রয়েছে যা ব্যবহারকারীদের পরিবেশন করা যেতে পারে! আপনার ওয়েব পৃষ্ঠাটি কীভাবে অনুকূল করতে হয় তা জানতে পড়ুন যাতে আপনি এসএক্সজি থেকে সর্বাধিক এলসিপি উন্নতি পান।

সর্বোচ্চ বয়স

যখন এসএক্সজিএসের মেয়াদ শেষ হয়ে যায়, গুগল এসএক্সজি ক্যাশে পটভূমিতে একটি নতুন অনুলিপি আনবে। এই আনার জন্য অপেক্ষা করার সময়, ব্যবহারকারীরা তার মূল হোস্টের পৃষ্ঠায় নির্দেশিত হয়, যা প্রিফেইচ করা হয় না। আপনি যত বেশি সময় Cache-Control: max-age , এই ব্যাকগ্রাউন্ড আনতে যত কম ঘন ঘন ঘটে থাকে এবং এইভাবে প্রায়শই এলসিপি প্রিফেচ দ্বারা হ্রাস করা যায়।

এটি পারফরম্যান্স এবং সতেজতার মধ্যে একটি ট্রেড অফ এবং ক্যাশে সাইটের মালিকদের প্রতিটি পৃষ্ঠার বিশেষ প্রয়োজনের সাথে ফিট করার জন্য 2 মিনিট থেকে 7 দিনের মধ্যে যে কোনও জায়গায় সর্বাধিক বয়সের সাথে এসএক্সজি সরবরাহ করতে দেয়। উপাখ্যানিকভাবে, আমরা এটি খুঁজে পাই:

• max-age=86400 (1 দিন) বা আর পারফরম্যান্সের জন্য ভাল কাজ করে
• max-age=120 (2 মিনিট) হয় না

আমরা এই দুজনের মধ্যে মানগুলি সম্পর্কে আরও শিখতে আশা করি, যেমন আমরা আরও ডেটা অধ্যয়ন করি।

ব্যবহারকারী-এজেন্ট

একসময়, আমি প্রিফেচড এসএক্সজি ব্যবহার করার সময় এলসিপি বৃদ্ধি দেখেছি। আমি ওয়েবপেজেস্টেস্ট চালিয়েছি, এসএক্সজি প্রিফেচ ছাড়াই এবং এর সাথে মিডিয়ান ফলাফলের তুলনা করে। নীচে পরে ক্লিক করা:

আমি দেখেছি যে প্রিফেচ কাজ করছে। এইচটিএমএল সমালোচনামূলক পথ থেকে সরানো হয় এবং এইভাবে, সমস্ত সাবরেসোর্স আগে লোড করতে সক্ষম হয়। তবে এলসিপি - যে সবুজ ড্যাশড লাইন - 2 এস থেকে 2.1s এ বৃদ্ধি পেয়েছে ।

এটি নির্ণয়ের জন্য, আমি ফিল্মের স্ট্রিপগুলির দিকে তাকালাম। আমি দেখতে পেয়েছি যে পৃষ্ঠাটি এসএক্সজিতে আলাদাভাবে রেন্ডার করেছে। সরল এইচটিএমএলে, ক্রোম নির্ধারণ করেছিলেন যে এলসিপির জন্য "বৃহত্তম উপাদান" শিরোনাম ছিল। যাইহোক, এসএক্সজি সংস্করণে, পৃষ্ঠাটি একটি অলস-বোঝা ব্যানার যুক্ত করেছে, যা ভাঁজের নীচে শিরোনামটি ঠেলে দেয় এবং নতুন বৃহত্তম উপাদানটিকে অলস-বোঝা কুকি সম্মতি সংলাপ হিসাবে পরিণত করে। আগের চেয়ে দ্রুত রেন্ডার করা সমস্ত কিছু, তবে লেআউটের পরিবর্তনের ফলে মেট্রিককে এটি ধীর হিসাবে রিপোর্ট করে।

আমি আরও গভীর খনন করেছি এবং লেআউটের পার্থক্যের কারণটি আবিষ্কার করেছি যে পৃষ্ঠাটি User-Agent দ্বারা পরিবর্তিত হয় এবং যুক্তিতে একটি ত্রুটি ছিল। এসএক্সজি ক্রল শিরোনাম মোবাইল নির্দেশিত সত্ত্বেও এটি একটি ডেস্কটপ পৃষ্ঠা পরিবেশন করছিল। এটি স্থির হওয়ার পরে, ব্রাউজারটি সঠিকভাবে পৃষ্ঠার শিরোনামটিকে তার বৃহত্তম উপাদান হিসাবে চিহ্নিত করেছে।

এখন, "পরে" ক্লিক করে, আমি দেখেছি যে প্রিফ্যাচড এলসিপি 1.3s এ নেমেছে :

এসএক্সজিগুলি সমস্ত ফর্ম ফ্যাক্টরের জন্য সক্ষম করা হয়। এর জন্য প্রস্তুত করার জন্য, এর মধ্যে একটি সত্য তা নিশ্চিত করুন:

• আপনার পৃষ্ঠাটি User-Agent দ্বারা Vary হয় না (যেমন এটি প্রতিক্রিয়াশীল নকশা বা পৃথক মোবাইল/ডেস্কটপ ইউআরএল ব্যবহার করে)।
• যদি আপনার পৃষ্ঠাটি গতিশীল পরিবেশন ব্যবহার করে তবে এটি নিজেকে <meta name=supported-media content=...> ব্যবহার করে মোবাইল- বা ডেস্কটপ হিসাবে টীকা দেয়।

উপসম্পদ

এসএক্সজিগুলি এইচটিএমএল সহ সাব্রেসোর্সগুলি (চিত্র সহ) প্রিফেচ করতে ব্যবহার করা যেতে পারে। ক্লাউডফ্লেয়ার এএসএক্স একই-উত্স (প্রথম পক্ষের) <link rel=preload> উপাদানগুলির জন্য এইচটিএমএল স্ক্যান করবে এবং তাদেরকে এসএক্সজি-সামঞ্জস্যপূর্ণ লিঙ্ক শিরোনামগুলিতে রূপান্তর করবে। উত্স কোড এখানে এবং এখানে বিশদ।

যদি এটি কাজ করে তবে আপনি গুগল অনুসন্ধান থেকে অতিরিক্ত প্রিফেচ দেখতে পাবেন:

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

গুগল এসএক্সজি ক্যাশে 20 টি পর্যন্ত সাবরেসোর্স প্রিলোডের অনুমতি দেয় এবং এএসএক্স নিশ্চিত করে যে এই সীমাটি অতিক্রম করা হয়নি। তবে অনেকগুলি সাব্রেসোর্স প্রিলোড যুক্ত করার ঝুঁকি রয়েছে। ক্রস-সাইট ট্র্যাকিং প্রতিরোধের জন্য ব্রাউজারটি কেবল প্রিলোডড সাবরেসোর্সগুলি ব্যবহার করবে যদি তাদের সবাই আনতে শেষ করে। সেখানে যত বেশি সাব্রেসোর্স রয়েছে, ব্যবহারকারী আপনার পৃষ্ঠায় ক্লিক করার আগে তাদের সমস্তগুলিই প্রিফেচিং শেষ করবে।

এসএক্সজি ভ্যালিডেটর বর্তমানে সাবরেসোর্সগুলি পরীক্ষা করে না; ডিবাগ করতে, এর মধ্যে curl বা dump-signedexchange ব্যবহার করুন।

পরিমাপ

ওয়েবপেজেস্টেস্টের অধীনে এলসিপি উন্নতি অনুকূলকরণের পরে, আপনার সাইটের সামগ্রিক পারফরম্যান্সে এসএক্সজি প্রিফেচিংয়ের প্রভাব পরিমাপ করা দরকারী।

সার্ভার-সাইড মেট্রিক

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

ক্লায়েন্ট-সাইড মেট্রিক

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

পরিবর্তে, আমি সম্ভাব্যভাবে প্রভাবিত পৃষ্ঠা লোডগুলিতে "জুম ইন" করা এবং এটি ফ্রেম হিসাবে এটি সহায়ক বলে মনে করি, "এসএক্সজিগুলি পৃষ্ঠা ভিউগুলির x% কে প্রভাবিত করে, 75 তম পার্সেন্টাইলের ওয়াই মিলিসেকেন্ড দ্বারা তাদের এলসিপিকে উন্নত করে" "

বর্তমানে, এসএক্সজি প্রিফেচ কেবল নির্দিষ্ট শর্তে ঘটে:

• ক্রোমিয়াম ব্রাউজার (যেমন আইওএস ব্যতীত ক্রোম বা প্রান্ত), সংস্করণ এম 98 বা উচ্চতর
• Referer: google.com বা অন্যান্য গুগল অনুসন্ধান ডোমেন । (দ্রষ্টব্য যে গুগল অ্যানালিটিক্সে, একটি রেফারেল ট্যাগ সেশনের সমস্ত পৃষ্ঠার দর্শনগুলিতে প্রযোজ্য, যেখানে এসএক্সজি প্রিফেচ কেবল প্রথম পৃষ্ঠার ভিউতে প্রযোজ্য, গুগল অনুসন্ধান থেকে সরাসরি সংযুক্ত))

"পৃষ্ঠা ভিউগুলির x%" এবং "ওয়াই মিলিসেকেন্ডস দ্বারা তাদের এলসিপিকে উন্নত করা" কীভাবে পরিমাপ করা যায় তার জন্য সমসাময়িক অধ্যয়ন বিভাগটি পড়ুন।

সমসাময়িক অধ্যয়ন

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

• আইওএস ডিভাইসগুলি: এই ডিভাইসগুলি রয়েছে এমন ব্যবহারকারীদের মধ্যে হার্ডওয়্যার বা নেটওয়ার্ক গতির পার্থক্যের কারণে।
• পুরানো ক্রোমিয়াম ব্রাউজার: একই কারণে।
• ডেস্কটপ ডিভাইসগুলি: একই কারণে বা পৃষ্ঠা বিন্যাসের কারণে একটি আলাদা "বৃহত্তম উপাদান" বেছে নেওয়া হয়।
• একই সাইট নেভিগেশন (সাইটের মধ্যে লিঙ্কগুলি অনুসরণ করে দর্শনার্থীরা): কারণ তারা পূর্ববর্তী পৃষ্ঠার লোড থেকে ক্যাশেড সাব্রেসোর্সগুলি পুনরায় ব্যবহার করতে পারে।

গুগল অ্যানালিটিক্সে (ইউএ), স্কোপ "হিট" দিয়ে দুটি কাস্টম মাত্রা তৈরি করুন , একটি "আইএসএসএক্সজি" নামে একটি এবং একটি "রেফারার" নামে একটি। (অন্তর্নির্মিত "উত্স" মাত্রার সেশন স্কোপ রয়েছে, সুতরাং এটি একই সাইট নেভিগেশনগুলি বাদ দেয় না))

নিম্নলিখিত ফিল্টারগুলির সাথে "এসএক্সজি কাউন্টারফ্যাক্টুয়াল" নামে একটি কাস্টম বিভাগ তৈরি করুন:

• referrer https://www.google.
• Browser হুবহু Chrome সাথে মেলে
• Browser সংস্করণটি রেজেক্সের সাথে মেলে ^(9[8-9]|[0-9]{3})
• isSXG হুবহু false মেলে

isSXG ব্যতীত "এসএক্সজি" নামে এই বিভাগটির একটি অনুলিপি তৈরি করুন, ঠিক true সাথে মেলে।

আপনার সাইটের টেমপ্লেটে, গুগল অ্যানালিটিক্স স্নিপেটের উপরে নিম্নলিখিত স্নিপেট যুক্ত করুন। এটি একটি বিশেষ সিনট্যাক্স যা এসএক্সজি তৈরি করার সময় এএসএক্স true false পরিবর্তন করবে:

<script data-issxg-var>window.isSXG=false</script>

এলসিপি রেকর্ড করার জন্য প্রস্তাবিত হিসাবে আপনার গুগল অ্যানালিটিক্স রিপোর্টিং স্ক্রিপ্টটি কাস্টমাইজ করুন। আপনি যদি জিটিএজি.জেএস ব্যবহার করছেন, কাস্টম ডাইমেনশন সেট করতে 'config' কমান্ডটি সংশোধন করুন (গুগল অ্যানালিটিক্স যে নামগুলি ব্যবহার করতে বলেছে তার সাথে 'dimension1' এবং 'dimension2' প্রতিস্থাপন করে):

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

আপনি যদি অ্যানালিটিক্স.জেএস ব্যবহার করছেন তবে এখানে নথিভুক্ত হিসাবে 'create' কমান্ডটি সংশোধন করুন।

কিছু ডেটা সংগ্রহ করার জন্য কয়েক দিন অপেক্ষা করার পরে, গুগল অ্যানালিটিক্স ইভেন্টের প্রতিবেদনে যান এবং এসএক্সজি বিভাগের জন্য একটি ড্রিলডাউন যুক্ত করুন। এটি "এসএক্সজিএস পৃষ্ঠার ভিউগুলির x% প্রভাবিত করে" এর জন্য এক্সটি পূরণ করা উচিত:

অবশেষে, ওয়েব ভাইটালস রিপোর্টে যান, "বিভাগগুলি নির্বাচন করুন" নির্বাচন করুন এবং "এসএক্সজি কাউন্টারফ্যাক্টুয়াল" এবং "এসএক্সজি" নির্বাচন করুন।

"জমা দিন" ক্লিক করুন এবং আপনার দুটি বিভাগের জন্য এলসিপি বিতরণ দেখতে হবে। এটি "75 তম পার্সেন্টাইল এ ওয়াই মিলিসেকেন্ড দ্বারা তাদের এলসিপির উন্নতি করার জন্য" ওয়াই পূরণ করা উচিত:

সতর্কতা

একবার আপনি উপরের সমস্ত ফিল্টার প্রয়োগ করার পরে, এসএক্সজি কাউন্টারফ্যাক্টুয়াল পৃষ্ঠা লোডগুলিতে এই জাতীয় জিনিস থাকা উচিত:

• ক্যাশে মিস করে: গুগল এসএক্সজি ক্যাশে যদি প্রদত্ত ইউআরএল এর জন্য এসএক্সজির একটি নতুন অনুলিপি না থাকে তবে এটি আপনার সাইটে মূল ইউআরএলটিতে পুনর্নির্দেশ করবে।
• অন্যান্য ফলাফলের ধরণ: বর্তমানে, গুগল অনুসন্ধান কেবল স্ট্যান্ডার্ড ওয়েব ফলাফল এবং অন্যান্য কয়েকটি ধরণের জন্য এসএক্সজি সমর্থন করে। অন্যরা, বৈশিষ্ট্যযুক্ত স্নিপেটস এবং শীর্ষ গল্পগুলি ক্যারোসেলের মতো আপনার সাইটে মূল ইউআরএল -এর সাথে লিঙ্ক করবে।
• অযোগ্য ইউআরএল: যদি আপনার সাইটে কিছু পৃষ্ঠাগুলি এসএক্সজির জন্য যোগ্য না হয় (যেমন তারা ক্যাশেযোগ্য নয়) তবে তারা এই সেটটিতে উপস্থিত হতে পারে।

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

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

শেষ অবধি, এমনকি সমস্ত নির্বাচনের পক্ষপাতিত্বকেও সম্বোধন করা, এমন ঝুঁকি রয়েছে যে বেঁচে থাকা পক্ষপাত এলসিপি উন্নতিগুলি রম পরিসংখ্যানগুলিতে অবক্ষয়ের মতো দেখায়। এই নিবন্ধটি সেই ঝুঁকিটি ব্যাখ্যা করার একটি দুর্দান্ত কাজ করে এবং এটি ঘটছে কিনা তা সনাক্ত করার জন্য কিছু ফর্ম বিসর্জন মেট্রিকের দিকে তাকানোর পরামর্শ দেয়।

অধ্যয়নের আগে/পরে

সমসাময়িক অধ্যয়ন থেকে ফলাফলগুলি সংশোধন করতে, এসএক্সজি সক্ষম করার আগে এবং পরে এলসিপির তুলনা করা কার্যকর হতে পারে। উপরে উল্লিখিত সম্ভাব্য পক্ষপাতগুলি দূর করতে, এসএক্সজি পৃষ্ঠার দর্শনগুলিতে সীমাবদ্ধ করবেন না। পরিবর্তে, এসএক্সজি-যোগ্য ফলাফলগুলি দেখুন-উপরের বিভাগের সংজ্ঞাগুলি তবে isSXG সীমাবদ্ধতা ছাড়াই।

নোট করুন যে গুগল অনুসন্ধানগুলি আপনার সাইটের সমস্ত পৃষ্ঠাগুলি পুনরায় নিয়োগ করতে বেশ কয়েক সপ্তাহ সময় নিতে পারে, যাতে সনাক্ত করতে যে এসএক্সজি তাদের জন্য সক্ষম হয়েছে। এই কয়েক সপ্তাহের মধ্যে, অন্যান্য সম্ভাব্য পক্ষপাতগুলি ঘটতে পারে:

• নতুন ব্রাউজার রিলিজ বা ব্যবহারকারীদের হার্ডওয়্যারগুলিতে উন্নতি পৃষ্ঠা লোডগুলিকে গতি বাড়িয়ে তুলতে পারে।
• ছুটির মতো একটি উল্লেখযোগ্য ঘটনা স্বাভাবিক থেকে ট্র্যাফিক স্কিউ করতে পারে।

উপরোক্ত অধ্যয়নগুলি নিশ্চিত করার জন্য এটি আগে এবং পরে সামগ্রিক 75 তম পার্সেন্টাইল এলসিপি দেখতে সহায়ক। জনসংখ্যার একটি উপসেট সম্পর্কে শেখা অগত্যা আমাদের সামগ্রিক জনসংখ্যার কথা বলে না। উদাহরণস্বরূপ, ধরা যাক এসএক্সজি 800 মিমি দ্বারা পৃষ্ঠা লোডগুলির 10% উন্নত করে।

• যদি এগুলি ইতিমধ্যে 10% দ্রুততম পৃষ্ঠার লোড হয় তবে এটি 75 তম পার্সেন্টাইলকে মোটেই প্রভাবিত করবে না।
• যদি তারা 10% ধীরতম পৃষ্ঠা লোড হয় তবে তারা 75 তম পার্সেন্টাইল এলসিপির চেয়ে 800 মিমি বেশি ধীর ছিল, তবে এটি 75 তম পার্সেন্টাইলকে মোটেই প্রভাবিত করবে না।

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

কিছু urls অপ্ট আউট

শেষ অবধি, এসএক্সজি পারফরম্যান্সের তুলনা করার একটি উপায় হ'ল আপনার সাইটে ইউআরএলগুলির কয়েকটি উপসেটের জন্য এসএক্সজি অক্ষম করা। উদাহরণস্বরূপ, আপনি একটি CDN-Cache-Control: no-store শিরোনাম। আমি এই বিরুদ্ধে সুপারিশ।

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

হোল্ডব্যাক অধ্যয়ন

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

একটি হোল্ডব্যাক স্টাডিতে নিম্নলিখিত বৈশিষ্ট্য রয়েছে:

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

এটি নির্বাচনের পক্ষপাতিত্বের উপরোক্ত সম্ভাব্য উত্সগুলি দূর করবে, যদিও এটি এলসিপি বেঁচে থাকার পক্ষপাতিত্বের ঝুঁকি দূর করবে না। এই উভয় বৈশিষ্ট্যই সক্ষম করার জন্য ব্রাউজার বা রেফারার প্রয়োজন।

উপসংহার

ফাউ! যে অনেক ছিল. আশা করি এটি কোনও ল্যাব পরীক্ষায় কীভাবে এসএক্সজি পারফরম্যান্স পরীক্ষা করতে হবে, ল্যাব টেস্টের সাথে একটি শক্ত প্রতিক্রিয়া লুপে কীভাবে তার পারফরম্যান্সটি অনুকূল করতে হবে এবং অবশেষে বাস্তব বিশ্বে এর কার্যকারিতা কীভাবে পরিমাপ করা যায় তার আরও সম্পূর্ণ চিত্র এঁকে দেয়। এই সমস্ত কিছু একসাথে রাখার ফলে আপনাকে এসএক্সজি থেকে সর্বাধিক উপার্জন করতে সহায়তা করা উচিত এবং তারা আপনার সাইট এবং আপনার ব্যবহারকারীদের উপকৃত হচ্ছে তা নিশ্চিত করে।

কীভাবে এসএক্সজি পারফরম্যান্স ক্যাপচার করবেন সে সম্পর্কে আপনার যদি অতিরিক্ত পরামর্শ থাকে তবে দয়া করে আমাদের জানান! আপনার প্রস্তাবিত উন্নতি সহ বিকাশকারী.ক্রোম ডট কমের বিরুদ্ধে একটি বাগ ফাইল করুন ।

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

এগুলির মধ্যে সর্বাধিক উন্নতি পেতে স্বাক্ষরিত এক্সচেঞ্জগুলি কীভাবে পরিমাপ এবং অনুকূল করতে হয়

Devin Mullins

স্বাক্ষরিত এক্সচেঞ্জগুলি (এসএক্সজিএস) আপনার পৃষ্ঠার গতি উন্নত করার একটি মাধ্যম - মূলত বৃহত্তম সামগ্রী সামগ্রী পেইন্ট (এলসিপি) । কোনও পৃষ্ঠায় সাইটগুলি (বর্তমানে গুগল অনুসন্ধান) লিঙ্কটি উল্লেখ করার সময় তারা ব্যবহারকারী লিঙ্কটিতে ক্লিক করার আগে তারা এটিকে ব্রাউজার ক্যাশে প্রিফেচ করতে পারে।

ওয়েব পৃষ্ঠাগুলি তৈরি করা সম্ভব যে, যখন প্রিফেচ করা হয়, পৃষ্ঠাটি রেন্ডার করার জন্য সমালোচনামূলক পথে কোনও নেটওয়ার্কের প্রয়োজন নেই! একটি 4 জি সংযোগে, এই পৃষ্ঠার লোডটি 2.8s থেকে 0.9s (বাকি 0.9s বেশিরভাগ সিপিইউ ব্যবহার দ্বারা) যায় :

বেশিরভাগ লোক আজ এসএক্সজি প্রকাশ করে ক্লাউডফ্লেয়ারের সহজেই ব্যবহারযোগ্য স্বয়ংক্রিয় স্বাক্ষরিত এক্সচেঞ্জগুলি (এএসএক্স) বৈশিষ্ট্যটি ব্যবহার করছে (যদিও ওপেন সোর্স বিকল্পগুলিও বিদ্যমান):

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

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

• ওয়েবপেজেস্টেস্ট ব্যবহার করে এসএক্সজি পারফরম্যান্স বিশ্লেষণ করুন ।
• যদি বিশ্লেষণ পদক্ষেপটি দেখায় যে এটি কাজ করছে না বলে এসএক্সজি পাইপলাইনটি ডিবাগ করুন ।
• একটি অনুকূল max-age সেট করা এবং প্রিলোডিং রেন্ডার-ব্লকিং সাব্রেসোর্সগুলি সেট সহ এসএক্সজি প্রিফেচের জন্য পৃষ্ঠাগুলি অনুকূল করুন ।
• উপযুক্ত পরীক্ষা এবং নিয়ন্ত্রণ গ্রুপগুলি নির্বাচন করে গুগল অ্যানালিটিক্স ব্যবহার করে এসএক্সজি উন্নতি পরিমাপ করুন ।

ভূমিকা

একটি এসএক্সজি হ'ল একটি ফাইল যা একটি ইউআরএল, এইচটিটিপি প্রতিক্রিয়া শিরোনামগুলির একটি সেট এবং একটি প্রতিক্রিয়া বডি - সমস্ত ওয়েব পিকেআই শংসাপত্র দ্বারা স্বাক্ষরিত সমস্ত ক্রিপ্টোগ্রাফিক। যখন ব্রাউজারটি একটি এসএক্সজি লোড করে, এটি এগুলি সমস্ত যাচাই করে:

• এসএক্সজির মেয়াদ শেষ হয়নি।
• স্বাক্ষরটি ইউআরএল, শিরোনাম, দেহ এবং শংসাপত্রের সাথে মেলে।
• শংসাপত্রটি বৈধ এবং URL এর সাথে মেলে।

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

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

বিশ্লেষণ করুন

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

নিম্নরূপে এসএক্সজি ছাড়াই একটি পরীক্ষা তৈরি করুন:

• ওয়েবপেজেস্টেস্টে যান এবং সাইন ইন করুন signing পরে সাইন ইন করা আপনার পরীক্ষার ইতিহাসকে সহজ তুলনা করার জন্য সংরক্ষণ করে।
• আপনি যে ইউআরএল পরীক্ষা করতে চান তা প্রবেশ করান।
• উন্নত কনফিগারেশনে যান। (আপনার এসএক্সজি পরীক্ষার জন্য উন্নত কনফিগারেশন প্রয়োজন হবে, সুতরাং এটি এখানে ব্যবহার করা পরীক্ষার বিকল্পগুলি একই কিনা তা নিশ্চিত করতে সহায়তা করে))
• পরীক্ষার সেটিংস ট্যাবে, 4 জি এর সাথে সংযোগ স্থাপন এবং "চালানোর জন্য পরীক্ষার সংখ্যা" থেকে 7 থেকে বাড়ানো সহায়ক হতে পারে।
• স্টার্ট টেস্টে ক্লিক করুন।

উপরের মতো একই পদক্ষেপগুলি ব্যবহার করে এসএক্সজির সাথে একটি পরীক্ষা তৈরি করুন, তবে স্টার্ট টেস্টে ক্লিক করার আগে, স্ক্রিপ্ট ট্যাবে যান, নিম্নলিখিত ওয়েবপেজেটেস্ট স্ক্রিপ্টে পেস্ট করুন এবং নির্দেশিত হিসাবে দুটি navigate ইউআরএল সংশোধন করুন:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

প্রথম navigate ইউআরএল -এর জন্য, যদি আপনার পৃষ্ঠাটি এখনও কোনও গুগল অনুসন্ধানের ফলাফলগুলিতে উপস্থিত না হয় তবে আপনি এই উদ্দেশ্যে অনুসন্ধান ফলাফল পৃষ্ঠা তৈরি করতে এই প্রিফেচ পৃষ্ঠাটি ব্যবহার করতে পারেন।

দ্বিতীয় navigate ইউআরএল নির্ধারণ করতে, এসএক্সজি ভ্যালিডেটর ক্রোম এক্সটেনশন ব্যবহার করে আপনার পৃষ্ঠাটি দেখুন এবং ক্যাশে ইউআরএল দেখতে এক্সটেনশন আইকনটি ক্লিক করুন:

এই পরীক্ষাগুলি সম্পূর্ণ হয়ে গেলে, পরীক্ষার ইতিহাসে যান, দুটি পরীক্ষা নির্বাচন করুন এবং তুলনা ক্লিক করুন:

তুলনা &medianMetric=LCP তুলনা ইউআরএল এর সাথে তাই ওয়েবপেজেস্টেস্ট তুলনার প্রতিটি পক্ষের জন্য মিডিয়ান এলসিপি সহ রান নির্বাচন করে। (ডিফল্টটি স্পিড ইনডেক্স অনুসারে মধ্যস্থতা))

জলপ্রপাতের তুলনা করতে, জলপ্রপাতের অস্বচ্ছতা বিভাগটি প্রসারিত করুন এবং স্লাইডারটি টেনে আনুন। ভিডিওটি দেখতে, ফিল্মস্ট্রিপ সেটিংস সামঞ্জস্য করুন, সেই কথোপকথনের ভিতরে স্ক্রোল করুন এবং ভিডিও দেখুন ক্লিক করুন।

যদি এসএক্সজি প্রিফেচ সফল হয় তবে আপনি দেখতে পাবেন যে "এসএক্সজি" জলপ্রপাতটি এইচটিএমএল -এর জন্য একটি সারি অন্তর্ভুক্ত করে না এবং সাব্রেসোর্সগুলির জন্য ফেচগুলি শীঘ্রই শুরু হয়। উদাহরণস্বরূপ, এখানে "আগে" এবং "পরে" তুলনা করুন:

ডিবাগ

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

প্রকাশনা

আপনার পৃষ্ঠাগুলি এসএক্সজি হিসাবে উত্পন্ন হচ্ছে তা নিশ্চিত করুন। এটি করার জন্য, আপনাকে ক্রলার হওয়ার ভান করতে হবে। সবচেয়ে সহজ উপায় হ'ল এসএক্সজি ভ্যালিডেটর ক্রোম এক্সটেনশন ব্যবহার করা:

এক্সটেনশনটি একটি Accept অনুরোধ শিরোনাম সহ বর্তমান ইউআরএলটি নিয়ে আসে যা বলে যে এটি এসএক্সজি সংস্করণটিকে পছন্দ করে। আপনি যদি উত্সের পাশের একটি চেক চিহ্ন (✅) দেখতে পান তবে তার অর্থ একটি এসএক্সজি ফিরে এসেছে; আপনি ইনডেক্সিং বিভাগে এড়িয়ে যেতে পারেন।

আপনি যদি কোনও ক্রস চিহ্ন (❌) দেখতে পান তবে এর অর্থ একটি এসএক্সজি ফেরত দেওয়া হয়নি:

যদি ক্লাউডফ্লেয়ার এএসএক্স সক্ষম করা থাকে তবে ক্রস মার্ক (❌) এর সবচেয়ে সম্ভবত কারণ হ'ল ক্যাশে নিয়ন্ত্রণ প্রতিক্রিয়া শিরোনাম এটি প্রতিরোধ করে। এএসএক্স নিম্নলিখিত নামগুলি সহ শিরোনামগুলি দেখায়:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

যদি এই শিরোনামগুলির মধ্যে কোনওটিতে নিম্নলিখিত শিরোনামের মানগুলির মধ্যে থাকে তবে এটি একটি এসএক্সজি উত্পন্ন হতে বাধা দেবে:

• private
• no-store
• no-cache
• max-age 120 এরও কম, যদি না s-maxage দ্বারা ওভাররাইড করা হয় 120 এর চেয়ে বেশি বা সমান

এএসএক্স এই ক্ষেত্রে একটি এসএক্সজি তৈরি করে না কারণ এসএক্সজিগুলি একাধিক পরিদর্শন এবং একাধিক দর্শকদের জন্য ক্যাশে এবং পুনরায় ব্যবহার করা যেতে পারে।

ক্রস মার্ক (❌) এর আরেকটি সম্ভাব্য কারণ হ'ল Set-Cookie বাদে এই রাষ্ট্রীয় প্রতিক্রিয়া শিরোনামগুলির মধ্যে একটি উপস্থিতি। এসএক্সজি স্পেসিফিকেশন মেনে চলার জন্য এএসএক্স Set-Cookie শিরোনামটি সরিয়ে দেয়।

আর একটি সম্ভাব্য কারণ হ'ল একটি Vary: Cookie প্রতিক্রিয়া শিরোনাম। গুগলবট ব্যবহারকারীর শংসাপত্র ছাড়াই এসএক্সজি আনতে পারে এবং একাধিক দর্শনার্থীদের তাদের পরিবেশন করতে পারে। আপনি যদি তাদের কুকির উপর ভিত্তি করে বিভিন্ন ব্যবহারকারীদের কাছে বিভিন্ন এইচটিএমএল পরিবেশন করেন তবে তারা লগ আউট ভিউয়ের মতো একটি ভুল অভিজ্ঞতা দেখতে পেল।

বিকল্পভাবে ক্রোম এক্সটেনশনে, আপনি curl মতো একটি সরঞ্জাম ব্যবহার করতে পারেন:

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

বা dump-signedexchange :

dump-signedexchange -verify -uri $URL

যদি এসএক্সজি উপস্থিত এবং বৈধ থাকে তবে আপনি এসএক্সজির একটি মানব পঠনযোগ্য প্রিন্টআউট দেখতে পাবেন। অন্যথায়, আপনি একটি ত্রুটি বার্তা দেখতে পাবেন।

ইনডেক্সিং

নিশ্চিত করুন যে আপনার এসএক্সজিগুলি সফলভাবে গুগল অনুসন্ধান দ্বারা সূচকযুক্ত রয়েছে। ক্রোম ডিভটুলগুলি খুলুন, তারপরে আপনার পৃষ্ঠার জন্য একটি গুগল অনুসন্ধান করুন। যদি এটি কোনও এসএক্সজি হিসাবে সূচকযুক্ত করা হয় তবে আপনার পৃষ্ঠায় গুগলের লিঙ্কটিতে ওয়েবপিকিজিএইচসিএইসি.কমের অনুলিপিটির দিকে নির্দেশ করে একটি data-sxg-url অন্তর্ভুক্ত থাকবে:

গুগল অনুসন্ধান যদি মনে করে যে ব্যবহারকারী সম্ভবত ফলাফলটিতে ক্লিক করতে পারে তবে এটি এটি প্রিফেচও করবে:

<link> উপাদানটি ব্রাউজারটিকে তার প্রিফেচ ক্যাশে এসএক্সজি ডাউনলোড করার নির্দেশ দেয়। যখন ব্যবহারকারী <a> উপাদানটিতে ক্লিক করেন, ব্রাউজারটি পৃষ্ঠাটি রেন্ডার করতে সেই ক্যাশেড এসএক্সজি ব্যবহার করবে।

আপনি ডেভটুলগুলিতে নেটওয়ার্ক ট্যাবে গিয়ে এবং webpkgcache সহ ইউআরএলগুলি অনুসন্ধান করে প্রিফেইচের প্রমাণও দেখতে পারেন।

যদি <a> ওয়েবপিকেজিসিএইসিএইচই.কমকে নির্দেশ করে তবে এর অর্থ স্বাক্ষরিত এক্সচেঞ্জের গুগল অনুসন্ধান সূচক কাজ করছে। আপনি ইনজেশন বিভাগে এগিয়ে যেতে পারেন।

অন্যথায়, এটি এমন হতে পারে যে আপনি এসএক্সজি সক্ষম করেছেন বলে গুগল আপনার পৃষ্ঠাটি এখনও পুনরায় তৈরি করতে পারেনি। গুগল অনুসন্ধান কনসোল ইউআরএল পরিদর্শন সরঞ্জামটি ব্যবহার করে দেখুন:

একটি digest: mi-sha256-03=... শিরোনাম নির্দেশ করে যে গুগল সফলভাবে এসএক্সজি সংস্করণটি ক্রল করেছে।

যদি কোনও digest শিরোনাম উপস্থিত না থাকে তবে এটি একটি ইঙ্গিত হতে পারে যে কোনও এসএক্সজি গুগলবোটকে পরিবেশন করা হয়নি বা আপনি এসএক্সজিএস সক্ষম করার পর থেকে সূচকটি আপডেট করা হয়নি।

যদি কোনও এসএক্সজি সফলভাবে ক্রল করা হয়, তবে এটি এখনও যুক্ত হচ্ছে না, তবে এটি এসএক্সজি ক্যাশে প্রয়োজনীয়তাগুলি পূরণ করতে ব্যর্থ হতে পারে। এগুলি পরবর্তী বিভাগে আচ্ছাদিত।

ইনজেশন

যখন গুগল অনুসন্ধান একটি এসএক্সজি সূচক করে, এটি গুগল এসএক্সজি ক্যাশে এর অনুলিপিটি প্রেরণ করে, যা ক্যাশে প্রয়োজনীয়তার বিরুদ্ধে এটি বৈধ করে। ক্রোম এক্সটেনশন ফলাফল দেখায়:

আপনি যদি একটি চেক চিহ্ন (✅) দেখতে পান তবে আপনি অনুকূল করতে এগিয়ে যেতে পারেন।

If it fails to meet the requirements, you will see a cross mark (❌) and a warning message indicating why:

In this event, the page will work just as it did before enabling SXG. Google will link to the page on its original host without an SXG prefetch.

In the event that the cached copy has expired and is being re-fetched in the background, you will see an hourglass (⌛):

The Google developer document on SXG also has instructions for querying the cache manually .

অপ্টিমাইজ করুন

If the SXG Validator Chrome extension shows all check marks (✅), you have a SXG that can be served to users! Read on to find out how to optimize your web page so that you get the most LCP improvement from SXG.

সর্বোচ্চ বয়স

When SXGs expire, the Google SXG Cache will fetch a new copy in the background. While waiting for that fetch, users are directed to the page on its original host, which is not prefetched. The longer you set Cache-Control: max-age , the less often this background fetch happens, and thus the more often that LCP can be reduced by prefetch.

This is a tradeoff between performance and freshness, and the cache allows site owners to provide SXGs with a max-age anywhere between 2 minutes and 7 days, to fit each page's particular needs. Anecdotally, we find that:

• max-age=86400 (1 day) or longer works well for performance
• max-age=120 (2 minutes) does not

We hope to learn more about values in between those two, as we study the data more.

user-agent

One time, I saw LCP increase when using a prefetched SXG. I ran WebPageTest , comparing median results without and with SXG prefetch. Clicking on After below:

I saw that prefetch was working. The HTML is removed from the critical path and, thus, all of the subresources are able to load earlier. But LCP—that green dashed line— increased from 2s to 2.1s .

To diagnose this, I looked at the film strips. I found that the page rendered differently in SXG. In plain HTML, Chrome determined that the "largest element" for LCP was the headline. However, in the SXG version, the page added a lazy-loaded banner, which pushed the headline below the fold and caused the new largest element to be the lazy-loaded cookie consent dialog. Everything rendered faster than before, but a change in layout caused the metric to report it as slower.

I dug deeper and discovered the reason for the difference in layout is that the page varies by User-Agent , and there was an error in the logic. It was serving a desktop page even though the SXG crawl header indicated mobile. After this was fixed, the browser correctly identified the page's headline as its largest element again.

Now, clicking on "After", I saw that the prefetched LCP drops to 1.3s :

SXGs are enabled for all form factors. To prepare for that, ensure that one of these is true:

• Your page doesn't Vary by User-Agent (eg it uses responsive design or separate mobile/desktop URLs ).
• If your page uses dynamic serving , it annotates itself as mobile- or desktop-only using <meta name=supported-media content=...> .

উপসম্পদ

SXGs can be used to prefetch subresources (including images) along with the HTML. Cloudflare ASX will scan the HTML for same-origin (first-party) <link rel=preload> elements and convert them into SXG-compatible Link headers . Details in the source code here and here .

If it's working, you'll see additional prefetches from Google Search:

To optimize for LCP, look closely at your waterfall, and figure out which resources are on the critical path to rendering the largest element. If they can't be prefetched, consider if they can be taken off the critical path . Be on the lookout for scripts that hide the page until they are done loading.

The Google SXG Cache allows up to 20 subresource preloads and ASX ensures that this limit isn't exceeded. However, there is a risk in adding too many subresource preloads. The browser will only use preloaded subresources if all of them have finished fetching , in order to prevent cross-site tracking . The more subresources there are, the less likely all of them will have finished prefetching before the user clicks through to your page.

SXG Validator does not currently check subresources; to debug, use curl or dump-signedexchange in the meantime.

পরিমাপ

After optimizing the LCP improvement under WebPageTest, it's useful to measure the impact of SXG prefetching on the overall performance of your site.

Server-side metrics

When measuring server-side metrics such as Time to First Byte (TTFB) , it's important to note that your site only serves SXGs to crawlers that accept the format. Limit your measurement of TTFB to requests coming from real users, and not bots. You may find that generating SXGs increases the TTFB for crawler requests, but this has no impact on your visitors' experience.

Client-side metrics

SXGs produce the most speed benefit for client-side metrics, especially LCP. When measuring their impact, you could simply enable Cloudflare ASX, wait for it to be re-crawled by Googlebot, wait an additional 28 days for Core Web Vitals (CWV) aggregation, and then look at your new CWV numbers. However, the change might be hard to spot when mixed in among all the other changes during this time frame.

Instead, I find it helpful to "zoom in" on the potentially affected page loads, and frame it as, "SXGs affect X% of page views, improving their LCP by Y milliseconds at the 75th percentile."

Currently, SXG prefetch only happens under certain conditions:

• Chromium browser (eg Chrome or Edge except on iOS ), version M98 or higher
• Referer: google.com or other Google search domains . (Note that in Google Analytics, a referral tag applies to all page views in the session , whereas SXG prefetch only applies to the first page view, directly linked from Google Search.)

Read the Contemporary study section for how to measure "X% of page views" and "improving their LCP by Y milliseconds".

সমসাময়িক অধ্যয়ন

When looking at real user monitoring (RUM) data, you should split page loads into SXG and non-SXG. When doing so, it is essential to limit the set of page loads you look at, so the non-SXG side matches the eligibility conditions for SXG, in order to avoid selection bias. Otherwise, all of the following would exist only in the set of non-SXG page loads, which may have innately different LCP:

• iOS devices: due to differences in hardware or network speed among the users who have these devices.
• Older Chromium browsers: for the same reasons.
• Desktop devices: for the same reasons or because the page layout causes a different "largest element" to be chosen.
• Same-site navigations (visitors following links within the site): because they can reuse cached subresources from the previous page load.

In Google Analytics (UA), create two custom dimensions with scope "Hit", one named "isSXG" and one named "referrer". (The built-in "Source" dimension has session scope , so it doesn't exclude same-site navigations.)

Create a custom segment named "SXG counterfactual" with the following filters ANDed together:

• referrer starts with https://www.google.
• Browser exactly matches Chrome
• Browser Version matches regex ^(9[8-9]|[0-9]{3})
• isSXG exactly matches false

Create a copy of this segment, named "SXG", except with isSXG exactly matches true .

In your site template, add the following snippet above the Google Analytics snippet. This is a special syntax that ASX will change false to true when generating a SXG:

<script data-issxg-var>window.isSXG=false</script>

Customize your Google Analytics reporting script as recommended to record LCP. If you're using gtag.js, modify the 'config' command to set the custom dimension (replacing 'dimension1' and 'dimension2' with the names that Google Analytics says to use):

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

If you're using analytics.js, modify the 'create' command as documented here .

After waiting a few days to collect some data, go to the Google Analytics Events report and add a drilldown for the SXG segment. This should fill in the X for "SXGs affect X% of page views":

Finally, go to the Web Vitals Report , select "Choose segments", and select "SXG counterfactual" and "SXG".

Click "Submit", and you should see LCP distributions for the two segments. This should fill in the Y for "improving their LCP by Y milliseconds at the 75th percentile":

সতর্কতা

Once you've applied all of the above filters, SXG counterfactual page loads should consist of things like these:

• Cache misses: If the Google SXG Cache doesn't have a fresh copy of the SXG for a given URL, it will redirect to the original URL at your site.
• Other result types: Currently, Google Search only supports SXG for standard web results and a few other types. Others, like Featured Snippets and Top Stories Carousel, will link to the original URL at your site.
• Ineligible URLs: If some pages on your site are not eligible for SXG (eg because they are not cacheable), they could appear in this set.

There may be remaining bias between the SXG page loads and the above set of non-SXG page loads, but it should be smaller in magnitude than the biases mentioned at the top of the Contemporary study section . For example, perhaps your non-cacheable pages are slower or faster than your cacheable pages. If you suspect this could be an issue, consider looking at the data limited to a specific SXG-eligible URL to see if its results match the overall study.

If your site has some AMP pages, they probably won't see performance improvements from enabling SXG, as they can already be prefetched from Google Search. Consider adding a filter to exclude such pages, to further "zoom in" on the relevant changes.

Lastly, even addressing all selection biases, there is risk that survivorship bias makes LCP improvements look like degradations in RUM statistics. This article does a great job of explaining that risk, and suggests looking at some form of abandonment metric to detect whether this is happening.

Before/after study

To corroborate results from the contemporary study, it may be useful to do a comparison of LCP before and after enabling SXG. Don't limit to SXG page views, to eliminate the potential biases noted above. Instead, look at SXG-eligible results—the above segment definitions but without the isSXG constraint.

Note that Google Search may take up to several weeks to recrawl all pages on your site, in order to identify that SXG has been enabled for them. In those several weeks, there are other potential biases that may occur:

• New browser releases or improvements in users' hardware may speed up page loads.
• A significant event like a holiday may skew traffic from normal.

It also is helpful to look at overall 75th percentile LCP before and after, to confirm the above studies. Learning about a subset of the population doesn't necessarily tell us about the overall population. For instance, let's say SXG improves 10% of page loads by 800ms.

• If these were already the 10% fastest page loads, then it won't affect the 75th percentile at all.
• If they were the 10% slowest page loads, but they were more than 800ms slower than the 75th percentile LCP to begin with, then it won't affect the 75th percentile at all.

These are extreme examples, likely not reflective of reality, but hopefully illustrate the issue. In practice, it's likely that SXG will affect the 75th percentile for most sites. Cross-site navigations tend to be some of the slowest, and improvements from prefetching tend to be significant.

Opt-out some URLs

Lastly, one way to compare SXG performance could be to disable SXG for some subset of URLs on your site. For instance, you could set a CDN-Cache-Control: no-store header to prevent Cloudflare ASX from generating an SXG. I recommend against this.

It likely has a bigger risk of selection bias than the other study methods. For instance, it may make a big difference whether your site's home page or a similarly popular URL is selected into the control group or the experiment group.

Holdback study

The ideal way to measure impact would be to conduct a holdback study. Unfortunately, you can't do this kind of test currently. We're planning to add support for such a test in the future.

A holdback study has the following properties:

• In the experiment group, some random fraction of page views that would be SXG are "held back", and served as non-SXG instead. This allows for an "apples-to-apples" comparison between equivalent users, devices, scenarios, and pages.
• Those held-back (aka counterfactual) page views are labeled as such in the analytics. This allows for a "zoomed-in" view of the data, where we can compare SXG page loads in the control to SXG counterfactuals in the experiment. This, in turn, reduces noise from the other page loads that would be unaffected by SXG prefetch.

This would eliminate the aforementioned possible sources of selection bias, although it wouldn't eliminate the risk of LCP survivorship bias. Both of these properties require either the browser or the referrer to enable.

উপসংহার

ফাউ! যে অনেক ছিল. Hopefully it paints a more complete picture of how to test SXG performance in a lab test, how to optimize its performance in a tight feedback loop with the lab test, and finally how to measure its performance in the real world. Putting all of this together should help you make the most out of SXGs, and ensure that they are benefiting your site and your users.

If you have additional advice on how to capture SXG performance, please let us know! File a bug against developer.chrome.com with your suggested improvements.

For more information on signed exchanges, take a look at the web.dev documentation and the Google Search documentation .

How to measure and optimize signed exchanges to get the most improvement out of them

Devin Mullins

Signed exchanges (SXGs) are a means to improve your page speed—mainly Largest Contentful Paint (LCP) . When referring sites (currently Google Search) link to a page, they can prefetch it into the browser cache before the user clicks on the link.

It's possible to make web pages that, when prefetched, require no network on the critical path to rendering the page ! On a 4G connection, this page load goes from 2.8s to 0.9s (the remaining 0.9s being mostly by CPU usage):

Most people publishing SXGs today are using Cloudflare's easy-to-use Automatic Signed Exchanges (ASX) feature (though open source options exist too):

In many cases, checking the box to enable this feature is enough to get the kind of substantial improvement shown above. Sometimes, there are a few more steps to ensure these SXGs are working as intended at each stage of the pipeline, and to optimize pages to take full advantage of prefetch.

In the past couple of months since Cloudflare's launch, I've been reading and responding to questions on various forums and learning how to advise sites on how to make sure they're getting the most out of their SXG deployments. This post is a collection of my advice. I'll walk through the steps to:

• Analyze SXG performance using WebPageTest.
• Debug the SXG pipeline if the Analyze step shows that it's not working.
• Optimize pages for SXG prefetch including setting an optimal max-age and preloading render-blocking subresources.
• Measure SXG improvement using Google Analytics by selecting appropriate experiment and control groups.

ভূমিকা

An SXG is a file containing a URL, a set of HTTP response headers, and a response body—all cryptographically signed by a Web PKI certificate. When the browser loads an SXG, it verifies all of these:

• The SXG hasn't expired.
• The signature matches the URL, headers, body, and certificate.
• The certificate is valid and matches the URL.

If verification fails, the browser abandons the SXG and instead fetches the signed URL. If verification succeeds, the browser loads the signed response, treating it as if it came directly from the signed URL. This allows SXGs to be rehosted on any server as long as it isn't expired or modified since being signed.

In the case of Google Search, SXG enables prefetching of pages in its search results. For pages supporting SXGs, Google Search can prefetch its cached copy of the page, hosted on webpkgcache.com. These webpkgcache.com URLs don't affect the display or behavior of the page, because the browser respects the original, signed URL. Prefetching can enable your page to load much faster.

বিশ্লেষণ করুন

To see the benefit of SXGs, start by using a lab tool to analyze SXG performance in repeatable conditions. You can use WebPageTest to compare waterfalls—and LCP—with and without SXG prefetch.

Generate a test without SXG as follows:

• Go to WebPageTest and sign in. Signing in saves your test history for easier comparison later.
• Enter the URL you want to test.
• Go to Advanced Configuration . (You will need Advanced Configuration for the SXG test, so using it here helps ensure the test options are the same.)
• In the Test Settings tab, it may be helpful to set Connection to 4G and increase "Number of Tests to Run" to 7.
• স্টার্ট টেস্টে ক্লিক করুন।

Generate a test with SXG by using the same steps as above, but before clicking Start Test , go to the Script tab, paste in the following WebPageTest script , and modify the two navigate URLs as directed:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

For the first navigate URL, if your page doesn't appear in any Google Search results yet, you can use this prefetch page to generate a pretend search results page for this purpose.

To determine the second navigate URL, visit your page using the SXG Validator Chrome extension , and click the extension icon to see the cache URL:

Once these tests are complete, go to Test History , select the two tests, and click Compare :

Append &medianMetric=LCP to the compare URL so WebPageTest selects the run with median LCP for each side of the comparison. (The default is median by Speed Index.)

To compare waterfalls, expand the Waterfall Opacity section and drag the slider. To view the video, click Adjust Filmstrip Settings , scroll down inside that dialog, and click View Video .

If the SXG prefetch is successful, you will see that the "with SXG" waterfall doesn't include a row for the HTML, and the fetches for subresources start sooner. For example, compare "Before" and "After" here:

ডিবাগ

If the WebPageTest is showing that the SXG is being prefetched, then it has succeeded in all the steps of the pipeline; you may skip to the Optimize section to learn how to further improve LCP. Otherwise, you'll need to find out where in the pipeline it failed and why; read on to learn how.

প্রকাশনা

Make sure your pages are being generated as SXGs. To do so, you need to pretend to be a crawler. The easiest way is to use the SXG Validator Chrome extension :

The extension fetches the current URL with an Accept request header that says it prefers the SXG version. If you see a check mark (✅) next to Origin, that means an SXG was returned; you can skip to the Indexing section.

If you see a cross mark (❌), that means an SXG wasn't returned:

If Cloudflare ASX is enabled, then the most likely reason for a cross mark (❌) is because a cache control response header prevents it. ASX looks at headers with the following names:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

If any of these headers contains any of the following header values, it will prevent an SXG from being generated:

• private
• no-store
• no-cache
• max-age less than 120, unless overridden by s-maxage greater than or equal to 120

ASX doesn't create an SXG in these cases because SXGs may be cached and reused for multiple visits and multiple visitors.

Another possible reason for a cross mark (❌) is the presence of one of these stateful response headers , except for Set-Cookie . ASX removes the Set-Cookie header to comply with the SXG specification.

Another possible reason is the presence of a Vary: Cookie response header. Googlebot fetches SXGs without user credentials and may serve them to multiple visitors. If you serve different HTML to different users based on their cookie, then they could see an incorrect experience such as a logged out view.

Alternatively to the Chrome extension, you can use a tool like curl :

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

or dump-signedexchange :

dump-signedexchange -verify -uri $URL

If the SXG is present and valid, you will see a human readable printout of the SXG. Otherwise, you will see an error message.

ইনডেক্সিং

Make sure your SXGs are successfully indexed by Google Search. Open Chrome DevTools, then perform a Google Search for your page. If it has been indexed as an SXG, Google's link to your page will include a data-sxg-url pointing to webpkgcache.com's copy:

If Google Search thinks the user is likely to click on the result, it will also prefetch it:

The <link> element instructs the browser to download the SXG into its prefetch cache. When the user clicks on the <a> element, the browser will use that cached SXG to render the page.

You can also see evidence of the prefetch by going to the Network tab in DevTools and searching for URLs containing webpkgcache .

If the <a> points to webpkgcache.com, this means Google Search indexing of the signed exchange is working. You can skip forward to the Ingestion section.

Otherwise, it could be that Google hasn't recrawled your page yet since you enabled SXG. Try the Google Search Console URL Inspection Tool :

The presence of a digest: mi-sha256-03=... header indicates that Google successfully crawled the SXG version.

If a digest header is not present, this could be an indication that an SXG was not served to Googlebot or that the index hasn't been updated since you enabled SXGs.

If an SXG is successfully crawled, but it still isn't being linked to, then it may be a failure to meet SXG cache requirements. These are covered in the next section.

ইনজেশন

When Google Search indexes an SXG, it sends its copy to the Google SXG Cache, which validates it against the cache requirements . The Chrome extension shows the result:

If you see a check mark (✅), then you can skip ahead to Optimize .

If it fails to meet the requirements, you will see a cross mark (❌) and a warning message indicating why:

In this event, the page will work just as it did before enabling SXG. Google will link to the page on its original host without an SXG prefetch.

In the event that the cached copy has expired and is being re-fetched in the background, you will see an hourglass (⌛):

The Google developer document on SXG also has instructions for querying the cache manually .

অপ্টিমাইজ করুন

If the SXG Validator Chrome extension shows all check marks (✅), you have a SXG that can be served to users! Read on to find out how to optimize your web page so that you get the most LCP improvement from SXG.

সর্বোচ্চ বয়স

When SXGs expire, the Google SXG Cache will fetch a new copy in the background. While waiting for that fetch, users are directed to the page on its original host, which is not prefetched. The longer you set Cache-Control: max-age , the less often this background fetch happens, and thus the more often that LCP can be reduced by prefetch.

This is a tradeoff between performance and freshness, and the cache allows site owners to provide SXGs with a max-age anywhere between 2 minutes and 7 days, to fit each page's particular needs. Anecdotally, we find that:

• max-age=86400 (1 day) or longer works well for performance
• max-age=120 (2 minutes) does not

We hope to learn more about values in between those two, as we study the data more.

user-agent

One time, I saw LCP increase when using a prefetched SXG. I ran WebPageTest , comparing median results without and with SXG prefetch. Clicking on After below:

I saw that prefetch was working. The HTML is removed from the critical path and, thus, all of the subresources are able to load earlier. But LCP—that green dashed line— increased from 2s to 2.1s .

To diagnose this, I looked at the film strips. I found that the page rendered differently in SXG. In plain HTML, Chrome determined that the "largest element" for LCP was the headline. However, in the SXG version, the page added a lazy-loaded banner, which pushed the headline below the fold and caused the new largest element to be the lazy-loaded cookie consent dialog. Everything rendered faster than before, but a change in layout caused the metric to report it as slower.

I dug deeper and discovered the reason for the difference in layout is that the page varies by User-Agent , and there was an error in the logic. It was serving a desktop page even though the SXG crawl header indicated mobile. After this was fixed, the browser correctly identified the page's headline as its largest element again.

Now, clicking on "After", I saw that the prefetched LCP drops to 1.3s :

SXGs are enabled for all form factors. To prepare for that, ensure that one of these is true:

• Your page doesn't Vary by User-Agent (eg it uses responsive design or separate mobile/desktop URLs ).
• If your page uses dynamic serving , it annotates itself as mobile- or desktop-only using <meta name=supported-media content=...> .

উপসম্পদ

SXGs can be used to prefetch subresources (including images) along with the HTML. Cloudflare ASX will scan the HTML for same-origin (first-party) <link rel=preload> elements and convert them into SXG-compatible Link headers . Details in the source code here and here .

If it's working, you'll see additional prefetches from Google Search:

To optimize for LCP, look closely at your waterfall, and figure out which resources are on the critical path to rendering the largest element. If they can't be prefetched, consider if they can be taken off the critical path . Be on the lookout for scripts that hide the page until they are done loading.

The Google SXG Cache allows up to 20 subresource preloads and ASX ensures that this limit isn't exceeded. However, there is a risk in adding too many subresource preloads. The browser will only use preloaded subresources if all of them have finished fetching , in order to prevent cross-site tracking . The more subresources there are, the less likely all of them will have finished prefetching before the user clicks through to your page.

SXG Validator does not currently check subresources; to debug, use curl or dump-signedexchange in the meantime.

পরিমাপ

After optimizing the LCP improvement under WebPageTest, it's useful to measure the impact of SXG prefetching on the overall performance of your site.

Server-side metrics

When measuring server-side metrics such as Time to First Byte (TTFB) , it's important to note that your site only serves SXGs to crawlers that accept the format. Limit your measurement of TTFB to requests coming from real users, and not bots. You may find that generating SXGs increases the TTFB for crawler requests, but this has no impact on your visitors' experience.

Client-side metrics

SXGs produce the most speed benefit for client-side metrics, especially LCP. When measuring their impact, you could simply enable Cloudflare ASX, wait for it to be re-crawled by Googlebot, wait an additional 28 days for Core Web Vitals (CWV) aggregation, and then look at your new CWV numbers. However, the change might be hard to spot when mixed in among all the other changes during this time frame.

Instead, I find it helpful to "zoom in" on the potentially affected page loads, and frame it as, "SXGs affect X% of page views, improving their LCP by Y milliseconds at the 75th percentile."

Currently, SXG prefetch only happens under certain conditions:

• Chromium browser (eg Chrome or Edge except on iOS ), version M98 or higher
• Referer: google.com or other Google search domains . (Note that in Google Analytics, a referral tag applies to all page views in the session , whereas SXG prefetch only applies to the first page view, directly linked from Google Search.)

Read the Contemporary study section for how to measure "X% of page views" and "improving their LCP by Y milliseconds".

সমসাময়িক অধ্যয়ন

When looking at real user monitoring (RUM) data, you should split page loads into SXG and non-SXG. When doing so, it is essential to limit the set of page loads you look at, so the non-SXG side matches the eligibility conditions for SXG, in order to avoid selection bias. Otherwise, all of the following would exist only in the set of non-SXG page loads, which may have innately different LCP:

• iOS devices: due to differences in hardware or network speed among the users who have these devices.
• Older Chromium browsers: for the same reasons.
• Desktop devices: for the same reasons or because the page layout causes a different "largest element" to be chosen.
• Same-site navigations (visitors following links within the site): because they can reuse cached subresources from the previous page load.

In Google Analytics (UA), create two custom dimensions with scope "Hit", one named "isSXG" and one named "referrer". (The built-in "Source" dimension has session scope , so it doesn't exclude same-site navigations.)

Create a custom segment named "SXG counterfactual" with the following filters ANDed together:

• referrer starts with https://www.google.
• Browser exactly matches Chrome
• Browser Version matches regex ^(9[8-9]|[0-9]{3})
• isSXG exactly matches false

Create a copy of this segment, named "SXG", except with isSXG exactly matches true .

In your site template, add the following snippet above the Google Analytics snippet. This is a special syntax that ASX will change false to true when generating a SXG:

<script data-issxg-var>window.isSXG=false</script>

Customize your Google Analytics reporting script as recommended to record LCP. If you're using gtag.js, modify the 'config' command to set the custom dimension (replacing 'dimension1' and 'dimension2' with the names that Google Analytics says to use):

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

If you're using analytics.js, modify the 'create' command as documented here .

After waiting a few days to collect some data, go to the Google Analytics Events report and add a drilldown for the SXG segment. This should fill in the X for "SXGs affect X% of page views":

Finally, go to the Web Vitals Report , select "Choose segments", and select "SXG counterfactual" and "SXG".

Click "Submit", and you should see LCP distributions for the two segments. This should fill in the Y for "improving their LCP by Y milliseconds at the 75th percentile":

সতর্কতা

Once you've applied all of the above filters, SXG counterfactual page loads should consist of things like these:

• Cache misses: If the Google SXG Cache doesn't have a fresh copy of the SXG for a given URL, it will redirect to the original URL at your site.
• Other result types: Currently, Google Search only supports SXG for standard web results and a few other types. Others, like Featured Snippets and Top Stories Carousel, will link to the original URL at your site.
• Ineligible URLs: If some pages on your site are not eligible for SXG (eg because they are not cacheable), they could appear in this set.

There may be remaining bias between the SXG page loads and the above set of non-SXG page loads, but it should be smaller in magnitude than the biases mentioned at the top of the Contemporary study section . For example, perhaps your non-cacheable pages are slower or faster than your cacheable pages. If you suspect this could be an issue, consider looking at the data limited to a specific SXG-eligible URL to see if its results match the overall study.

If your site has some AMP pages, they probably won't see performance improvements from enabling SXG, as they can already be prefetched from Google Search. Consider adding a filter to exclude such pages, to further "zoom in" on the relevant changes.

Lastly, even addressing all selection biases, there is risk that survivorship bias makes LCP improvements look like degradations in RUM statistics. This article does a great job of explaining that risk, and suggests looking at some form of abandonment metric to detect whether this is happening.

Before/after study

To corroborate results from the contemporary study, it may be useful to do a comparison of LCP before and after enabling SXG. Don't limit to SXG page views, to eliminate the potential biases noted above. Instead, look at SXG-eligible results—the above segment definitions but without the isSXG constraint.

Note that Google Search may take up to several weeks to recrawl all pages on your site, in order to identify that SXG has been enabled for them. In those several weeks, there are other potential biases that may occur:

• New browser releases or improvements in users' hardware may speed up page loads.
• A significant event like a holiday may skew traffic from normal.

It also is helpful to look at overall 75th percentile LCP before and after, to confirm the above studies. Learning about a subset of the population doesn't necessarily tell us about the overall population. For instance, let's say SXG improves 10% of page loads by 800ms.

• If these were already the 10% fastest page loads, then it won't affect the 75th percentile at all.
• If they were the 10% slowest page loads, but they were more than 800ms slower than the 75th percentile LCP to begin with, then it won't affect the 75th percentile at all.

These are extreme examples, likely not reflective of reality, but hopefully illustrate the issue. In practice, it's likely that SXG will affect the 75th percentile for most sites. Cross-site navigations tend to be some of the slowest, and improvements from prefetching tend to be significant.

Opt-out some URLs

Lastly, one way to compare SXG performance could be to disable SXG for some subset of URLs on your site. For instance, you could set a CDN-Cache-Control: no-store header to prevent Cloudflare ASX from generating an SXG. I recommend against this.

It likely has a bigger risk of selection bias than the other study methods. For instance, it may make a big difference whether your site's home page or a similarly popular URL is selected into the control group or the experiment group.

Holdback study

The ideal way to measure impact would be to conduct a holdback study. Unfortunately, you can't do this kind of test currently. We're planning to add support for such a test in the future.

A holdback study has the following properties:

• In the experiment group, some random fraction of page views that would be SXG are "held back", and served as non-SXG instead. This allows for an "apples-to-apples" comparison between equivalent users, devices, scenarios, and pages.
• Those held-back (aka counterfactual) page views are labeled as such in the analytics. This allows for a "zoomed-in" view of the data, where we can compare SXG page loads in the control to SXG counterfactuals in the experiment. This, in turn, reduces noise from the other page loads that would be unaffected by SXG prefetch.

This would eliminate the aforementioned possible sources of selection bias, although it wouldn't eliminate the risk of LCP survivorship bias. Both of these properties require either the browser or the referrer to enable.

উপসংহার

ফাউ! যে অনেক ছিল. Hopefully it paints a more complete picture of how to test SXG performance in a lab test, how to optimize its performance in a tight feedback loop with the lab test, and finally how to measure its performance in the real world. Putting all of this together should help you make the most out of SXGs, and ensure that they are benefiting your site and your users.

If you have additional advice on how to capture SXG performance, please let us know! File a bug against developer.chrome.com with your suggested improvements.

For more information on signed exchanges, take a look at the web.dev documentation and the Google Search documentation .