جستجو
برای جستجو متن مورد نظر وارد کنید و Enter بزنید برای بستن Esc بزنید.
سرعت سایت وردپرسی فقط به عددی که در PageSpeed Insights نمایش داده میشود محدود نیست. ممکن است یک سایت در یک تست آزمایشگاهی امتیاز بالایی بگیرد، اما کاربران واقعی هنگام باز کردن صفحه، مشاهده محتوای اصلی یا کلیک روی عناصر مختلف با تأخیر مواجه شوند.
برای ارزیابی تجربه واقعی کاربر، گوگل از معیارهای Core Web Vitals استفاده میکند. این مجموعه سه شاخص اصلی دارد: LCP برای سنجش سرعت نمایش محتوای اصلی، INP برای بررسی پاسخگویی صفحه به تعاملات کاربر و CLS برای اندازهگیری ثبات بصری صفحه.
محدوده مناسب این معیارها برای وضعیت Good شامل LCP حداکثر ۲.۵ ثانیه، INP حداکثر ۲۰۰ میلیثانیه و CLS حداکثر ۰.۱ است. ارزیابی دادههای میدانی نیز بر اساس صدک ۷۵ انجام میشود، بنابراین نتیجه یک تست منفرد نمیتواند بهتنهایی وضعیت تمام کاربران سایت را مشخص کند.
در وردپرس، عملکرد سایت نتیجه ترکیب عوامل مختلفی مانند قالب، افزونهها، تصاویر، فونتها، CSS، JavaScript، PHP، سرور، کش و دیتابیس است. به همین دلیل، افزایش سرعت وردپرس باید بر اساس علت واقعی مشکل انجام شود، نه مجموعهای از تنظیمات عمومی که برای همه سایتها یکسان هستند.
WordPress 6.9 نیز در بخش عملکرد تغییرات مهمی ایجاد کرده است. بهینهسازی بارگذاری استایلهای Block، مدیریت بهتر Scriptها، پشتیبانی از fetchpriority برای Scriptها و Script Moduleها، کاهش منابع مربوط به Blockهای مخفی، بهبود WP-Cron و برخی بهینهسازیهای Query و Cache از جمله این تغییرات هستند.
LCP مدت زمانی را اندازهگیری میکند که طول میکشد بزرگترین عنصر محتوایی قابل مشاهده در Viewport اولیه نمایش داده شود.
این عنصر میتواند تصویر اصلی مقاله، تصویر Hero، یک تیتر بزرگ یا بخش قابل توجهی از محتوای متنی باشد.
LCP فقط به حجم تصویر وابسته نیست. زمان پاسخ سرور، دریافت منابع، CSS، JavaScript، زمان پردازش مرورگر و Render شدن عنصر هم میتوانند روی آن تأثیر بگذارند.
INP پاسخگویی صفحه به تعاملات کاربر را بررسی میکند. کلیک روی دکمه، باز کردن منو، استفاده از جستوجو یا تعامل با فرم میتواند در این معیار تأثیر داشته باشد.
اگر JavaScript سنگین باعث شود Main Thread برای مدت طولانی مشغول باشد، کاربر ممکن است بعد از کلیک برای مشاهده نتیجه منتظر بماند.
CLS میزان جابهجایی غیرمنتظره عناصر صفحه را اندازهگیری میکند.
نمایش تبلیغ بدون فضای رزروشده، بارگذاری تصویر بدون ابعاد مشخص یا تغییر ناگهانی محتوای صفحه نمونههایی از عواملی هستند که میتوانند باعث Layout Shift شوند.
قبل از تغییر تنظیمات وردپرس باید مشخص کنید عنصر LCP صفحه چیست.
در یک مقاله ممکن است تصویر Featured Image عنصر LCP باشد، در حالی که در یک صفحه خدمات، تیتر اصلی یا یک بخش Hero این نقش را داشته باشد.
اگر عنصر LCP را نشناسید، ممکن است زمان زیادی را صرف بهینهسازی بخشی کنید که تأثیر چندانی بر مشکل اصلی ندارد.
برای بررسی LCP میتوانید از PageSpeed Insights و Chrome DevTools استفاده کنید.
یکی از اشتباهات رایج، فعال کردن Lazy Loading برای تمام تصاویر صفحه است.
تصاویر پایین صفحه معمولاً گزینه مناسبی برای Lazy Loading هستند، اما اگر تصویر اصلی بالای صفحه همان عنصر LCP باشد، تأخیر در درخواست آن میتواند عملکرد LCP را بدتر کند.
در شرایطی که نیاز به تعیین اولویت یک تصویر وجود دارد، میتوان از fetchpriority="high" استفاده کرد:
<img
src="hero.webp"
width="1200"
height="630"
fetchpriority="high"
decoding="async"
alt="تصویر اصلی مقاله">
این ویژگی باید با احتیاط استفاده شود و نباید روی تعداد زیادی از منابع صفحه قرار گیرد.
وردپرس از نسخه 6.3 قابلیت افزودن fetchpriority="high" به تصاویر احتمالی LCP را در Core دنبال کرده است. در WordPress 6.9 نیز پشتیبانی از fetchpriority برای Scriptها و Script Moduleها گسترش یافته است. بنابراین قبل از افزودن دستی این ویژگی، خروجی سایت را بررسی کنید.
یکی از رایجترین دلایل مصرف غیرضروری منابع در سایتهای وردپرسی، استفاده از تصاویر بزرگتر از اندازه واقعی نمایش است.
فرض کنید تصویر یک مقاله روی موبایل با عرض ۳۶۰ پیکسل نمایش داده میشود، اما مرورگر یک فایل ۳۰۰۰ پیکسلی دریافت میکند. در این حالت داده بسیار بیشتری از نیاز واقعی کاربر منتقل خواهد شد.
وردپرس برای تصاویر محتوایی از قابلیت Responsive Images استفاده میکند و میتواند با srcset و sizes نسخه مناسبتری را در اختیار مرورگر قرار دهد.
نمونه ساده:
<img
src="image-1200.webp"
srcset="
image-480.webp 480w,
image-768.webp 768w,
image-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, 768px"
width="1200"
height="800"
alt="تصویر مقاله">
در یک سایت وردپرسی معمولاً لازم نیست این ساختار را برای تمام تصاویر بهصورت دستی بنویسید. بهتر است ابتدا بررسی کنید قالب و سیستم رسانهای وردپرس چگونه تصاویر Responsive را مدیریت میکنند.
فرمت تصویر نیز اهمیت دارد. WebP و AVIF در بسیاری از شرایط میتوانند حجم فایل را کاهش دهند، اما انتخاب فرمت باید با توجه به نوع تصویر، کیفیت موردنیاز و سازگاری مرورگر انجام شود.
فرض کنید یک مقاله ۲۰ تصویر دارد، اما کاربر هنگام ورود به صفحه فقط سه تصویر اول را میبیند.
اگر تمام تصاویر همزمان بارگذاری شوند، منابع بیشتری در مرحله ابتدایی بارگذاری مصرف خواهد شد.
Lazy Loading به مرورگر اجازه میدهد تصاویر غیرضروری را تا زمانی که به محدوده موردنیاز نزدیک نشدهاند، دریافت نکند.
با این حال، نباید یک قانون ثابت برای تمام تصاویر تعریف کرد.
تصاویر مهم در بخش ابتدایی صفحه باید سریعتر دریافت شوند، در حالی که تصاویر پایین صفحه معمولاً گزینه بهتری برای Lazy Loading هستند.
هدف این است که منابع موردنیاز برای نمایش اولیه صفحه با منابع غیرضروری رقابت نکنند.
CSS میتواند بخشی از مسیر رندر اولیه صفحه باشد. اگر قالب یا افزونهها فایلهای CSS بزرگی را در تمام صفحات بارگذاری کنند، مرورگر باید منابعی را دریافت و پردازش کند که ممکن است در آن صفحه اصلاً استفاده نشوند.
برای بررسی CSS اضافی میتوانید از Chrome DevTools و بخش Coverage استفاده کنید.
موارد زیر ارزش بررسی دارند:
با این حال، حذف دستی CSSهای هسته وردپرس بدون بررسی دقیق توصیه نمیشود.
WordPress 6.9 در زمینه بارگذاری استایلهای Block تغییرات مهمی داشته است. در Classic Themeها، استایلهای Block اکنون بهصورت On-Demand مدیریت میشوند و Core برای کاهش CSS غیرضروری و بهبود مسیر رندر، تغییرات دیگری نیز اعمال کرده است. در آزمایشهای رسمی وردپرس، میزان CSS صفحه نمونه در قالبهای Bundled پس از این تغییرات بهطور میانگین حدود ۴۵ درصد کاهش داشته است.
بنابراین قبل از حذف دستی منابعی مانند wp-block-library باید خروجی واقعی سایت بررسی شود. حذف کورکورانه CSS اصلی وردپرس میتواند باعث خراب شدن ظاهر Blockها شود.
ممکن است یک افزونه فقط در یک صفحه استفاده شود، اما فایلهای CSS و JavaScript آن در تمام سایت بارگذاری شوند.
فرض کنید افزونه فرم تماس فقط در صفحه تماس موردنیاز است. در این حالت بهتر است منابع آن در سایر صفحات بارگذاری نشوند.
میتوان این کار را با wp_dequeue_script() و wp_dequeue_style() انجام داد.
نمونه:
add_action('wp_enqueue_scripts', function () {
if (!is_page('contact')) {
wp_dequeue_script('contact-form-script');
wp_dequeue_style('contact-form-style');
}
}, 100);
در این کد، contact-form-script و contact-form-style فقط Handleهای نمونه هستند. در سایت واقعی باید Handleهای واقعی ثبتشده توسط افزونه را پیدا کنید.
همچنین Dependencyهای هر Script و Style باید بررسی شوند. اگر فایل دیگری به منبع موردنظر وابسته باشد، حذف آن میتواند باعث از کار افتادن بخشی از سایت شود.
به همین دلیل، این روش باید ابتدا در محیط آزمایشی یا پس از تهیه Backup بررسی شود.
Defer و Delay دو مفهوم متفاوت در مدیریت JavaScript هستند.
با defer، فایل JavaScript میتواند در زمان پردازش HTML دریافت شود، اما اجرای آن تا بعد از Parse شدن HTML به تعویق میافتد.
Delay معمولاً به تأخیر انداختن اجرای Script تا یک رویداد، تعامل کاربر یا زمان مشخص اشاره دارد.
برای مثال، برخی Scriptهای Analytics، ابزارهای چت یا سرویسهای Third-Party ممکن است برای نمایش اولیه محتوای صفحه ضروری نباشند.
اما نباید همه JavaScriptهای سایت را Delay کرد.
منوی اصلی، جستوجو، فرمها، سبد خرید و برخی قابلیتهای تعاملی ممکن است برای عملکرد صحیح به JavaScript فوری نیاز داشته باشند.
بنابراین هر Script باید بر اساس نقش واقعی آن در صفحه بررسی شود.
INP صرفاً به حجم فایل JavaScript مربوط نیست.
ممکن است یک فایل JavaScript نسبتاً کوچک باشد، اما هنگام کلیک کاربر عملیات سنگینی انجام دهد و Main Thread را برای مدت قابل توجهی درگیر کند.
عواملی مانند موارد زیر میتوانند INP را تحت تأثیر قرار دهند:
اگر INP ضعیف است، صرفاً Minify کردن JavaScript راهکار کاملی نیست.
باید مشخص شود کدام تعامل کاربر باعث ایجاد تأخیر شده و چه Taskای Main Thread را درگیر کرده است.
Chrome DevTools در بخش Performance برای پیدا کردن Long Taskها و بررسی عملکرد JavaScript ابزارهای مناسبی در اختیار توسعهدهنده قرار میدهد.
فونتهای وب میتوانند بخشی از منابع موردنیاز صفحه باشند، بهخصوص زمانی که قالب چندین وزن و سبک مختلف را بارگذاری میکند.
اگر سایت فقط از وزنهای ۴۰۰ و ۷۰۰ استفاده میکند، بارگذاری وزنهای ۳۰۰، ۵۰۰، ۶۰۰ و ۸۰۰ ضرورتی ندارد.
استفاده از WOFF2 و حذف وزنهای غیرضروری میتواند حجم منابع فونت را کاهش دهد.
نمونه:
@font-face {
font-family: 'Vazirmatn';
src: url('/fonts/Vazirmatn-Regular.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
}
font-display: swap باعث میشود مرورگر تا آماده شدن فونت اصلی بتواند از فونت جایگزین استفاده کند.
با این حال، تأثیر بهینهسازی فونت بر Core Web Vitals به ساختار صفحه، نوع محتوا و نحوه بارگذاری فونت بستگی دارد و نمیتوان برای همه سایتها یک میزان بهبود مشخص تعیین کرد.
یکی از عوامل رایج CLS، مشخص نبودن فضای موردنیاز یک عنصر قبل از بارگذاری آن است.
برای مثال، اگر تصویر بدون ابعاد مشخص وارد صفحه شود، مرورگر ممکن است بعد از دریافت تصویر مجبور شود محتوای اطراف را جابهجا کند.
برای تصاویر بهتر است ابعاد یا نسبت تصویر مشخص باشد:
<img
src="article.webp"
width="1200"
height="800"
alt="تصویر مقاله">
این موضوع فقط به تصاویر محدود نیست.
تبلیغات، iframeها، Embedها و محتوای پویا نیز میتوانند باعث تغییر Layout شوند.
رزرو فضای موردنیاز از ابتدا به مرورگر کمک میکند ساختار صفحه را پایدارتر نگه دارد.
تبلیغات یکی از منابع رایج Layout Shift در سایتهای محتوایی هستند.
فرض کنید صفحه ابتدا بدون تبلیغ نمایش داده شود و چند لحظه بعد یک Banner با ارتفاع ۲۵۰ پیکسل وارد صفحه شود. محتوای زیر تبلیغ در این حالت ممکن است جابهجا شود.
یک راهکار ساده، تعیین حداقل ارتفاع برای Container تبلیغ است:
.ad-container {
min-height: 250px;
}
مقدار واقعی باید بر اساس اندازه جایگاه تبلیغ و رفتار نسخه موبایل و دسکتاپ تعیین شود.
همین منطق را میتوان برای iframeها و برخی Embedها نیز به کار برد. هدف این است که مرورگر پیش از دریافت محتوای خارجی، فضای موردنیاز آن را بداند.
در یک درخواست عادی وردپرس، اجرای PHP، Queryهای دیتابیس و تولید HTML میتواند بخشی از زمان پاسخ را مصرف کند.
Page Cache با نگهداری نسخه آماده HTML میتواند نیاز به اجرای دوباره بخشی از این پردازشها را کاهش دهد.
این روش برای صفحات محتوایی که بین کاربران مختلف یکسان هستند بسیار کاربردی است.
اما همه صفحات نباید بدون استثنا Cache شوند.
صفحات زیر معمولاً به سیاست Cache متفاوتی نیاز دارند:
بنابراین استفاده از Cache تنها به فعال کردن یک افزونه محدود نمیشود. Exclusionها و رفتار صفحات پویا نیز باید بررسی شوند.
Object Cache با Page Cache یکسان نیست.
Page Cache معمولاً نسخه HTML تولیدشده را نگهداری میکند، در حالی که Object Cache برای نگهداری دادهها و نتایج عملیات پرتکرار در سطح Backend استفاده میشود.
Redis یکی از راهکارهای رایج برای Object Cache است.
این فناوری میتواند در سایتهایی با دیتابیس بزرگ، WooCommerce، Queryهای پرتعداد یا بار همزمان بالا مفید باشد.
اما فعال کردن Redis بهتنهایی تضمین نمیکند LCP، INP یا CLS بهتر شوند.
اگر مشکل اصلی سایت تصویر LCP یا JavaScript سمت مرورگر باشد، بهینهسازی Object Cache راهکار اصلی نخواهد بود.
بنابراین ابتدا باید مشخص شود گلوگاه در Backend قرار دارد یا Front-End.
TTFB بالا همیشه به معنی ضعیف بودن هاست نیست.
یک افزونه یا قالب میتواند باعث اجرای Queryهای متعدد یا سنگین شود و زمان تولید HTML را افزایش دهد.
ابزارهایی مانند Query Monitor برای بررسی Queryهای دیتابیس، Hookها، درخواستهای HTTP و برخی منابع مصرفشده توسط وردپرس کاربرد دارند.
هنگام بررسی دیتابیس بهتر است این موارد را زیر نظر داشته باشید:
اگر مشخص شود یک افزونه در هر درخواست تعداد زیادی Query ایجاد میکند، اصلاح همان بخش میتواند تأثیر بیشتری از تغییرات عمومی داشته باشد.
WP-Cron وظیفه اجرای بسیاری از کارهای زمانبندیشده وردپرس را بر عهده دارد.
در برخی سایتهای پرترافیک، انتقال اجرای Cron به Cron سیستمعامل یا WP-CLI میتواند کنترل بیشتری روی اجرای وظایف زمانبندیشده ایجاد کند.
برای غیرفعال کردن اجرای داخلی WP-Cron میتوان از این تنظیم در wp-config.php استفاده کرد:
define('DISABLE_WP_CRON', true);
اما این خط بهتنهایی کافی نیست.
پس از غیرفعال کردن WP-Cron داخلی باید یک روش جایگزین برای اجرای wp-cron.php یا وظایف زمانبندیشده وردپرس تنظیم شود. در غیر این صورت ممکن است بعضی Cron Jobها اجرا نشوند.
WordPress 6.9 نیز نحوه Spawn شدن WP-Cron را تغییر داده و اجرای آن را از init به shutdown منتقل کرده است. هدف این تغییر کاهش اثر Spawn شدن Cron روی TTFB بوده است. مستندات رسمی وردپرس در تستهای خود امکان کاهش حدود یک ثانیهای این تأخیر را در برخی شرایط گزارش کردهاند.
بنابراین غیرفعال کردن WP-Cron نباید صرفاً بر اساس یک توصیه عمومی انجام شود. ابتدا وضعیت Cron و نیازهای واقعی سایت را بررسی کنید.
وردپرس برای نوشتهها و برگهها Revision ذخیره میکند تا امکان بازگردانی نسخههای قبلی وجود داشته باشد.
در سایتهایی که محتوا مرتب ویرایش میشود، تعداد Revisionها میتواند افزایش پیدا کند.
برای محدود کردن تعداد Revisionهای نگهداریشده میتوان از تنظیم زیر استفاده کرد:
define('WP_POST_REVISIONS', 10);
این تنظیم تعداد Revisionهای نگهداریشده برای هر نوشته یا برگه را محدود میکند.
نکته مهم این است که WP_POST_REVISIONS بهتنهایی Revisionهای قدیمی موجود در دیتابیس را پاک نمیکند.
بنابراین باید دو موضوع را از هم جدا کرد:
محدود کردن Revisionهای جدید
با تنظیم WP_POST_REVISIONS انجام میشود.
پاکسازی Revisionهای قبلی
نیازمند یک عملیات جداگانه است.
قبل از هرگونه پاکسازی مستقیم دیتابیس، تهیه Backup کامل ضروری است.
همچنین Revision یکی از معیارهای Core Web Vitals نیست و مدیریت آن نباید بهعنوان یک راهکار قطعی برای بهبود LCP، INP یا CLS معرفی شود. هدف اصلی این کار مدیریت Backend و جلوگیری از رشد غیرضروری دادههای Revision است.
بهینهسازی سایت بدون اندازهگیری میتواند باعث شود زمان زیادی صرف تغییراتی شود که تأثیر واقعی ندارند.
ابتدا باید یک Baseline از عملکرد سایت ایجاد کنید.
PageSpeed Insights و Lighthouse برای تست آزمایشگاهی مفید هستند، اما دادههای واقعی کاربران اهمیت زیادی دارند. شرایط دستگاه، شبکه و تعامل کاربر میتواند باعث تفاوت بین نتایج آزمایشگاهی و دادههای میدانی شود.
موارد زیر را بررسی کنید:
اگر عنصر LCP تصویر است، حجم، ابعاد، فرمت و اولویت دریافت آن را بررسی کنید.
تمرکز را روی موارد زیر قرار دهید:
این موارد را بررسی کنید:
بیشتر سراغ Backend بروید:
امتیاز Lighthouse یک نتیجه آزمایشگاهی است و نباید با تجربه واقعی کاربران یکی در نظر گرفته شود.
هدف اصلی باید بهبود تجربه کاربر و قرار گرفتن Core Web Vitals در محدوده مناسب باشد، نه رسیدن اجباری به یک عدد مشخص.
استفاده همزمان از چند سیستم Cache یا چند ابزار برای Minify، Combine و Lazy Load میتواند باعث تداخل شود.
تصویر LCP یا تصاویر مهم بالای صفحه نباید صرفاً به دلیل اینکه تصویر هستند Lazy Load شوند.
حذف یک فایل بدون شناخت وابستگیهای آن ممکن است باعث خراب شدن ظاهر یا عملکرد سایت شود.
همه Scriptها غیرضروری نیستند. برخی قابلیتهای اصلی سایت برای عملکرد صحیح به JavaScript فوری نیاز دارند.
حذف Revision، Transient یا دادههای افزونهها بدون شناخت ساختار دیتابیس میتواند باعث از دست رفتن اطلاعات یا ایجاد خطا شود.
برای بهینهسازی یک سایت وردپرسی بهتر است مراحل زیر را به ترتیب انجام دهید.
مقادیر LCP، INP، CLS و TTFB را ثبت کنید.
مشخص کنید مشکل اصلی در Front-End، Backend یا هر دو قرار دارد.
عنصر LCP و مسیر دریافت آن را بررسی کنید.
CSS اضافی، Scriptهای غیرضروری، Long Taskها و منابع Third-Party را شناسایی کنید.
ابعاد تصاویر، تبلیغات، iframeها و سایر عناصر پویا را کنترل کنید.
در صورت بالا بودن TTFB، سرور، PHP، Cache و Queryهای دیتابیس را بررسی کنید.
چندین تغییر نامرتبط را همزمان انجام ندهید. تغییرات را مرحلهای اعمال کنید.
پس از هر مرحله، عملکرد سایت را دوباره بررسی و نتیجه را با Baseline مقایسه کنید.
این روش مشخص میکند کدام تغییر واقعاً مؤثر بوده و از ایجاد تنظیمات اضافی جلوگیری میکند.
بهینهسازی سرعت وردپرس یک نسخه ثابت برای همه سایتها ندارد. LCP، INP و CLS مشکلات متفاوتی را بررسی میکنند و هرکدام به روش تشخیص و بهینهسازی متفاوتی نیاز دارند.
اگر LCP ضعیف است، مسیر نمایش محتوای اصلی و منابع اولیه را بررسی کنید. اگر INP مشکل دارد، JavaScript، Long Taskها و Main Thread اهمیت بیشتری پیدا میکنند. در صورت بالا بودن CLS نیز باید تصاویر، تبلیغات، iframeها، فونتها و عناصر پویا بررسی شوند.
در سمت سرور نیز Page Cache، Object Cache، PHP، Queryهای دیتابیس و WP-Cron باید بر اساس داده واقعی سایت ارزیابی شوند.
مهمترین اصل این است که ابتدا گلوگاه واقعی را پیدا کنید، سپس همان بخش را بهینه کنید و بعد نتیجه را دوباره اندازه بگیرید. این روش از نصب مجموعهای از افزونههای بهینهسازی و تغییر تنظیمات بدون شناخت اثر واقعی آنها قابل اتکاتر است.
WordPress 6.9 نیز بخش قابل توجهی از بهینهسازی عملکرد را به Core منتقل کرده است. بهبود بارگذاری استایلهای Block، کاهش منابع غیرضروری، مدیریت بهتر Scriptها و تغییر نحوه اجرای WP-Cron نمونههایی از این مسیر هستند. بنابراین در نسخههای جدید وردپرس، پیش از اعمال بهینهسازیهای دستی باید بررسی شود که Core، قالب یا افزونه مورد استفاده چه بخشی از کار را از قبل انجام میدهد.