آموزش بکاپگیری از وردپرس؛ روش دستی، افزونه و بازگردانی
هک شدن سایت، یک بهروزرسانی ناموفق، حذف اشتباهی یک پوشه یا مشکل سرور هاست؛ هر کدام از اینها میتواند در …
اگر سایت وردپرسی شما در PageSpeed Insights نمرهٔ نارنجی یا قرمز میگیرد، تنها نیستید. خیلی از سایتها با یک قالب سنگین، چند افزونهٔ اضافه و تصاویر بهینهنشده به همینجا میرسند. خبر خوب این است که بیشتر مشکلات Core Web Vitals در وردپرس دلیلهای تکراری و راهحلهای شناختهشده دارند و برای رفعشان لازم نیست برنامهنویس باشید.
در این راهنما اول میبینیم سه شاخص LCP، INP و CLS دقیقاً چه چیزی را میسنجند و چطور درست اندازهشان بگیریم. بعد برای هر کدام کارهایی را مرور میکنیم که در وردپرس بیشترین اثر را دارند. اگر دنبال فهرست افزونههای سرعت هستید، افزونههای ضروری وردپرس برای افزایش سرعت را هم کنار این مقاله باز کنید؛ اینجا تمرکز روی اندازهگیری و رفع هر سه شاخص است.
آخرین بهروزرسانی: ۱۱ آبان ۱۴۰۵ — آستانهها و تعریفها از مستندات رسمی web.dev و Google Search Central، قابلیتهای هستهٔ وردپرس از اطلاعیههای رسمی make.wordpress.org و آمار نصب افزونهها از مخزن وردپرس (نسخهٔ فعلی وردپرس: 7.1.4) برداشته شدهاند.
⚡ پاسخ کوتاه
Core Web Vitals سه شاخص گوگل برای تجربهٔ کاربری است: LCP (سرعت نمایش بزرگترین محتوا، خوب: حداکثر ۲٫۵ ثانیه)، INP (سرعت واکنش به کلیک و لمس، خوب: حداکثر ۲۰۰ میلیثانیه) و CLS (پایداری چیدمان، خوب: حداکثر ۰٫۱). در وردپرس بیشترین اثر را این کارها دارند: هاست و کش صفحه، فشردهسازی و ابعاد درست تصاویر، حذف افزونهها و اسکریپتهای اضافه و رزرو کردن جای تبلیغ، بنر و فونت. نتیجه را با دادهٔ میدانی PageSpeed Insights و گزارش Core Web Vitals سرچ کنسول بسنجید، نه فقط با عدد نمرهٔ آزمایشگاهی.
📑 فهرست مطالب
Core Web Vitals مجموعهای از سه شاخص است که تجربهٔ واقعی کاربران را در سه جنبه میسنجد: بارگذاری، واکنشگرایی و پایداری ظاهری صفحه. گوگل در مستندات Search Central صریحاً توصیه میکند صاحبان سایت به Core Web Vitals خوب برسند و میگوید این شاخصها در کنار دیگر جنبههای تجربهٔ صفحه با چیزی همراستا هستند که سیستمهای اصلی رتبهبندیاش به آن پاداش میدهند.
البته باید واقعبین بود: سرعت جای محتوای مفید را نمیگیرد. صفحهای که جواب بهتری به جستوجوی کاربر میدهد، معمولاً حتی با نمرهٔ متوسط هم بالاتر میآید. اما وقتی چند صفحه از نظر محتوا نزدیک به هم باشند، تجربهٔ کاربری بهتر میتواند فرق ایجاد کند و مهمتر از آن، کاربری که منتظر بارگذاری نماند، اصلاً به محتوای شما نمیرسد.
| شاخص | چه چیزی را میسنجد | خوب | نیاز به بهبود | ضعیف |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | زمان نمایش بزرگترین عکس یا بلوک متنی در صفحهٔ اول | تا ۲٫۵ ثانیه | ۲٫۵ تا ۴ ثانیه | بیش از ۴ ثانیه |
| INP (Interaction to Next Paint) | تأخیر بین کلیک، لمس یا تایپ و بهروز شدن صفحه | تا ۲۰۰ میلیثانیه | ۲۰۰ تا ۵۰۰ میلیثانیه | بیش از ۵۰۰ میلیثانیه |
| CLS (Cumulative Layout Shift) | میزان جابهجایی ناگهانی عناصر صفحه | تا ۰٫۱ | ۰٫۱ تا ۰٫۲۵ | بیش از ۰٫۲۵ |
این آستانهها روی صدک ۷۵ام بازدیدها سنجیده میشوند؛ یعنی دستکم ۷۵ درصد بازدیدهای واقعی باید در محدودهٔ «خوب» باشند و موبایل و دسکتاپ هم جدا ارزیابی میشوند. صفحه فقط وقتی قبول میشود که هر سه شاخص خوب باشند. یک نکتهٔ تاریخی هم: از ۱۲ مارس ۲۰۲۴ شاخص INP جای FID را گرفت، پس اگر در آموزشهای قدیمی اسم FID را دیدید، آن بخش دیگر بهروز نیست.

بزرگترین اشتباه در بهینهسازی سرعت این است که فقط به عدد ۰ تا ۱۰۰ بالای PageSpeed Insights نگاه کنیم. این ابزار دو نوع داده نشان میدهد که باید فرقشان را بدانید:
اگر سایت کمبازدید است، ممکن است بخش دادهٔ میدانی خالی بماند، چون CrUX برای صفحه یا دامنه دادهٔ کافی ندارد. در این حالت به دادهٔ آزمایشگاهی تکیه کنید و چند بار تست بگیرید. برای دید کلی سایت، گزارش Core Web Vitals در سرچ کنسول گوگل را باز کنید؛ این گزارش صفحههای مشابه را گروهبندی میکند و نشان میدهد کدام گروه در کدام شاخص مشکل دارد. بعد از رفع مشکل، دکمهٔ «اعتبارسنجی اصلاح» را بزنید تا گوگل دوباره بررسی کند.
همیشه نسخهٔ موبایل را اول بررسی کنید. تست موبایل PageSpeed با پردازندهٔ کندتر و اینترنت محدودتر شبیهسازی میشود و تقریباً همیشه از دسکتاپ پایینتر است. اگر موبایل خوب شد، دسکتاپ معمولاً خودش درست میشود.
در بیشتر سایتهای وردپرسی، عنصر LCP تصویر شاخص نوشته، اسلایدر صفحهٔ اصلی یا یک تیتر بزرگ است. در PageSpeed Insights بخش «Largest Contentful Paint element» دقیقاً نشان میدهد عنصر LCP کدام است. راهنمای web.dev زمان LCP را به چهار بخش تقسیم میکند: زمان پاسخ سرور (TTFB)، تأخیر شروع دانلود منبع، مدت دانلود و تأخیر رندر. هر بخش راهحل خودش را دارد:
اگر TTFB بالاست، مشکل قبل از رسیدن به مرورگر است. هاست ضعیف یا شلوغ، نسخهٔ قدیمی PHP و نبود کش صفحه رایجترین دلیلها هستند. اول از کش صفحه شروع کنید: اگر سرورتان LiteSpeed است، افزونهٔ LiteSpeed Cache (بیش از ۷ میلیون نصب فعال) بهترین انتخاب است و روی سرورهای دیگر WP Super Cache یا W3 Total Cache کار را راه میاندازند. اگر بعد از کش هنوز سرور کند بود، وقت بازبینی هاست است؛ اشتباهات رایج در انتخاب هاست را ببینید. استفاده از CDN هم فاصلهٔ فیزیکی تا کاربر را کم میکند.
fetchpriority="high" را به تصویری که احتمالاً LCP است اضافه میکند و آن را از lazy load کنار میگذارد، اما بعضی قالبها و افزونههای بهینهسازی این رفتار را خراب میکنند. در کد صفحه چک کنید.<img src="hero.webp" width="1200" height="675"
fetchpriority="high" alt="...">
فایلهای CSS و جاوااسکریپتی که در head صفحه بارگذاری میشوند، رندر را متوقف میکنند. افزونههایی مثل Autoptimize یا WP-Optimize میتوانند CSS را فشرده و جاوااسکریپت را با defer بارگذاری کنند. برای فونتهای فارسی مثل وزیرمتن، فایل فونت را روی هاست خودتان بگذارید، فقط وزنهای لازم را بارگذاری کنید و از font-display: swap استفاده کنید تا متن قبل از دانلود کامل فونت دیده شود.

INP میسنجد از لحظهای که کاربر کلیک میکند، صفحه را لمس میکند یا کلیدی را میزند تا وقتی که تغییر روی صفحه دیده شود، چقدر طول میکشد. این شاخص در طول کل بازدید جمعآوری میشود و تقریباً کندترین تعامل را گزارش میکند. مقصر اصلی تقریباً همیشه جاوااسکریپت زیاد است که رشتهٔ اصلی مرورگر را مشغول نگه میدارد.
یک افزونهٔ رسمی هم از تیم عملکرد وردپرس هست به نام Performance Lab که قابلیتهای آزمایشی بهینهسازی را پیش از ورود به هستهٔ وردپرس در اختیارتان میگذارد. همچنین وردپرس از نسخهٔ ۶٫۸ «بارگذاری پیشدستانه» (Speculative Loading) را بهطور پیشفرض فعال کرده است تا صفحهٔ بعدی وقتی کاربر شروع به کلیک روی لینک میکند، از قبل بارگذاری شود. این قابلیت برای کاربران واردشده و سایتهای بدون پیوند یکتای خوانا غیرفعال است. اگر از افزونههای هوش مصنوعی و چتبات استفاده میکنید، اسکریپتشان را هم بسنجید؛ فهرست افزونههای هوش مصنوعی وردپرس را با همین نگاه انتخاب کنید.
حتماً برایتان پیش آمده که میخواهید روی لینکی بزنید و درست همان لحظه یک بنر بالای صفحه ظاهر میشود و دکمهٔ اشتباه را میزنید. CLS همین تجربهٔ آزاردهنده را میسنجد. دلیلهای رایجش در وردپرس اینهاست:
| دلیل | راهحل |
|---|---|
| تصویر و ویدیو بدون width و height | ابعاد را در کد بگذارید یا با CSS نسبت تصویر (aspect-ratio) تعیین کنید؛ وردپرس برای تصاویر کتابخانهٔ رسانه این کار را خودکار انجام میدهد |
| تبلیغ، بنر یا اعلان کوکی که دیر بارگذاری میشود | جای ثابتی با min-height برایش رزرو کنید یا آن را بهصورت شناور روی صفحه نمایش دهید |
| عوض شدن فونت بعد از بارگذاری | فونت را preload کنید و فونت جایگزین با اندازهٔ نزدیک انتخاب کنید |
| محتوایی که با جاوااسکریپت بالای محتوای موجود اضافه میشود | محتوای جدید را پایینتر اضافه کنید یا فقط بعد از تعامل کاربر نمایش دهید |
برای پیدا کردن عنصر مقصر، در گزارش PageSpeed Insights بخش «Avoid large layout shifts» را باز کنید. ابزار Performance در DevTools کروم هم جابهجاییها را با رنگ روی صفحه نشان میدهد.

اگر نمیدانید از کجا شروع کنید، این ترتیب برای بیشتر سایتهای وردپرسی بیشترین نتیجه را با کمترین ریسک میدهد:
Core Web Vitals فقط یک بخش از سئوی فنی است. برای تصویر کاملتر، راهنمای سئوی فنی را بخوانید. اگر فروشگاه ووکامرسی دارید، این کارها را روی صفحههای محصول و سبد خرید هم انجام دهید؛ آموزش نصب و راهاندازی ووکامرس نقطهٔ شروع خوبی است. و اگر ترجیح میدهید این کارها را به متخصص بسپارید، تیم رادینو در طراحی و توسعهٔ وبسایت و خدمات سئو کنار شماست.
گوگل آن را بخشی از تجربهٔ صفحه میداند که سیستمهای رتبهبندی به آن پاداش میدهند، اما محتوای مرتبط و مفید همچنان مهمتر است. سرعت را برای کاربر بهتر کنید، نه فقط برای نمره.
تست موبایل با دستگاه کندتر و اینترنت محدودتر شبیهسازی میشود، پس همان صفحه زمان بیشتری برای بارگذاری و اجرای جاوااسکریپت لازم دارد.
FID فقط تأخیر اولین تعامل را میسنجید، اما INP تقریباً کندترین تعامل در کل بازدید را گزارش میکند و تا بهروز شدن صفحه را هم حساب میکند. از مارس ۲۰۲۴ INP جایگزین FID شده است.
به سرورتان بستگی دارد. روی سرور LiteSpeed افزونهٔ LiteSpeed Cache، و روی سرورهای دیگر WP Super Cache یا W3 Total Cache انتخابهای رایج و رایگان هستند. فقط یک افزونهٔ کش فعال داشته باشید.
دادهٔ میدانی تجربهٔ کاربران واقعی کروم در ۲۸ روز گذشته است و مبنای ارزیابی گوگل است؛ دادهٔ آزمایشگاهی یک تست شبیهسازیشده است که برای عیبیابی به کار میآید.
همه منابع در تاریخ ۱۱ آبان ۱۴۰۵ بررسی شدهاند.
نظرات 0
برای ارسال نظر وارد حساب کاربری شوید.
هنوز نظری ثبت نشده؛ اولین نفر باشید.