ملاحظات کلی عملکرد HTML

اولین قدم در ساختن وب سایتی که سریع بارگذاری می شود، دریافت پاسخ به موقع از سرور برای HTML صفحه است. هنگامی که URL را در نوار آدرس مرورگر وارد می کنید، مرورگر یک درخواست GET برای بازیابی آن به سرور ارسال می کند. اولین درخواست برای یک صفحه وب برای یک منبع HTML است - و اطمینان از اینکه HTML به سرعت با کمترین تاخیر می رسد، یک هدف کلیدی عملکرد است.

این درخواست اولیه برای HTML چندین مرحله را طی می کند که هر کدام مدتی طول می کشد. کاهش زمان صرف شده برای هر مرحله به شما زمان سریع‌تری برای اولین بایت (TTFB) می‌دهد. در حالی که TTFB تنها معیاری نیست که در مورد سرعت بارگیری صفحات باید روی آن تمرکز کنید، TTFB بالا رسیدن به آستانه های "خوب" تعیین شده برای معیارهایی مانند بزرگترین رنگ محتوای (LCP) و First Contentful Paint را چالش برانگیز می کند. FCP) .

تغییر مسیرها را به حداقل برسانید

هنگامی که منبعی درخواست می شود، سرور ممکن است با یک تغییر مسیر، یا با تغییر مسیر دائمی (پاسخ 301 Moved Permanently ) یا موقت (یک پاسخ 302 Found ) پاسخ دهد.

تغییر مسیرها سرعت بارگذاری صفحه را کاهش می‌دهند، زیرا مرورگر باید یک درخواست HTTP اضافی در مکان جدید برای بازیابی منبع ارسال کند. دو نوع تغییر مسیر وجود دارد:

1. تغییرمسیرهایی با همان مبدا که کاملاً در مبدا شما رخ می دهد. این نوع تغییر مسیرها کاملاً در کنترل شما هستند، زیرا منطق مدیریت آنها به طور کامل بر روی وب سرور شما قرار دارد.
2. تغییر مسیرهای متقاطع که توسط مبدا دیگری آغاز می شوند. این نوع تغییر مسیرها معمولاً خارج از کنترل شما هستند.

تغییر مسیرهای متقاطع اغلب توسط تبلیغات، سرویس های کوتاه کننده URL و سایر خدمات شخص ثالث استفاده می شود. اگرچه تغییر مسیرهای متقاطع خارج از کنترل شما هستند، ممکن است همچنان بخواهید بررسی کنید که از تغییر مسیرهای متعدد اجتناب کنید - به عنوان مثال، داشتن تبلیغی که به یک صفحه HTTP پیوند می دهد که به نوبه خود به معادل HTTPS خود هدایت می شود، یا یک تغییر مسیر متقاطع که به مبدأ شما می رسد، اما سپس یک تغییر مسیر همان مبدأ را راه اندازی می کند.

پاسخ های HTML کش

ذخیره کردن پاسخ‌های HTML دشوار است، زیرا پاسخ ممکن است شامل پیوندهایی به منابع مهم دیگر مانند CSS، جاوا اسکریپت، تصاویر و سایر انواع منابع باشد. این منابع ممکن است یک اثر انگشت منحصر به فرد در نام فایل مربوطه خود داشته باشند که بر اساس محتوای یک فایل تغییر می کند. این بدان معنی است که سند HTML ذخیره شده شما ممکن است پس از استقرار کهنه شود، زیرا حاوی ارجاعاتی به منابع فرعی قدیمی است.

با این وجود، طول عمر حافظه نهان کوتاه - به جای عدم وجود حافظه پنهان - می تواند مزایایی مانند اجازه دادن به یک منبع در حافظه پنهان در یک CDN - کاهش تعداد درخواست هایی که از سرور مبدا ارائه می شود - و در مرورگر، اجازه اعتبار مجدد منابع را داشته باشد. به جای دانلود مجدد این رویکرد برای محتوای ثابتی که در هیچ زمینه‌ای تغییر نمی‌کند بهترین کار را دارد و زمان مناسب برای ذخیره‌سازی منابع می‌تواند روی چند دقیقه تنظیم شود که شما مناسب می‌دانید. پنج دقیقه برای منابع HTML ایستا یک شرط مطمئن است و تضمین می‌کند که به‌روزرسانی‌های دوره‌ای بی‌توجه نمی‌مانند.

اگر محتویات HTML یک صفحه به روشی شخصی سازی شده باشد - مثلاً برای یک کاربر تأیید شده - به احتمال زیاد نمی خواهید به دلیل نگرانی های مختلف، از جمله امنیت و تازگی، محتوا را در حافظه پنهان نگه دارید. اگر یک پاسخ HTML توسط مرورگر کاربر ذخیره شود، نمی‌توانید کش را باطل کنید. بنابراین بهتر است در چنین مواردی از کش کردن HTML به طور کلی اجتناب کنید.

یک رویکرد محتاطانه برای کش کردن HTML می تواند استفاده از ETag یا Last-Modified سرصفحه پاسخ باشد. ETag - که در غیر این صورت به عنوان یک تگ موجودیت شناخته می شود - هدر یک شناسه است که به طور منحصر به فرد منبع درخواستی را نشان می دهد، اغلب با استفاده از هش از محتوای منبع :

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

هر زمان که منبع تغییر کند، یک مقدار ETag جدید باید تولید شود. در درخواست‌های بعدی، مرورگر مقدار ETag را از طریق هدر درخواست If-None-Match ارسال می‌کند. اگر ETag روی سرور با آنچه که توسط مرورگر ارسال شده مطابقت داشته باشد، سرور با یک پاسخ 304 Not Modified پاسخ می دهد و مرورگر از منبع موجود در حافظه پنهان استفاده می کند. در حالی که این هنوز دارای تأخیر شبکه است، یک پاسخ 304 Not Modified بسیار کوچکتر از کل منبع HTML است.

با این حال، تأخیر شبکه درگیر در تأیید مجدد تازگی یک منبع، هنوز هم یک نوع منفی خود است. مانند بسیاری از جنبه های دیگر توسعه وب، معاوضه و مصالحه اجتناب ناپذیر است. این به شما بستگی دارد که بفهمید آیا تلاش اضافی برای کش کردن HTML به این روش ارزشش را دارد یا اینکه بهتر است در سمت امن باقی بمانید و اصلاً برای کش کردن محتوای HTML زحمت ندهید.

زمان پاسخگویی سرور را اندازه گیری کنید

اگر پاسخی در حافظه پنهان ذخیره نشود، زمان پاسخ سرور به شدت به ارائه دهنده هاست و پشته برنامه کاربردی شما بستگی دارد. یک صفحه وب که یک پاسخ تولید شده به صورت پویا را ارائه می دهد - مانند واکشی داده ها از پایگاه داده، برای مثال - ممکن است TTFB بالاتری نسبت به یک صفحه وب استاتیک داشته باشد که می تواند بلافاصله بدون زمان محاسباتی قابل توجهی در backend ارائه شود. نمایش یک اسپینر در حال بارگذاری و سپس واکشی همه داده ها در سمت کلاینت، تلاش را از یک محیط سمت سرور قابل پیش بینی تر به یک محیط بالقوه غیرقابل پیش بینی سمت مشتری منتقل می کند. به حداقل رساندن تلاش سمت مشتری معمولاً منجر به بهبود معیارهای کاربر محور می شود.

اگر کاربران TTFB کندی را در این زمینه تجربه می‌کنند، می‌توانید با استفاده از هدر پاسخ Server-Timing اطلاعات مربوط به زمان صرف شده در سرور را در معرض دید قرار دهید:

Server-Timing: auth;dur=55.5, db;dur=220

مقدار سرصفحه Server-Timing می تواند شامل چندین معیار و همچنین مدت زمان برای هر یک باشد. سپس می‌توان این داده‌ها را از کاربران در این زمینه با استفاده از Navigation Timing API جمع‌آوری کرد و تجزیه و تحلیل کرد تا ببیند آیا کاربران با تاخیر مواجه هستند یا خیر. در قطعه کد قبلی، هدر پاسخ شامل دو زمان بندی است:

• زمان احراز هویت یک کاربر ( auth ) که 55.5 میلی ثانیه طول کشید.
• زمان دسترسی به پایگاه داده ( db ) که 220 میلی ثانیه طول کشید.

همچنین ممکن است بخواهید زیرساخت میزبانی خود را بررسی کنید و تأیید کنید که منابع کافی برای مدیریت ترافیک دریافتی وب سایت خود دارید. ارائه دهندگان هاست اشتراکی اغلب مستعد TTFB بالا هستند و راه حل های اختصاصی که زمان پاسخگویی سریع تری را ارائه می دهند ممکن است پرهزینه تر باشند.

فشرده سازی

پاسخ‌های مبتنی بر متن مانند تصاویر HTML، جاوا اسکریپت، CSS و SVG باید فشرده شوند تا اندازه انتقال آنها در شبکه کاهش یابد تا بتوانند سریع‌تر دانلود شوند. پرکاربردترین الگوریتم های فشرده سازی gzip و Brotli هستند. Brotli حدود 15% تا 20% بهبود نسبت به gzip دارد.

فشرده‌سازی اغلب به‌طور خودکار توسط اکثر ارائه‌دهندگان میزبانی وب تنظیم می‌شود، اما اگر می‌توانید خودتان تنظیمات فشرده‌سازی را پیکربندی یا تغییر دهید، موارد مهمی وجود دارد که باید در نظر بگیرید:

1. در صورت امکان از Brotli استفاده کنید. همانطور که قبلاً گفته شد، Brotli نسبت به gzip پیشرفت نسبتاً قابل توجهی ارائه می دهد و Brotli در همه مرورگرهای اصلی پشتیبانی می شود . در صورت امکان از Brotli استفاده کنید، اما اگر وب سایت شما توسط تعداد زیادی کاربر در مرورگرهای قدیمی استفاده می شود، مطمئن شوید که gzip به عنوان یک نسخه بازگشتی استفاده می شود، زیرا هر فشرده سازی بهتر از عدم فشرده سازی است.
2. اندازه فایل مهم است. منابع بسیار کوچک - کمتر از 1 کیلوبایت - خیلی خوب فشرده نمی شوند یا حتی گاهی اوقات اصلاً فشرده نمی شوند. اثربخشی هر نوع فشرده سازی داده به داشتن مقدار زیادی داده بستگی دارد که یک الگوریتم فشرده سازی می تواند با آنها کار کند تا بیت های قابل تراکم بیشتری از داده را پیدا کند. هرچه یک فایل بزرگتر باشد، فشرده سازی بهتر عمل می کند – با این حال، منابع بسیار بزرگ را صرفاً به این دلیل که می توانند به طور مؤثرتر فشرده شوند، ارسال نکنید. منابع بزرگ - مانند جاوا اسکریپت و CSS به عنوان مثال - پس از اینکه مرورگر آنها را از حالت فشرده خارج کرد، به زمان قابل توجهی تجزیه و ارزیابی می‌شوند، و ممکن است اغلب تغییر کنند، حتی اگر فقط اندکی تغییر کرده باشند، زیرا هر تغییری منجر به هش فایل متفاوت می‌شود.
3. درک فشرده سازی پویا در مقابل استاتیک. فشرده سازی دینامیک و استاتیک رویکردهای متفاوتی در مورد اینکه چه زمانی باید یک منبع فشرده شود، هستند. فشرده سازی پویا یک منبع را در زمان درخواست فشرده می کند و گاهی اوقات هر بار که درخواست می شود. از طرف دیگر، فشرده سازی استاتیک فایل ها را زودتر از موعد فشرده می کند و نیازی به فشرده سازی در زمان درخواست ندارد. فشرده‌سازی استاتیک تأخیر مربوط به فشرده‌سازی را حذف می‌کند، که می‌تواند در صورت فشرده‌سازی پویا به زمان پاسخ سرور اضافه کند. منابع استاتیک - مانند تصاویر جاوا اسکریپت، CSS و SVG - باید به صورت ایستا فشرده شوند، در حالی که منابع HTML - به خصوص اگر به صورت پویا برای کاربران احراز هویت شده تولید شوند - باید به صورت پویا فشرده شوند.

فشرده سازی به تنهایی چالش برانگیز است، و اغلب بهتر است به یک شبکه تحویل محتوا (CDN) - که در بخش بعدی مورد بحث قرار می گیرد - اجازه دهید این کار را برای شما انجام دهد. با این حال، دانستن این مفاهیم می تواند به شما کمک کند تا تشخیص دهید که آیا ارائه دهنده هاست شما به درستی از فشرده سازی استفاده می کند یا خیر. این دانش می تواند به شما کمک کند تا فرصت هایی را برای بهبود تنظیمات فشرده سازی خود بیابید تا حداکثر سود را برای وب سایت شما داشته باشند.

شبکه های تحویل محتوا (CDN)

یک شبکه تحویل محتوا (CDN) یک شبکه توزیع شده از سرورها است که منابع را از سرور اصلی شما ذخیره می کند و به نوبه خود آنها را از سرورهای لبه ای که از نظر فیزیکی به کاربران شما نزدیکتر هستند ارائه می دهد. نزدیکی فیزیکی به کاربران شما زمان رفت و برگشت (RTT) را کاهش می‌دهد، در حالی که بهینه‌سازی‌هایی مانند HTTP/2 یا HTTP/3، حافظه پنهان و فشرده‌سازی به CDN اجازه می‌دهد محتوا را سریع‌تر از زمانی که از سرور اصلی شما واکشی می‌شود، ارائه دهد. استفاده از CDN می تواند در برخی موارد به طور قابل توجهی TTFB وب سایت شما را بهبود بخشد.

دانش خود را تست کنید

بعدی: درک مسیر بحرانی

اکنون که با برخی از ملاحظات عملکرد مرتبط با HTML وب سایت خود آشنا شده اید، در موقعیت بهتری هستید تا مطمئن شوید که می تواند در سریع ترین زمان ممکن بارگذاری شود - اما این تنها شروع یادگیری عملکرد وب است. در مرحله بعد، نظریه پشت مسیر رندر بحرانی پوشش داده می شود. این ماژول مفاهیم کلیدی مانند رندر-مسدود کردن و تجزیه-مسدود کردن منابع، و نقشی که آنها در دریافت رندر اولیه صفحه در مرورگر در سریع ترین زمان ممکن دارند را شرح می دهد.