چکلیست سرعت صفحهٔ فرود؛ ۸ مورد قبل از انتشار
زمین را با لایه‌بندی روشن کنیم: کارگاه اصلاح سرعت صفحهٔ فرود با مثال واقعی کارگاه اصلاح یک صفحهٔ سنگین موجود است و ترتیب جراحی آن را نشان میدهد؛ این مقاله از سمت مقابل همان زمین را می‌بندد — گیت هشتچکی که هر صفحهٔ فرود باید پیش از دکمهٔ انتشار پاس کند. چارچوب محتوایی خود صفحه را هم چارچوب ساخت صفحه فرود سئوشده جداگانه ساخته است؛ این مقاله لایهٔ فنی همان چارچوب را مکتوب میکند.
چرا گیت قبل از انتشار، نه بعد؟ چون اصلاح پس از انتشار دو هزینه دارد: هفته‌های اول عمر صفحه با نسخهٔ کند ایندکس و سنجیده میشود، و هر بازطراحیِ وسط کمپین، بازخورد در جریان را به‌هم می‌ریزد. به تجربهٔ ما همان بیست دقیقه‌ای که تیم حوصله‌اش را ندارد، بعداً چند جلسه کارشناسی میشود. گیت مکتوب، این بده‌بستان را حذف میکند.
سرعت صفحهٔ فرود را چرا قبل از انتشار گیت می‌کنیم؟
صفحهٔ فرود، سنگین‌ترین انتظار را هم دارد: ورودی‌هایش پولی یا رقابتی‌اند و بازدیدکننده‌اش حوصلهٔ کمتری از بازدیدکنندهٔ مقاله دارد. به تجربهٔ ما صفحهٔ فرود برخلاف مقاله با یک بار «راه‌افتادن» مدیریت نمی‌شود؛ هر بنر تازه، هر فرم اضافه و هر افزونهٔ جدید، بارش را عوض میکند. پس نقطهٔ کنترل باید جایی باشد که تغییر ساخته میشود: قبل از انتشار، نه بعد از شکایت.
این گیت دو ویژگی دارد که آن را از نمره‌گرفتنِ صرف جدا میکند. اول، ترتیب‌دار است: از تصویر هیرو شروع میشود و به سنجش می‌رسد، چون بیشترین بار صفحه معمولاً در همان بخش بالایی است. دوم، مالک دارد: هر مورد یک مسئول روشن دارد — محتوا، فنی یا هر دو — تا چکلیست روی کاغذ نماند. هشت مورد پیش رو با همین منطق چیده شده‌اند.
یک مرز هم بگذاریم: گیت پیش از انتشار بهانهٔ کمال‌گرایی نیست. هدف، صفحهٔ بینقص نیست؛ صفحه‌ای است که در دستگاه واقعی کاربر روان باشد و بعد از انتشار نیازمند جراحی نباشد. تفاوتش در تصمیم است: گیتِ هشتچکی در بیست دقیقه تمام میشود و سند تصمیم می‌سازد، اما کمال‌گرایی بی‌پایان انتشار را به هفتهٔ بعد می‌سپارد.
موارد ۱ و ۲؛ تصویر هیرو و فونت‌ها
مورد ۱، تصویر هیرو است؛ معمولاً سنگین‌ترین فایل صفحه. سه چیز را چک کنید: ابعاد بریده‌شده برای قالب واقعی، نه تصویر چهاربرابر که مرورگر کوچکش کند؛ فرمت فشردهٔ مدرن به‌جای عکس خام؛ و بلا lazyماندن هیرو — تصویری که اول دیده میشود باید بدون تعویق بار شود، lazyکردن آن همان چیزی را که می‌خواهید سریع باشد کند میکند. انتخاب افزونهٔ فشرده‌سازی را هم یکبار ببندید؛ مقایسهٔ افزونه‌های بهینه‌سازی تصویر این مقایسه را داده‌محور انجام داده است.
مورد ۲، فونت‌هاست. دو وزن کافی است؛ هر وزن اضافه یعنی یک فایل اضافه در مسیر بحرانی. فونت اصلی را از پیش بارگذاری کنید تا متن صفحه منتظر فایل فونت نماند و رشتهٔ جایگزین — مثل تاهوما برای فارسی — را طوری انتخاب کنید که پرش چیدمان دیده نشود. آیکون‌های تکراری را هم به فایل یک‌جا منتقل کنید تا هر آیکون یک درخواست نباشد. این دو مورد را حتماً روی موبایل بازچک کنید؛ همان فونتی که روی دسکتاپ بی‌صدا می‌آید، روی شبکهٔ ضعیف پرش چیدمان را به نمایش می‌گذارد.
موارد ۳ و ۴؛ اسکریپت‌ها و صفحه‌ساز
مورد ۳، اسکریپت‌هاست. فهرست هر چیزی که در این صفحه اجرا میشود را روی کاغذ بیاورید: رهگیری، چت آنلاین، نقشه، ویدیو. هر موردی که به پیام صفحه کمک نمی‌کند حذف شود و هر موردی که لازم است، تا اولین تعامل کاربر به تأخیر بیفتد — چت نیازی نیست در همان ثانیهٔ اول بالا بیاید. اسکریپت آزمایشی که ماه‌ها از حذفش گذشته، از فهرست پاک شود؛ به تجربهٔ ما بخش بزرگی از بار قابل‌حذف، همین میراث‌های فراموش‌شده است. این فهرست را در پروندۀ صفحۀ فرود نگه دارید تا گیت بعدی از روی حافظه اجرا نشود.
مورد ۴، صفحه‌ساز و قالب است. بلوک‌های تکراری و استایل‌های بلااستفاده‌ای که صفحه‌ساز با خود می‌آورد را در نسخهٔ انتشار نگه ندارید؛ ویجت تزئینیِ پایین صفحه که در موبایل سطرهای طولانی می‌سازد، همانجا حذف شود. چیدمان ساده‌تر با همان پیام، هم سبک‌تر است و هم برای بازدیدکنندهٔ موبایلی خواناتر. اگر قالب چند نسخهٔ جزئی دارد، سبک‌ترین نسخهٔ درست را انتخاب کنید، نه پرمایه‌ترین را. در نتیجه، همان پیام تجاری با فایل کمتر به دست مخاطب می‌رسد.
موارد ۵ و ۶؛ کش، فشرده‌سازی و CDN
مورد ۵، کش است. کش صفحه و کش مرورگر باید فعال و — مهم‌تر از آن — پس از هر تغییر قالب، آزمایش‌شده باشد؛ کش درست اما بدون تست، فرم را هم می‌تواند از کار بیندازد و این خطا در صفحهٔ فرود گران است. قاعدهٔ ما ساده است: هر تغییر ساختاری، یک بازدید تست از نسخهٔ کش‌شده برای کاربر تازه و کاربر برگشتی. این تست را در پروندۀ تغییرات ثبت کنید تا ریشۀ هر خرابی بعدی قابل‌ردیابی بماند.
مورد ۶، فشرده‌سازی و CDN است. فشرده‌سازی پاسخ سرور از سمت هاست روشن باشد و فایل‌های ثابت از طریق CDN سرو شوند؛ وقتی مخاطب شما در چند شهر پراکنده است، نزدیک‌بودن محتوا به او بخشی از سرعت را می‌سازد که هیچ بهینه‌سازی داخل سایت جای آن را نمی‌گیرد. این دو مورد یکبار درست تنظیم می‌شوند و بعد فقط در گیتِ تغییرات چک می‌شوند — نه هر بار از صفر. یادتان باشد پس از هر تغییر هاست یا دامنه، تنظیمات فشرده‌سازی و CDN را دوباره از سر بگیرید؛ این‌ها با انتقال از بین می‌روند.
مورد ۷؛ سنجش سهحالتی پیش از انتشار
مورد ۷، سنجش است و به تجربهٔ ما همان‌جایی است که گیت‌ها سست می‌شوند، چون «نمرهٔ خوب» بهانۀ تعویق انتشار میشود. ما سنجش را سهحالتی میبندیم تا تصمیم، تابع یک عدد نباشد. حالت اول، آزمون ابزار با پروفایل موبایل پیش از انتشار. حالت دوم، بازکردن صفحه روی یک دستگاه واقعی با شبکهٔ ضعیف‌شده — جایی که مشکلات واقعی کاربر دیده میشود. حالت سوم، پایش هفتهٔ نخست در گزارش‌های رفتار کاربر واقعی، تا اصلاح بعدی روی دادهٔ واقعی بنا شود.
در هر سه حالت، چیزی که دنبالش هستید تجربهٔ محسوس است، نه نمره: تصویر هیرو سر جایش می‌نشیند؟ متن منتظر فونت نمیماند؟ دکمهٔ اقدام در همان دید اول قابل‌لمس است؟ اگر پاسخ هر سه بله بود، منتظر عدد بینقص نمانید؛ صفحه‌ای که در دنیای واقعی روان است، به مرور نمره‌اش هم بالا می‌آید. اگر نه، فهرست هشت‌تایی را همانجا مرور کنید و هر مورد را با تاریخ و مسئول ثبت کنید تا ریشهٔ مشکل قابل‌ردیابی بماند.
مورد ۸؛ قرارداد نگهداشت پس از انتشار
مورد ۸، قرارداد نگهداشت است؛ چون سرعت یک ویژگی نیست، یک وضعیت است که با هر تغییر می‌لغزد. برای صفحهٔ فرود سه بند مکتوب بگذارید: هر افزونه یا فونت تازه از همان گیت هشتچکی می‌گذرد؛ هر ماه یک بازبینی پانزدهدقیقهای روی صفحات پولساز انجام میشود؛ و هر تغییر، یک صاحب مشخص دارد که نتیجهٔ سنجش هفتهٔ بعدش را امضا میکند. همین سه بند جلوی بازگشت آرامِ سنگینی را می‌گیرد. علتش ساده است: تغییرها همیشه با انگیزۀ تجاری می‌آیند — بنر جدید، ابزار تازه — و بدون بند مکتوب، هیچ‌کس هزینهٔ سرعتی‌شان را نمی‌پرسد.
قرارداد نگهداشت را به تقویم تیم وصل کنید، نه به حافظه؛ در تقویم محتوایی، ردیف ثابت «بازبینی فنی صفحات فرود» بگذارید. تیمی که این ردیف را دارد، بعد از شش ماه هم می‌داند صفحهٔ فرودش سبک است؛ تیمی که ندارد، معمولاً همانجا کشف میکند که سه اسکریپت آزمایشی از زمین و زمان بالا آمده‌اند و صفحه به‌آرامی سنگین شده است.
جمع‌بندی؛ گیت هشتچکی روی دیوار تیم
جمع‌بندی روی دیوار تیم: تصویر هیرو بریده و فشرده و بدون تعویق؛ دو وزن فونت با پیش‌بارگذاری؛ فهرست اسکریپت‌ها با تأخیر تا تعامل؛ صفحه‌ساز بدون بلوک اضافه؛ کش فعال و تست‌شده؛ فشرده‌سازی و CDN روشن؛ سنجش سهحالتی به‌جای پرستش یک نمره؛ و قرارداد نگهداشت مکتوب با مالک مشخص. هشت مورد، بیست دقیقه — و تفاوتش در هفته‌های اول عمر صفحه خودش را نشان میدهد.
اگر همین حالا چند صفحهٔ فرود منتشرشده دارید و حال پرچالش‌شان را نمی‌دانید، از سنجش شروع کنید نه از بازسازی: ممیزی رایگان دامنه وضع فعلی دامنه را نشان میدهد و قابلیت‌های پلتفرم سوئیت بخشی از این چک‌ها را در چرخهٔ انتشار پلتفرم پوشش میدهد و نقشهٔ کامل مقاله‌های این خوشه در هاب سرعت و کارایی وردپرس مرتب است. سرعت صفحهٔ فرود با گیتِ مکتوب مدیریت میشود، نه با نیت؛ چکلیست را چاپ کنید و کنار دکمهٔ انتشار بچسبانید. هر صفحهٔ فرود تازه از چرخهٔ بعدی، با این گیت وارد میدان میشود.
رصد ما، رشد شما.
سؤالات پرتکرار
این چکلیست برای صفحۀ فرود وردپرسی کافی است؟
برای گیت انتشار بله؛ هشت مورد پرتکرارترین عاملهای سنگینی صفحهٔ فرود را پوشش میدهد. برای صفحۀ سنگینِ موجود که اصلاح میخواهد، کارگاه گامبهگام ما را کنارش بخوانید.
نمرۀ ابزار سرعت چند قبول است؟
ما با «نمرۀ قبول» کار نمیکنیم؛ سنجش سهحالتی میبندیم: آزمون ابزار، دستگاه واقعی با شبکۀ ضعیف، و پایش هفتۀ نخست. صفحۀ روان در این سه حالت، منتظر عدد بینقص نمیماند.
تصویر هیرو را lazy بارگذاری کنیم؟
نه؛ هیرو اولین چیزی است که باید بدون تعویق بار شود و lazyکردنش همان بخش بحرانی را کُند میکند. lazy برای تصاویر پایین صفحه درست است، نه برای تصویر بالای صفحه.
بعد از انتشار افت سرعت دیدیم؛ چه کنیم؟
قرارداد نگهداشت را اجرا کنید: آخرین تغییرها را مرور کنید، معمولاً یک افزونۀ تازه یا بنر جدید عامل است. گیت هشتچکی همانجا دوباره اجرا میشود، نه بازسازی کامل.
چند وقت یکبار صفحات فرود را از نظر سرعت بازبینی کنیم؟
به تجربهٔ ما یک بازبینی پانزدهدقیقهای در ماه برای صفحات پولساز کافی است، بهعلاوۀ اجرای کامل گیت بعد از هر تغییر ساختاری.
