مقدمه ای بر فناوری های در دسترس
چرا سرعت بارگذاری صفحه اهمیت دارد؟
اکثر کاربران به طور معمول بارهای آهسته صفحه را به عنوان منبع اصلی ناامیدی تشخیص می دهند (54٪ در مطالعه کاربران انجام شده توسط Google). بنابراین، نباید تعجب آور باشد که بارگذاری سریعتر صفحه نتایج بهتری برای یک کسب و کار به همراه دارد. در واقع، اگر بازدیدکنندگان حتی قبل از تعامل با یک وب‌سایت ناامید شوند، بعید است که آن‌قدر طولانی بمانند تا ارزش آن را بدانند. در واقع، یک مطالعه دیگر گوگل در 254 سایت تجارت الکترونیک، امور مالی و سفر نشان داد که سایت هایی که در دو ثانیه یا کمتر بارگیری می شوند، 15٪ نرخ تبدیل بالاتری دارند.
افزایش سرعت بزرگترین رنگ محتوایی (LCP)
همانطور که گفته می شود، شما نمی توانید آنچه را که اندازه گیری نمی کنید، بهبود بخشید. برای تجربیات کاربر در وب، ما معتقدیم که Core Web Vitals مجموعه ای محکم از معیارهای کاربر محور است که برای ثبت جنبه های اساسی تجربه کاربر طراحی شده است. به طور خاص، بزرگترین رنگ محتوایی (LCP) عملکرد بارگذاری صفحات شما را با گزارش زمان لازم برای نمایش بزرگترین بلوک متن یا تصویری که کاربر می بیند، اندازه گیری می کند. برای ارائه یک تجربه کاربری خوب، LCP باید در عرض 2.5 ثانیه از زمانی که صفحه برای اولین بار بارگذاری می شود (یعنی آستانه LCP خوب) رخ دهد.
بیایید ببینیم چه چیزی به LCP یک صفحه معمولی کمک می کند.
هنگامی که کاربر از یک صفحه بازدید می کند، مرورگر HTML را از سرور درخواست می کند. سرور با HTML پاسخ می دهد، که به مرورگر نکات بیشتری در مورد آنچه در مرحله بعد واکشی می کند، از جمله CSS، جاوا اسکریپت، فونت ها و تصاویر می دهد. با بازگشت این پاسخ‌ها، مرورگر نیز باید برای ارزیابی آنها کار کند و در نهایت اجزای صفحه را قرار داده و نقاشی کند. اما بیشتر زمان صرف آن می شود تا آن بسته ها از دستگاه به سرور منتقل شوند و سپس به دستگاه برگردند. در واقع، داده‌های ما (Chrome برای Android؛ میانه) نشان می‌دهد که حدود 40 درصد از تأخیر قابل مشاهده برای کاربر معمولاً توسط مرورگر صرف می‌شود تا اولین بایت از سرور بازگردد.
قدرت واکشی اولیه
اگر کسی بتواند همه این فایل ها را از قبل واکشی کند - یعنی آنها را قبل از بازدید کاربر از صفحه واکشی کند - این کار باعث افزایش سرعت زیادی می شود و فقط چند کار قبل از نمایش صفحه باقی می ماند: ارزیابی، محاسبه طرح بندی و نقاشی.
با توجه به داده‌هایی که قبلاً به اشتراک گذاشته شد، می‌توان منبع اصلی را از قبل واکشی کرد و همچنان به بارگذاری صفحه بسیار سریع‌تری دست یافت. در مورد همان سایت، این نوع تکنیک به راحتی با موارد اولیه مانند rel=prefetch در دسترس است. با این حال، با سناریوهای متقابل سایت، آنقدرها هم ساده نیست.
پیمایش های بین سایتی
در حالی که واکشی اولیه برای مدتی وجود داشته است، در هنگام واکشی اولیه صفحات از یک سایت در حالی که کاربر در سایت دیگری است، توجه بیشتری لازم است.
فرض کنید که یک سایت ارجاع دهنده به مرورگر دستور می دهد که یک صفحه را از یک سایت دیگر واکشی کند. بدیهی است که وقتی کاربر روی پیوند به این صفحه از پیش واکشی شده کلیک می کند، از تجربه کاربری بهتری با بارگذاری صفحه بسیار سریعتر لذت می برد. با این حال، اگر کاربر هرگز روی این پیوند کلیک نکند، چه؟ آنها انتظار ندارند که یک وب سایت پیوندی متوجه شود که ممکن است به موضوعی علاقه داشته باشند، در حالی که آن را در سایت ارجاع دهنده جستجو می کردند. و با این حال، این یک خطر اساسی است، زیرا درخواست‌های واکشی اولیه، آدرس IP کاربر، و در صورت وجود کوکی‌ها، مانند هر درخواست معمولی دیگری را دارند.
راه حل ها
برای فعال کردن واکشی اولیه بین سایتی ایمن برای حفظ حریم خصوصی، ما در 3 سال گذشته دو راه حل ایجاد کرده ایم: پراکسی Prefetch خصوصی و Signed Exchanges (SXG) . ما همچنین آزمایشی در مقیاس بزرگ انجام دادیم تا تأیید کنیم که واکشی اولیه متقاطع مزایای سرعت قابل توجهی دارد. به طور مشخص، وقتی به مواردی نگاه کردیم که Google توانست به طور ایمن HTML اصلی را برای پیمایش بعدی کاربر واکشی کند، دیدیم که کسری از بارگذاری صفحه با LCP "خوب" 14 درصد افزایش یافته است!
ملاحظات کلیدی
در حالی که پراکسی Prefetch خصوصی و Signed Exchange یک مورد استفاده را حل می کنند، هر فناوری مجموعه متفاوتی از مبادلات را ارائه می دهد. بنابراین، بهترین انتخاب واقعاً به نیازهای خاص سایت شما بستگی دارد. برای کمک به درک شما از مبادلات موجود، بخش‌های زیر دو ملاحظات کلیدی را برای فعال کردن واکشی متقابل سایت و انتخاب بین دو فناوری موجود پوشش می‌دهند. همچنین جزئیات بیشتری را در مقالات شیرجه عمیق برای هر فناوری خواهید یافت.
بازدیدکنندگان تکراری
واکشی اولیه بین سایتی برای کاربرانی که برای اولین بار از سایت شما بازدید می کنند آسان است. برای بازدیدکنندگان مکرر، این بستگی به میزان شخصی سازی در سایت شما دارد. این به این واقعیت مربوط می شود که درخواست های پیش واکشی بین سایتی به دلایل حفظ حریم خصوصی نمی توانند شامل کوکی ها شوند.
- برای بازدیدکنندگانی که برای اولین بار بازدید می‌کنند، این محدودیت هیچ چالشی ایجاد نمی‌کند زیرا این بازدیدکنندگان هیچ کوکی برای شروع ندارند. در نتیجه، شما می توانید واکشی اولیه متقاطع سایت را برای این کاربران بدون هیچ تغییری در سایت خود فعال کنید.
- اگر می‌خواهید واکشی اولیه بین سایتی را برای بازدیدکنندگان مکرر فعال کنید و سایت شما بر اساس کوکی‌ها شخصی‌سازی شده است، باید این عناصر شخصی‌شده را پس از پیمایش کاربر بارگیری کنید. این کار به این دلیل کار می‌کند که پس از پیمایش، محدودیت کوکی‌ها دیگر مورد نیاز نیست، زیرا کاربر صراحتاً از وب‌سایت شما بازدید کرده است. بنابراین، در زمان ناوبری، سایت شما طبق معمول به کوکی های خود دسترسی دارد. برای راهنمایی دقیق، این بهترین روش‌ها را برای بارگذاری تنبل ببینید.
- اگر در حال حاضر شخصی‌سازی را مستقیماً در HTML خود رمزگذاری می‌کنید، همچنان می‌توانید در صورت وجود کوکی‌ها به این کار ادامه دهید و از بارگذاری تنبل به عنوان یک استراتژی بازگشتی برای صفحات از پیش واکشی شده استفاده کنید.
- اگر سایت شما بر اساس کوکی‌ها شخصی‌سازی نشده است، یا اگر شخصی‌سازی حیاتی نیست، می‌توانید همان محتوایی را که برای بازدیدکنندگانی که برای اولین بار انجام می‌دهند به بازدیدکنندگان تکراری خود ارائه دهید.
در حال حاضر، Private Prefetch Proxy فقط برای بازدیدکنندگانی که برای اولین بار (پیوندهای بدون کوکی) با کار در حال انجام هستند فعال می شود تا پوشش را برای بازدیدکنندگان تکراری (پیوندهای با کوکی) گسترش دهد. از سوی دیگر، Signed Exchange در حال حاضر از واکشی اولیه متقابل سایت هم برای بازدیدکنندگان بار اول و هم برای بازدیدکنندگان مکرر (با رویکردهای ذکر شده در بالا) پشتیبانی می کند.
داده های اضافی از پیش واکشی ارائه می شود
فعال کردن واکشی اولیه بین سایتی می‌تواند منجر به ارائه اطلاعات اضافی شود. در واقع، اگر یک ارجاع دهنده صفحه شما را از قبل واکشی کند اما کاربر روی پیوند کلیک نکند، این نشان دهنده ترافیک اضافی برای شما خواهد بود.
- برای کاهش این موضوع، می‌توان از ارجاع‌دهنده درخواست کرد که با درخواست‌های واکشی اولیه‌اش کمتر تهاجمی باشد. به طور مشابه، ارجاع دهنده یا مرورگر می تواند با تمرکز بر منابع نسبتا سبک و در عین حال حیاتی (به عنوان مثال، منبع اصلی، CSS حیاتی، یا زیرمنابع جاوا اسکریپت) این مشکل را کاهش دهد. این اساساً یک مبادله بین مزایای سرعت و ترافیک اضافی است.
- از طرف دیگر، می‌توان این ترافیک را با انتخاب ذخیره‌سازی اضافی جبران کرد (برای جزئیات بیشتر به این بخش در Signed Exchange مراجعه کنید). نقطه ضعف در اینجا این است که ذخیره محتوا برای مدت طولانی می تواند منجر به نمایش اطلاعات قدیمی به کاربران شما شود. این اساساً مبادله ای بین ارائه داده های اضافی و تازگی محتوا است.
برای گرفتن بهترین تصمیم در اینجا، از خود بپرسید که سایت شما در کجای مقیاس کشویی بین حداکثر تازگی و حداقل درخواست های اضافی قرار دارد. پاسخ به این سوال در نهایت به نیازهای خاص کسب و کار شما و کاربران شما بستگی دارد.
شروع شدن
این فناوری‌ها در جستجوی Google ادغام شده‌اند تا سایت‌ها بتوانند بلافاصله LCP خود را بهبود بخشند. ما امیدواریم که این امر سایر ارجاع دهندگان محبوب را نیز تشویق کند که از این روند پیروی کنند و به سرعت بیشتر وب در سراسر جهان کمک کند!
در حالی که این فناوری‌ها هر دو یک مورد استفاده را حل می‌کنند، آنها مبادلات متفاوتی را در مورد ملاحظات کلیدی که قبلا توضیح داده شد ارائه می‌دهند. حتی ممکن است تصمیم بگیرید که با یک فناوری شروع کنید و با توجه به نیازهایتان یا درک مزایا، از فناوری دیگر فارغ التحصیل شوید. این غواصی های عمیق را ببینید تا بفهمید کدام فناوری برای موقعیت خاص شما بهترین راه رو به جلو است: