قبل از بهینه‌سازی سرعت سایت؛ پیدا کردن بخش کند
اگر سایت دیر باز می‌شود، ابتدا مشخص کنید تأخیر در کدام مرحله است: پاسخ سرور، دریافت فایل‌ها یا نمایش محتوای اصلی. یک امتیاز پایین به‌تنهایی نمی‌گوید باید سرور را عوض کرد یا تصویر را کوچک‌تر کرد.
«سایت کند است» را به یک مشاهدهٔ قابل بازتولید تبدیل کنید
این جمله برای شروع بررسی مفید است، اما هنوز علت یا حتی مسیر مشکل را مشخص نمی‌کند. ممکن است صفحهٔ محصول دیر دیده شود، منو پس از لمس واکنش ندهد یا ذخیرهٔ سفارش در پیشخوان طول بکشد. هرکدام شاهد و ابزار متفاوتی می‌خواهند. پیش از خرید سرویس یا نصب ابزار تازه، یک نشانی و یک کار مشخص انتخاب کنید. بنویسید از چه نقطه‌ای شروع می‌کنید و چه اتفاقی را پایان انتظار می‌دانید. این تعریف کمک می‌کند بعداً نتیجهٔ تغییر واقعاً با مسئلهٔ اولیه مقایسه شود.
نمونهٔ فرضیِ مناسب این است: «در گوشی، صفحهٔ محصول را از یک بازدید تازه باز می‌کنم؛ متن می‌آید ولی عکس اصلی مدتی خالی می‌ماند.» این مشاهده از «امتیاز کم است» اطلاعات بیشتری می‌دهد. هنوز نمی‌دانیم تصویر بزرگ است، دیر درخواست می‌شود یا نمایش آن منتظر کد دیگری است. ثبت مشاهده، تشخیص نیست. هدف این مرحله محدودکردن پرسش است تا اصلاح احتمالی به مرحلهٔ مرتبط برسد و یک تغییر عمومیِ پرهزینه صرفاً به امید بهترشدن همه‌چیز انتخاب نشود یا نتیجهٔ یک مسیر به کل سایت تعمیم داده نشود.
زمان، مرورگر، نوع دستگاه، وضعیت ورود و نشانی را کنار شاهد نگه دارید. اگر مشکل فقط بعضی وقت‌ها رخ می‌دهد، دفعات و تفاوت شرایط مهم‌اند. یک فیلم کوتاهِ بدون اطلاعات شخصی یا ثبت مسیر می‌تواند به توضیح کمک کند. دادهٔ حساس لازم نیست در گزارش عمومی قرار بگیرد. خروجی این مرحله باید برای فرد دیگری قابل فهم باشد: بداند دقیقاً چه کاری را تکرار کند، کجا انتظار را ببیند و کدام شرایط را ثابت نگه دارد. اگر هنوز این تعریف را نداریم، نتیجهٔ آزمون‌های بعدی ممکن است دقیق به نظر برسد ولی به پرسش دیگری پاسخ دهد.
چند مسیر نماینده انتخاب کنید و شرایط را یکسان نگه دارید
صفحهٔ اصلی همیشه نمایندهٔ فروشگاه نیست. محصول دارای تنوع، فهرست دسته، سبد و حساب کاربری می‌توانند رفتار متفاوت داشته باشند. برای شروع، چند مسیر مرتبط با مشکل و استفادهٔ واقعی انتخاب کنید. لازم نیست همهٔ نشانی‌ها را یک‌جا بسنجید. نمونهٔ کوچکِ دارای دلیل از فهرست بزرگِ بدون تعریف مفیدتر است. برای هر مسیر مشخص کنید آیا کاربر وارد است، سبد دارد و دادهٔ شخصی یا قیمت خاص دریافت می‌کند. بدون این اطلاعات، مقایسهٔ دو اجرای ظاهراً مشابه ممکن است به دو مسیر پردازش متفاوت مربوط باشد.
در آزمایش فرضی، بار نخست یک محصولِ بدون کش و بار دوم همان صفحه از کش پاسخ می‌گیرد. اختلاف این دو می‌تواند قابل انتظار باشد، اما اگر یکی «قبل» و دیگری «بعد» نامیده شود، نتیجهٔ اصلاح بیش از واقع دیده خواهد شد. وضعیت مرورگر و لایه‌های پاسخ را ثبت کنید. چند بار همان شرایط را تکرار و پراکندگی را ببینید. تعداد اجرای مناسب به پرسش بستگی دارد؛ یک بار سریع یا کند نمایندهٔ همهٔ کاربران نیست. مثال عددیِ ساخته‌شده هم نباید به‌عنوان نتیجهٔ واقعیِ سایت یا مشتری منتشر شود و هر گزارش باید شاهد خودش را داشته باشد.
محدودیت آزمایش را صریح بنویسید. اگر فقط یک دستگاه در یک اتصال بررسی شده، نتیجه برای همان شرایط است. کاربر دیگر شاید فاصلهٔ شبکه یا توان پردازش متفاوتی داشته باشد. این محدودیت دلیل بی‌فایده‌بودن آزمایش نیست؛ کمک می‌کند ادعا اندازهٔ شواهد بماند. خروجیِ قابل استفاده، فهرست مسیرها با شرایط و شاهد است. بعد می‌توان تصمیم گرفت کدام تفاوت مربوط به مرورگر، شبکه یا پردازش است و برای کدام فرضیه دادهٔ بیشتری لازم داریم، به‌جای آنکه از یک نتیجهٔ عمومی فوراً علتِ قطعی ساخته شود یا همهٔ مسیرها یکسان فرض شوند.
دادهٔ واقعی کاربران و آزمون محلی کار یکسانی نمی‌کنند
آزمون کنترل‌شده برای پیدا کردن جزئیات و تکرار سناریو مناسب است. دادهٔ میدانی تجربهٔ ثبت‌شده در بازدیدهای واقعی را نشان می‌دهد. ممکن است نتیجه‌ها با هم فرق داشته باشند، چون دستگاه، شبکه و ترکیب کاربران یکسان نیستند. نبود دادهٔ میدانی هم به معنی خوب‌بودن تجربه نیست. این دو نوع شاهد را کنار هم بخوانید و در گزارش مشخص کنید هر عدد از کدام آمده است. امتیاز یک اجرای آزمایشگاهی را به‌عنوان وضعیت قطعیِ همهٔ مخاطبان معرفی نکنید و نتیجهٔ یک مسیر محلی را به کل سایت تعمیم ندهید.
چارچوب معیارهای تجربهٔ کاربر در web.dev بارگذاری، پاسخ به تعامل و پایداری دیداری را با معیارهای متفاوت توضیح می‌دهد. برای گزارش خودتان ابتدا مشخص کنید کدام جنبه مسئله است. صفحه‌ای که زود دیده می‌شود ممکن است هنگام انتخاب تنوع کند واکنش بدهد. صفحهٔ دیگر شاید تعامل مناسب داشته باشد اما تصویر اصلی دیر بیاید. یک عدد خلاصه می‌تواند این تفاوت را پنهان کند و نباید جای توضیحِ رفتار واقعی را بگیرد. معیار مرتبط باید همراه با تعریف و شرایط اندازه‌گیری خوانده شود تا اقدام به بخش درست برسد.
مثال فرضی: در آزمایش محلی، عکس سریع است ولی شکایت کاربران دربارهٔ دکمهٔ افزودن به سبد ادامه دارد. این دو شاهد الزاماً متناقض نیستند؛ شاید مسیر تعامل اصلاً در آزمایش دیده نشده باشد. به مشاهدهٔ اولیه برگردید و سناریوی مناسب ضبط کنید. هدف انتخاب شاهدی نیست که نتیجهٔ مطلوب بدهد. خروجی باید نشان دهد چه چیزی معلوم شده و چه چیزی هنوز بررسی نشده است. «اجرانشده» را با «بدون مشکل» یکی نکنید. همین تفکیک ساده مانع می‌شود گزارشِ ظاهراً کامل به تصمیم نامرتبط دربارهٔ سرور یا تصویر منجر شود و مشکل اصلی بی‌پاسخ بماند.
زمان دریافت HTML را با زمان دیده‌شدن محتوا جدا بخوانید
پیش از نمایش، مرورگر باید پاسخ و منابع لازم را دریافت و پردازش کند. تأخیر در هر بخش می‌تواند نتیجهٔ متفاوتی بسازد. TTFB به رسیدن نخستین بایتِ پاسخ مربوط است و معادل زمان اجرای خالصِ کد سرور نیست. مسیر اتصال و پاسخ هم در آن نقش دارند. راهنمای TTFB جزئیات تعریف را توضیح می‌دهد. هنگام مقایسه، ابزار و مبنای سنجش را ثبت کنید تا دو عدد با دامنهٔ متفاوت، به‌اشتباه شاهد افزایش یا کاهش یک علت معرفی نشوند و نتیجهٔ نامعلوم دقیق جلوه نکند.
اگر پاسخ HTML زود رسیده ولی محتوای اصلی دیر دیده می‌شود، هنوز باید زنجیرهٔ بعد از پاسخ را بررسی کرد. در مثال فرضی، ارتقای سرور ممکن است بخشی را کوتاه کند اما درخواستِ تصویری که با تأخیر آغاز می‌شود همچنان دیر شروع شود. برعکس، اگر بیشتر انتظار قبل از پاسخ است، کوچک‌کردن عکس نمی‌تواند همان بخش را توضیح دهد. این‌ها فرضیهٔ تشخیصی‌اند و نتیجهٔ سایت شما محسوب نمی‌شوند. شواهد هر مرحله لازم‌اند و نباید یک اصلاحِ محبوب را پیش از دیدن مسیر، علتِ قطعیِ همهٔ کندی‌ها فرض کرد یا صرفاً به نام فناوری تکیه کرد.
زمان پاسخِ API هم با زمان دیده‌شدن صفحه یکی نیست. شاید درخواستِ داخلی سریع‌تر شده ولی مرورگر هنوز کار دیگری دارد. گزارش قبل و بعد باید بگوید دقیقاً چه چیزی اندازه گرفته شده است. نمونه‌های ثبت‌شدهٔ پروژه در بخش نتایج اجرایی با شرایط خودشان خوانده می‌شوند و به همهٔ سایت‌ها تعمیم داده نمی‌شوند. برای تشخیص پروژهٔ تازه، همان نشانی و سناریوی مربوط لازم است. عدد خوب در یک لایه، به‌تنهایی تحویل کل تجربه را ثابت نمی‌کند و عدد بد هم بدون تفکیک مرحله‌ها، نسخهٔ آمادهٔ تغییر زیرساخت نخواهد بود.
آبشار درخواست‌ها را برای یافتن زنجیره بخوانید
در پنل شبکه می‌توان دید درخواست‌ها چه زمانی شروع شده‌اند و کدام منبع آغازشان کرده است. مرجع Network در Chrome DevTools ابزارهای این بررسی را توضیح می‌دهد. هدف فقط پیدا کردن بزرگ‌ترین فایل نیست. منبع کوچکی که خیلی دیر کشف می‌شود ممکن است مسیر مهمی را معطل کند. شروع، انتظار و دریافت را از هم جدا ببینید و به رابطهٔ منابع توجه کنید تا از روی طول یک نوار، بی‌دلیل علتِ قطعی دربارهٔ کد یا سرور ساخته نشود و شاهد در همان دامنهٔ خودش بماند.
فرض کنید تصویر اصلی پس از اجرای یک اسکریپت و درخواست داده وارد صفحه می‌شود. در این نمونهٔ فرضی، فایل تصویر حتی اگر سبک باشد، زودتر از آن زنجیره درخواست نمی‌شود. سؤال مناسب این است که آیا کشف تصویر می‌تواند زودتر و در مسیر معتبر انجام شود؟ پاسخ به ساختار واقعی وابسته است. صرف فشرده‌کردن دوبارهٔ تصویر شاید سهم کمی داشته باشد. ثبتِ آغازگر و ترتیب درخواست‌ها کمک می‌کند فرضیه روشن شود. درخواست ناموفق و تلاش مجدد هم باید دیده شوند؛ بارگذاری در نهایت موفق می‌تواند انتظار اضافیِ یک خطای پنهان را در نتیجهٔ خلاصه نشان ندهد.
برای مقایسه، فایل ثبت‌شده و شرایطش را نگه دارید. گزارش شبکه ممکن است شامل دادهٔ خصوصی یا سرآیند حساس باشد و نباید بی‌بررسی عمومی شود. نمونهٔ پاک‌سازی‌شده برای گفت‌وگو کافی است. هر مشاهده را به سؤال مشخص وصل کنید: کدام درخواست دیر شروع شد، کدام منبع منتظر بود و چه شاهدی فرضیه را رد می‌کند؟ این روش از فهرست کلیِ «منابع زیادند» قابل اقدام‌تر است. تعداد درخواست هم به‌تنهایی علت نیست و بدون نقش و زمانشان، نمی‌توان نتیجه گرفت ادغام یا حذف هر فایل تجربه را بهتر خواهد کرد یا کارکرد ضروری را حفظ خواهد کرد.
عنصر اصلی را بشناسید و مرحلهٔ تأخیرش را جدا کنید
بزرگ‌ترین محتوای نمای اولیه ممکن است تصویر یا بلوک متن باشد و با اندازهٔ صفحه تغییر کند. پیش از اصلاح، عنصرِ گزارش‌شده را در همان شرایط پیدا کنید. راهنمای بهینه‌سازی LCP تفکیک مسیر را توضیح می‌دهد: زمان پاسخ، انتظار آغاز منبع، دریافت و انتظار نمایش می‌توانند سهم متفاوتی داشته باشند. نباید همهٔ این زمان‌ها را «حجم عکس» نامید. اصلاح باید به مرحلهٔ دارای شاهد مربوط باشد تا یک تغییرِ ظاهراً فنی فقط کار را از بخشی به بخش دیگر جابه‌جا نکند یا نتیجهٔ کلی را بی‌دلیل بهتر فرض نکند.
در مثال فرضی، دریافت فایل کوتاه است ولی نمایش به فعال‌شدن گالری وابسته مانده. اینجا سؤال دربارهٔ وابستگیِ نمایش است. در مثال دیگر درخواست زود شروع می‌شود اما فایل نامتناسب دریافت طولانی دارد. این دو مسئله مسیر یکسانی نمی‌خواهند. حتی پس از اصلاح ممکن است عنصرِ اصلی عوض شود؛ گزارش تازه را دوباره بخوانید. کوتاه‌شدن یک مرحله لزوماً به همان مقدار از نتیجهٔ کل کم نمی‌کند، چون گلوگاه دیگری می‌تواند غالب شود. این توضیح تحلیلِ نمونه است و جای شاهد واقعیِ صفحهٔ شما را نمی‌گیرد یا تضمینِ نتیجهٔ عددی ایجاد نمی‌کند.
مطالعهٔ اصلاح گالری محصول یک نمونهٔ اجراییِ ثبت‌شده است؛ عدد و شرایط آن در همان صفحه معتبرند. برای سایت دیگر، بدون بررسی نمی‌توان همان نتیجه را وعده داد. خروجی بررسی باید عنصر، مرحلهٔ مسئله‌دار و فرضیهٔ اصلاح را روشن کند. اگر فقط یک امتیاز خلاصه داریم، هنوز دادهٔ کافی برای تصمیم دقیق نداریم. این مرحله مانع می‌شود چند تغییر بزرگ هم‌زمان اعمال و بعد به‌اشتباه همهٔ نتیجه به یک گزینه نسبت داده شود یا چیزی که آزمایش نشده، به‌عنوان بی‌مشکل در گزارش نهایی ثبت شود.
تصویر اصلی و تصویرهای پایین صفحه سیاست یکسان نمی‌خواهند
عکسی که کاربر در شروع می‌بیند با تصویر دور از نمای اولیه نقش متفاوتی دارد. تأخیر عمدی در منبع اصلی می‌تواند مسیر نمایش را عقب بیندازد، در حالی که برای بخش پایین‌تر ممکن است بارگذاری دیرتر مناسب باشد. راهنمای بارگذاری تنبل تصویر رفتار این امکان را توضیح می‌دهد. برچسب‌ها و اولویت را باید با نقش واقعیِ تصویر انتخاب کرد، نه با یک قاعدهٔ کور برای همهٔ تصاویر. ابزار بهینه‌سازی هم باید روی صفحهٔ واقعی و اندازه‌های مختلف بررسی شود تا نتیجه فقط در یک نمای آزمایشگاهی خوب نباشد.
نسخهٔ مناسب نمایش، نسبت تصویر و فضای رزروشده را بررسی کنید. فایل اصلیِ بسیار بزرگ ممکن است برای کارت کوچک لازم نباشد، اما کیفیت هم باید برای همان کاربرد کافی بماند. نام فرمت به‌تنهایی انتخاب درستِ اندازه و نمایش را ثابت نمی‌کند. در مثال فرضی، بعد از تبدیل فایل، مرورگر هنوز نسخهٔ بزرگ نامتناسب را می‌گیرد؛ آن وقت مسئلهٔ انتخاب منبع باقی است. از شاهد واقعی بفهمید کدام فایل دریافت شده و آیا همان نسخه‌ای است که انتظار داشتید. فرضِ کارکردنِ تنظیمات از روی پنل افزونه، جای دیدن نتیجهٔ شبکه را نمی‌گیرد یا کیفیت نمایش را تضمین نمی‌کند.
پس از تغییر، گالری، بزرگ‌نمایی و انتخاب تنوع را هم ببینید. سریع‌شدن یک تصویر با شکستن گزینهٔ دیگر تحویل موفق نیست. در گزارش بنویسید چه چیزی عوض شد و کدام مسیر کنترل شد. تصویر مشتری یا اطلاعات خصوصیِ محصول برای آزمون عمومی لازم نیست. هدف فقط کم‌شدن حجم نیست؛ رسیدن محتوای مناسب در زمان لازم و حفظ کارکرد است. دامنهٔ اصلاح می‌تواند از تنظیم ساده تا تغییر مسیر گالری متفاوت باشد و قبل از دیدن شواهد، تعداد افزونه یا نوع قالب به‌تنهایی علتِ قطعی معرفی نخواهد شد تا تصمیم به بخش مرتبط برسد.
پس از دریافت منابع، زمان پردازش مرورگر را بررسی کنید
ممکن است فایل‌ها دریافت شده باشند ولی صفحه هنوز واکنش یا نمایش مناسب نداشته باشد. در این حالت، فقط دیدن زمان شبکه کافی نیست. ضبط عملکرد می‌تواند نشان دهد مرورگر در آن بازه مشغول چه کاری است. راهنمای Performance در Chrome DevTools ابزار بررسی را معرفی می‌کند. یک ضبط را به همان مشاهدهٔ اولیه وصل کنید: در چه لحظه‌ای لمس یا تغییر رخ داد و چه فاصله‌ای تا نتیجه بود؟ بدون این رابطه، نام چند تابع یا فعالیتِ طولانی به‌تنهایی علتِ تجربهٔ کاربر را توضیح نمی‌دهد و نباید تشخیص قطعی ساخته شود.
مثال فرضی این است که انتخاب تنوع، محاسبه و بازسازی بخش بزرگی از صفحه را فعال می‌کند. HTML اولیه می‌تواند سریع باشد ولی تعامل همچنان سنگین بماند. در نمونهٔ دیگر، یک ابزار بیرونی پس از بارگذاری کار اضافه انجام می‌دهد. لازم است رفتار واقعی بررسی شود، نه اینکه هر اسکریپت بیرونی یا هر افزونه از پیش مقصر فرض شود. شاهد باید به فعالیت و نتیجهٔ قابل بازتولید مربوط باشد. حذف آزمایشیِ کنترل‌شده می‌تواند فرضیه را بسنجد، اما حذف کورکورانه در سایت عملیاتی راه مناسبی برای حفظ کارکرد نیست و نتیجهٔ یک اجرا هم باید با شرایطش گزارش شود.
خروجی مناسبِ این مرحله، بازهٔ زمانی و فعالیتِ مرتبط با تأخیر است. اگر هنوز نمی‌دانیم کدام کار ضروری یا تکراری است، نیاز به بررسی کد باقی می‌ماند. ابزار فقط داده می‌دهد و نامِ آشنا به‌تنهایی مسئولیت خطا را ثابت نمی‌کند. پس از اصلاح، همان تعامل و مسیرهای مرتبط دوباره بررسی خواهند شد. هدف، پاسخ بهتر همراه با کارکرد درست است. عدد بارگذاریِ صفحه به‌تنهایی موفقیت این تغییر را ثابت نمی‌کند و گزارش باید بگوید چه چیزی در تعامل سنجیده شد تا نتیجه با مسئلهٔ اصلی و دامنهٔ شواهد یکسان بماند.
کش مرورگر، کش مشترک و پردازش اصلی را مخلوط نکنید
ممکن است پاسخ از لایه‌ای نزدیک کاربر بیاید و پردازش اصلی اصلاً در آن درخواست انجام نشود. در این حالت، زمان مشاهده‌شده نمایندهٔ اجرای تازهٔ برنامه نیست. تعریف لایه و شاهدِ وضعیت مهم‌اند. راهنمای کش HTTP در MDN دربارهٔ پاسخ‌های ذخیره‌شده و قواعدشان توضیح می‌دهد. برای گزارش خودتان مشخص کنید چه چیزی واقعاً بررسی شده است. سریع‌بودن یک پاسخِ ذخیره‌شده به‌تنهایی کندیِ پردازش اصلی را رد نمی‌کند و مقایسهٔ حالت‌های متفاوت نباید به‌عنوان نتیجهٔ یک اصلاح معرفی شود یا موفقیت همهٔ بازدیدها را ثابت کند.
در مثال فرضی، مهمان صفحهٔ عمومی را سریع می‌بیند ولی کاربر واردشده دادهٔ متفاوتی می‌گیرد و کند است. این تفاوت می‌تواند سؤال بررسی باشد، نه دعوت به کش‌کردن بی‌ضابطهٔ همه‌چیز. قیمت شخصی، حساب و سبد باید دادهٔ درست بگیرند. کوتاه‌شدن زمان با نمایش اطلاعات کاربر دیگر یا وضعیت کهنه، بهبود معتبر نیست. قواعد باید با رفتار واقعی برنامه سازگار باشند. راهنمای کش و سبد ووکامرس بحث مرتبط را جدا باز می‌کند. وجود یک تنظیمِ فعال در پنل، کافی نیست؛ نتیجهٔ پاسخ و جداسازی داده هم باید بررسی شوند تا تجربه و درستی هم‌زمان حفظ شوند.
پیش از تغییر، حالت‌های نماینده را ثبت کنید و بعد همان‌ها را کنترل کنید. شواهد می‌توانند نشانی، نقش و نشانهٔ وضعیت پاسخ باشند، بدون انتشار دادهٔ حساس. اگر ابزار وضعیت را نشان نمی‌دهد، این نبود شاهد را به‌عنوان قطعیت گزارش نکنید. پاک‌کردن همهٔ کش‌ها هم خودش شرایط را عوض می‌کند و باید در گزارش معلوم باشد. خروجیِ قابل استفاده می‌گوید کدام مسیر از کجا پاسخ گرفته و کدام حالت هنوز بررسی نشده است. این مرز به تصمیم دربارهٔ تصویر، برنامه یا زیرساخت کمک می‌کند و از تعمیم عددِ یک لایه به کل سیستم جلوگیری خواهد کرد.
صفحهٔ فروشگاه را با چند کار ضروری کنترل کنید
برای یک فروشگاه، بازشدن صفحه پایان تجربه نیست. مشتری باید بتواند گزینه را انتخاب کند، تعداد را عوض کند و نتیجهٔ معتبر در سبد ببیند. پس از اصلاح سرعت، مسیرهای مرتبط با تغییر باید کار کنند. این کنترل به معنی تکرار بی‌دلیل همهٔ آزمون‌ها نیست؛ دامنه با خطر واقعیِ تغییر انتخاب می‌شود. اگر فقط نسخهٔ تصویر عوض شده، منطق مالی شاید دامنهٔ مستقیم نباشد، ولی گالری و انتخاب تصویر باید دیده شوند. اگر کش یا اسکریپت خرید تغییر کرده، کنترل سبد و دادهٔ شخصی اهمیت بیشتری خواهد داشت و نباید حذف شود.
یک سناریوی فرضیِ خوب می‌تواند افزودن تنوع مشخص و مشاهدهٔ همان گزینه در سبد باشد. نتیجهٔ ظاهری و ثبت معتبر باید با هم بخوانند. دکمه‌ای که زود واکنش نشان می‌دهد ولی درخواست را اشتباه می‌فرستد، بهبود موفق نیست. آزمون پرداخت هم در محیط مناسب و بدون تراکنش واقعی انجام می‌شود. سرعت نباید بهانهٔ ارسال سفارش یا پیام واقعی برای امتحان ظاهر باشد. دادهٔ ساختگی می‌تواند مسیر را نشان دهد. اگر محیط محدود است، مرزِ آن در گزارش می‌آید و چیزی که آزمایش نشده، بی‌مشکل معرفی نخواهد شد تا وضعیت واقعیِ تحویل روشن بماند.
برای مشکل خاص، راهنمای مرتبط را انتخاب کنید. کندی پیشخوان ووکامرس با صفحهٔ عمومی یکی نیست و اقدام‌های زمان‌بندی‌شده هم مسیر جداگانه‌ای دارند. ممکن است یک تغییر به بخشی کمک کند و مسئلهٔ دیگر باقی بماند. گزارش باید همین را بگوید. عنوان عمومیِ افزایش سرعت نباید چند نتیجهٔ متفاوت را پنهان کند. تعریف خروجی برای هر مسیر کمک می‌کند صاحب فروشگاه بداند چه چیزی اصلاح شده و ادامهٔ لازم چیست، بدون آنکه عدد یک صفحه به‌عنوان موفقیت کل عملیات یا ضمانت تجربهٔ همهٔ مشتریان معرفی شود.
شواهد سرور باید به همان زمان و درخواست مربوط باشند
اگر انتظار پیش از پاسخ غالب است، دادهٔ سمت سرور می‌تواند مفید باشد. اما مشاهدهٔ مصرف منابع در یک لحظهٔ نامرتبط کافی نیست. زمان، مسیر و وضعیت درخواست را با شاهد تطبیق دهید. گزارشِ پردازش، خطا یا پاسخِ سرویس وابسته ممکن است سؤال را محدود کند. از روی یک عدد کلی دربارهٔ حافظه یا پردازنده، علتِ قطعیِ همهٔ کندی‌ها ساخته نمی‌شود. ابزار مناسب به محیط واقعی بستگی دارد و تغییر تنظیمات عملیاتی باید با برنامهٔ بازگشت و شناخت اثر انجام شود، نه با نسخهٔ عمومیِ بی‌بررسی که ممکن است مسیرهای دیگر را مختل کند.
مثال فرضی: در زمان شکایت، صفحهٔ مشخص منتظر یک وابستگی بیرونی است ولی میانگین مصرف دستگاه عادی دیده می‌شود. این دو مشاهده الزاماً متناقض نیستند. در نمونهٔ دیگر، درخواست‌های هم‌زمانِ یک عملیات داخلی می‌توانند انتظار بسازند. هدف این است که شاهد به مسیر مرتبط برسد. تغییر سرور پیش از شناخت می‌تواند فقط شرایط را عوض کند و علت را پنهان نگه دارد. برعکس، گاهی محدودیتِ واقعی زیرساخت با داده تأیید می‌شود و اقدام متناسب لازم خواهد بود. تصمیم باید اندازهٔ شواهد باشد و از نام سرویس یا فناوری به‌تنهایی نتیجه نخواهد گرفت.
گزارش‌های فنی ممکن است اطلاعات خصوصی داشته باشند. پیش از اشتراک عمومی، دادهٔ حساس بررسی و حذف شود. برای برآورد، نمونهٔ پاک‌سازی‌شده و شرح مسیر کافی است. پیکربندی و دسترسی واقعی در مرحلهٔ مناسب بررسی خواهند شد. خروجی این بخش، فرضیهٔ محدود و شاهد مرتبط است، نه فهرست بلندِ احتمال‌ها بدون اولویت. اگر داده کافی نیست، نیاز به اندازه‌گیری ثبت می‌شود. این کار مانع می‌شود اصلاحی پرهزینه به‌عنوان ضرورت قطعی معرفی شود وقتی هنوز معلوم نیست کدام لایه مسئول است یا چه نتیجه‌ای از تغییر باید انتظار داشت و چگونه قرار است سنجیده شود.
هر بار یک فرضیهٔ قابل رد را امتحان کنید
فرضیه باید به مشاهدهٔ خاصی پاسخ دهد. «همه‌چیز را بهینه کنیم» برای نسبت‌دادن نتیجه مناسب نیست. می‌توان گفت در نمونهٔ فرضی، آغاز دیرهنگام یک منبع سهم اصلیِ انتظار است و تغییرِ مشخص باید همان بخش را کوتاه کند. پیش از اجرا، انتظار و شاهدِ رد را بنویسید. اگر نتیجه تغییر نکرد، فرضیه شاید کافی نبوده یا گلوگاه دیگری غالب شده است. این شکستِ داده‌ای می‌تواند مفید باشد و نباید با انتخاب یک اجرای مطلوب پنهان شود یا عددِ متفاوتِ نامرتبط به‌جای نتیجهٔ واقعی معرفی شود.
تغییرهای مستقل را تا جایی که عملی است جدا نگه دارید. اگر هم‌زمان کش، تصویر، کد و زیرساخت عوض شوند، سهم هرکدام نامعلوم می‌ماند. گاهی اجرای گروهی لازم است؛ در آن صورت همین محدودیت گزارش می‌شود. دادهٔ قبل و بعد باید شرایط قابل مقایسه داشته باشند و چند اجرا پراکندگی را نشان دهند. معیار اصلی را با مشاهدهٔ کاربر مرتبط نگه دارید. صرف بهترشدن امتیاز خلاصه، درستیِ فرضیه را ثابت نمی‌کند اگر مسیرِ مشکل‌دار اصلاً در آزمون دیده نشده باشد. این روش از ادعای بیش از شواهد جلوگیری می‌کند و تصمیمِ ادامه را روشن‌تر خواهد کرد.
برای هر اقدام، محدوده، روش برگشت و کنترل کارکرد را مشخص کنید. تغییر کم‌اثر و قابل بازگشت می‌تواند آزمایش مناسب‌تری از جابه‌جایی بزرگِ بی‌تعریف باشد، اما انتخاب نهایی به محیط و ضرورت بستگی دارد. این مقاله نسخهٔ قطعی برای همهٔ سایت‌ها نمی‌دهد. خروجی باید معلوم کند چه چیزی انجام شد، چه شاهدی نتیجه را پشتیبانی می‌کند و چه پرسشی باز مانده است. اگر سناریو اجرا نشده، همان وضعیت ثبت می‌شود. گزارشِ صادقانهٔ محدود از ادعای کاملِ بدون داده مفیدتر است و برای مرحلهٔ بعد هم مبنای قابل استفاده باقی خواهد گذاشت.
اولویت را از اثر واقعی، هزینه و خطر تغییر بسازید
پس از تفکیک مسئله، چند اقدام ممکن است وجود داشته باشد. هرکدام را به شاهد و مسیر مربوط وصل کنید. گزینه‌ای که فقط روی یک فایل کم‌اهمیت اثر دارد، الزاماً اولویت همان گزینهٔ دارای سهم عمده نیست. هزینهٔ اجرا و نگهداری هم اهمیت دارد. خطر شکستن کارکرد ضروری باید دیده شود. تصمیم قرار نیست فقط از تعداد هشدارهای ابزار بیاید. بعضی هشدارها در سناریوی شما نقش کمتری دارند و بعضی مسئله‌های واقعی در گزارشِ خلاصه پررنگ نیستند؛ ارزیابی باید با مشاهده و دادهٔ همان صفحه هماهنگ بماند و نتیجهٔ آماده تجویز نکند.
نمونهٔ فرضی: دو پیشنهاد داریم، تغییر مسیر کشف تصویر و تعویض کامل زیرساخت. اگر شاهد فقط تأخیرِ بعد از پاسخ را نشان می‌دهد، هنوز برای ضرورتِ گزینهٔ دوم داده کافی نداریم. این به معنی نامناسب‌بودن همیشگیِ تغییر زیرساخت نیست؛ دامنهٔ شاهد محدود است. باید نتیجهٔ قابل انتظار و معیار تصمیم روشن باشند. برای فروشگاه، درستیِ سبد و دادهٔ شخصی هم بخشی از ارزیابی خواهد بود. سرعت بیشتر با خطای مالی یا نمایش اطلاعات نامرتبط، خروجی موفق نیست و نباید صرفاً به‌دلیل یک امتیاز بهتر پذیرفته شود تا هدف اصلی حفظ شود.
برنامهٔ اجرا می‌تواند مرحله‌ای باشد: یک اصلاحِ مرتبط، سنجش دوباره و سپس تصمیم دربارهٔ ادامه. لازم نیست از ابتدا همهٔ احتمال‌ها به کار قطعی تبدیل شوند. اگر دادهٔ کافی ندارید، کارِ لازم اندازه‌گیری است. اگر مسئلهٔ اصلی مشخص است، اقدام و خروجی نوشته می‌شوند. این رویکرد به صاحب سایت کمک می‌کند بداند هزینه برای چه پرسش و نتیجه‌ای صرف می‌شود. قرارداد یا پیشنهاد نباید عددی تضمین کند که هنوز شرایط و مرجعش معلوم نیست. زمان و نتیجهٔ واقعی با همان محیط تعریف خواهند شد و دامنهٔ ادعا اندازهٔ آزمون باقی می‌ماند.
گزارش پایان باید قابل مقایسه و قابل استفاده باشد
نشانی، زمان، دستگاه، وضعیت ورود و کش کنار نتیجهٔ قبل و بعد بیایند. تعریف معیار هم لازم است؛ پاسخ API، نخستین بایت و نمایش محتوای اصلی یک عدد نیستند. اگر شرایط تغییر کرده، محدودیت را بنویسید. شاهد تصویری یا ثبت پاک‌سازی‌شده می‌تواند مقایسه را روشن کند. عددِ یک اجرای منتخب به‌تنهایی کافی نیست. هدف گزارش این است که فرد دیگری بفهمد چه چیزی تغییر کرده و نتیجه تا کجا معتبر است، نه اینکه چند عددِ بی‌تعریف کنار هم قرار بگیرند و به‌عنوان موفقیت همهٔ تجربه معرفی شوند.
کارکردهای مرتبط و موارد باز هم ثبت خواهند شد. اگر هنوز مشکل تعامل یا پیشخوان باقی است، همین را مشخص کنید. دادهٔ کاربران واقعی ممکن است بعداً تصویر کامل‌تری بدهد و زمان ارزیابی آن با آزمایش محلی یکسان نیست. رتبهٔ جست‌وجو نیز از یک اصلاح سرعت به‌تنهایی تضمین نمی‌شود. این مقاله دربارهٔ تشخیص و سنجش است و نتیجهٔ تجاری یا رتبهٔ مشتری نمی‌سازد. منابع رسمیِ پیوندشده مرجع تعریف ابزار و معیارند؛ مثال‌های متن فرضی‌اند و نباید به‌عنوان آزمون انجام‌شدهٔ سایت شما یا سابقهٔ تازهٔ اجرایی گزارش شوند.
برای بررسی پروژه، از خدمت سرعت و سرور می‌توانید شروع کنید. نشانیِ مسئله‌دار، شرح مشاهده و شرایط تکرار را بفرستید؛ دادهٔ خصوصی لازم نیست. ابتدا مشخص می‌شود کدام شاهد کم است و کدام مسیر باید سنجیده شود. پس از آن دامنهٔ اصلاح و معیار تحویل پیشنهاد خواهد شد. اگر مشکل اصلی با ابزار یا جریان دیگر مرتبط باشد، همان مسیر جدا بررسی می‌شود. تصمیمِ خوب از سؤال مشخص و شاهد معتبر می‌آید و با ثبت محدودیت‌ها قابل دفاع می‌ماند، بدون آنکه یک امتیاز یا نام فناوری جای فهمیدن علت واقعی را بگیرد.