خطای Document Request Latency زمانی در گزارش پیچ اسپید گوگل ظاهر میشود که زمان زیادی برای دریافت فایل HTML از سرور سایت بیش از حد نرمال باشد. یعنی زمانیکه یک کاربر وارد سایت میشود، مرورگرش باید فایل HTML اصلی را از سرور بگیرد. اگر دریافت این فایل طولانی شود، گوگل این تأخیر را ثبت و گزارش میدهد که سایت در همان لحظه ورود، کند عمل کردهاست.
در واقع، این مشکل روی کل عملکرد سایت تأثیر میگذارد، چون سایت نمیتواند بارگذاری بقیه منابع مثل عکس، CSS یا جاوااسکریپت را شروع کند تا وقتی که HTML اصلی را کامل دریافت نکرده باشد. بنابراین:
سرور کند یا پرمشغله اگر هاست یا سرور سایت کند باشد یا چند سایت دیگر به طور همزمان از آن استفاده کنند، ممکن است پاسخگویی به کاربر با تأخیر انجام شود.
فشار زیاد به سایت از سمت پلاگینها یا کدهای سنگین مخصوصاً در وردپرس، اگر افزونهها کوئریهای زیاد اجرا کنند یا قالب طراحیشده بهینه نباشد، سرور برای ساختن HTML زمان زیادی صرف میکند.
نبود کش سمت سرور اگر سایتت هر بار که کسی وارد میشود، از اول HTML را بسازد، این فرآیند زمانبر است. در صورتی که اگر یک نسخه آمادهی کششده داشته باشد، همان را سریع تحویل میدهد.
نبود CDN یا تنظیمات اشتباه آن اگر کاربر از منطقهای دورتر از سرور به سایت متصل شود و سایت CDN نداشته باشد، مسیر دریافت فایل HTML زیاد میشود.
ریدایرکت اضافی مثلاً وقتی کاربر به macanads.com میرود و سایت اول او را به www.macanads.com و بعد به https://macanads.com منتقل میکند. این رفتوبرگشتها باعث تأخیر در تحویل فایل اصلی HTML میشود.
پایگاهداده سنگین و کند در سایتهای داینامیک، اگر دیتابیس بهینه نباشد (مثلاً زیاد پر شده باشد یا جداول به هم ریخته باشند)، بازیابی اطلاعات برای ساخت فایل HTML طول میکشد.
راهحلهای کامل و کاربردی برای برطرف کردن این خطا
میزبانی سایت را ارتقا یا تعویض کنید اگر از هاست اشتراکی استفاده میکنید، حتماً به سرور مجازی (VPS) یا هاستی با منابع بیشتر منتقل شوید. شرکتهایی که هاست پرسرعت و Lite Speed ارائه میکنند، گزینهی خوبی هستند.
از افزونه کش استفاده کنید (برای وردپرس) افزونههایی مثل WP Rocket، LiteSpeed Cache یا W3 Total Cache، نسخه آمادهای از HTML صفحات را ذخیره میکنند و خیلی سریعتر به کاربران تحویل میدهند.
ریدایرکتهای زنجیرهای را حذف کنید تنظیم دامنه را طوری انجام بدهید که کاربر مستقیماً وارد نسخه نهایی آدرس بشود مثلاً همیشه مستقیماً وارد www.https://macanads.comشود بدون اینکه مراحل اضافی طی شود.
از CDN استفاده کنید (مثل Cloudflare) با فعالسازی CDN، نسخهای از فایلهای HTML روی سرورهای نزدیک به کاربر ذخیره میشود و خیلی سریع بارگذاری میشود.
قالب و افزونههای سنگین را حذف یا جایگزین کنید قالبهایی که تعداد زیادی فایل CSS، فونت یا اسکریپت دارند، و افزونههایی که کوئریهای زیاد روی دیتابیس اجرا میکنند را بررسی کنید و تا جای ممکن جایگزین یا حذف کنید.
دیتابیس سایت را بهینهسازی کنید با ابزارهایی مثل WP-Optimize میتوانید دیتابیس را تمیز، دادههای موقت را حذف و سرعت پاسخدهی سرور را بالا ببرید.
TTFB سایت را بررسی کنید اگر TTFB زمان تا دریافت اولین بایت از سرور زیاد باشد، نشانهی اصلی همین مشکل است. از سایتهایی مثل GTmetrix یا WebPageTest برای بررسی عدد دقیق استفاده کنید.
خطای Font Display
وقتی سایت از فونتهایی استفاده میکند که باید از سرور دانلود شوند مثل ایرانیکان، وزیر، یا فونتهای گوگل، مرورگر برای نمایش متنها باید اول آن فونت را بگیرد. تا زمانی که فونت بهطور کامل دریافت نشده، متنها نمایش داده نمیشوند صفحه سفید میماند.
این یعنی کاربر چند ثانیه اول ورود به سایت، فقط یک صفحه سفید یا بدون متن میبیند. این اتفاق باعث تأخیر در نمایش محتوا و نارضایتی کاربر میشود.
گوگل وقتی متوجه این وضعیت شود، در گزارش Page Speed خطایی با عنوان Font Display نشان میدهد تا بگوید که باید به مرورگر اجازه دهید اول متن را با یک فونت معمولی نشان دهد، بعد که فونت اصلی رسید، آن را جایگزین کند. بنابراین:
این خطا به این دلیل نشان داده میشود که در فایل CSS سایت، برای فونتهایی که از بیرون بارگذاری میشوند (چه از هاست خودت و چه از سایتهایی مثل Google Fonts یا FontYar، ویژگی font-display تنظیم نشده است.
وقتی این ویژگی تنظیم نشده باشد، مرورگر نمیداند چه رفتاری باید داشته باشد: باید متن را پنهان کند تا فونت بیاید؟ یا متن را با یک فونت جایگزین نشان بدهد و بعد فونت اصلی را اعمال کند؟
وقتی این ویژگی مشخص نیست، مرورگر معمولاً متن را مخفی نگه میدارد. همین باعث افت نمره عملکرد و تجربه کاربری میشود، و گوگل این موضوع را بهعنوان یک مشکل گزارش میکند.
راهحلهای کامل و کاربردی برای برطرف کردن این خطا
باید به همه فونتهایی که در سایت استفاده شدهاند، ویژگی زیر را اضافه کنی:
font-display: swap;
این دستور باعث میشود متنها بدون صبر برای فونت فوراً با یک فونت موقت نمایش داده شوند، و بعد که فونت اصلی دانلود شد، جایگزین شود. با این کار:
متنها سریعتر دیده میشوند
صفحه زودتر بارگذاری بهنظر میرسد
نمره Page Speed بهتر میشود
خطای Render-Blocking Resources
این خطا زمانی ظاهر میشود که فایلهایی مثل CSS یا جاوااسکریپت در ابتدای صفحه قرار دارند و باعث میشوند مرورگر نتواند خیلی سریع نمایش صفحه را شروع کند.
وقتی کاربر وارد سایت میشود، مرورگر باید کد HTML را بخواند، ولی وقتی به فایلهای CSS یا JavaScript در هارد میرسد، متوقف میشود تا آنها را دانلود کند. در این مدت، نمایش render صفحه متوقف میشود و چیزی به کاربر نشان داده نمیشود.
این فایلها به مسدودکنندهی رندر معروف هستند. گوگل میخواهد این فایلها در همان لحظه اول باعث تأخیر در ساخت صفحه نشوند.
به همین دلیل، وقتی فایلهای CSS یا JS مستقیماً در بالا یا وسط HTML قرار دارند و به شکل بهینهسازی نشده بارگذاری میشوند، این خطا را Page Speed نشان میدهد. بنابراین:
فایلهای CSS که در <head> قرار دارند (مثل style.css)
فایلهای JavaScript بدون async یا defer
فونتها یا فایلهایی که در ابتدا بارگذاری میشوند و قبل از نمایش صفحه باید حتماً دانلود شوند
راهحلهای کامل و کاربردی برای برطرف کردن این خطا
برای JavaScript → استفاده از async یا defer این باعث متوقف شدن رندر میشود.
defer: فایل جاوااسکریپت بعد از بارگذاری کامل HTML اجرا میشود (مناسبتر برای اکثر سایتها)
async: فایل جاوااسکریپت همزمان با HTML دانلود میشود و بلافاصله اجرا میشود (اگر ترتیب اجرا مهم نباشد)
برای CSS → استفاده از بارگذاری تأخیری (load CSS asynchronously)
برای فایلهای CSS، نمیتونی از async یا defer استفاده کنی. باید با روشهای خاص بارگذاری شود.
این روش باعث میشود فایل CSS هم بارگذاری شود ولی جلوی نمایش صفحه را نگیرد.
برای فایلهای غیرضروری → لود آنها را به تأخیر بنداز
مثلاً اگر اسلایدر، ویدیو، نقشه گوگل یا فونت خاصی داری که در لحظه اول مهم نیستند، اینها را با جاوااسکریپت بعد از بارگذاری صفحه اجرا کن.
ادغام فایلها (Combine CSS & JS)
اگر سایت چند فایل CSS و JS دارد، بهتر است همه آنها در یک فایل ترکیب شوند تا تعداد درخواستها کاهش پیدا کند و بارگذاری سریعتر انجام شود.
استفاده از Critical CSS
در این روش، فقط بخش CSS مربوط به محتوای قابلمشاهده در لحظه اول (مثلاً هدر و بنر) بهصورت مستقیم در داخل HTML گذاشته میشود. باقی CSSها با تأخیر بارگذاری میشوند.
سپس فایل اصلی CSS سایت با روش async یا preload بارگذاری شود.
استفاده از افزونه برای وردپرس
اگر سایتت وردپرسه و نمیتونی دستی کدها رو ویرایش کنی، از افزونههایی مثل:
WP Rocket
Autoptimize
LiteSpeed Cache
Asset CleanUp
استفاده کن. این افزونهها به صورت خودکار جاوااسکریپت و CSS رو بهینه میکنن، defer یا async میزنن و رندر بلاکینگ رو از بین میبرن.
این خطا وقتی ظاهر میشود که کدهای جاوااسکریپت یا CSS باعث بازسازی و چینش مجدد کل صفحه یا بخش بزرگی از آن بشود، آن هم بهصورت مداوم و پشت سر هم.
مرورگر برای نمایش صفحه، یکبار موقع بارگذاری همه عناصر را محاسبه و مرتب میکند. ولی اگر بعد از آن دوباره و دوباره مجبور شود محاسبهها را تکرار کند، مخصوصاً وقتی وسط اجرای اسکریپتها یا انیمیشنها این اتفاق بیفتد، صفحه دچار کندی و لگ میشود.
به این وضعیت میگویند چینش اجباری مکرر Forced Reflow. این کار باعث میشود صفحه دیرتر بارگیری شود، اسکرول گیر کند، و تجربه کاربری افت کند. گوگل این رفتار را یک اشتباه عملکردی جدی میداند. بنابراین:
کدی که مرتباً چیزی را در DOM تغییر میدهد و بلافاصله بعدش چیزی را از DOM میخواند
این کد باعث میشود مرورگر بلافاصله ساختار صفحه را دوباره محاسبه کند، که باعث تأخیر و لگ میشود. این کار اگر در حلقه، انیمیشن یا scroll event باشد، صدها بار پشت سر هم انجام میشود و مشکل شدیدتر میشود.
کدهای انیمیشنی با تغییر مستقیم استایل در لحظه
انیمیشنهای CSS یا JS که باعث تغییر موقعیت یا اندازه عناصر زیاد در صفحه میشوند
خواندن و نوشتن متوالی روی DOM بدون دستهبندی
راهحلهای کامل و کاربردی برای برطرف کردن این خطا
1. جدا کردن خواندن و نوشتن (Batch DOM Read/Writes)
نباید بلافاصله بعد از تغییر در DOM (مثل تغییر اندازه یا موقعیت)، از DOM چیزی بخوانید. این باعث بازسازی کامل صفحه میشود.
اول همه اطلاعات را بخوانید، بعد همه تغییرات را بنویسید.
2. استفاده از requestAnimationFrame برای انیمیشنها
وقتی میخواهید در جاوااسکریپت انیمیشن اجرا کنید، بهجای setInterval یا حلقه مستقیم، از requestAnimationFrame استفاده کنید. این باعث میشود مرورگر در زمان مناسب تغییرات را اعمال کند و از چندبار محاسبه همزمان جلوگیری شود.
3. بهجای تغییر مستقیم style.left, style.top از transform استفاده کن
چون تغییر در ویژگیهایی مثل left یا top باعث محاسبه مجدد کل چیدمان میشود، اما transform فقط گرافیکی است و سریعتر اجرا میشود.
4. کاهش تعداد دفعات تغییر اندازه، موقعیت یا ویژگیهای نمایشی در عناصر داخل حلقه یا اسکرول
مثلاً اگر اسکرول صفحه باعث اجرای تابعی میشود که دهها تغییر در DOM میدهد، آن را بهجای مستقیم، بهصورت تأخیری یا با requestIdleCallback یا requestAnimationFrame انجام بدهید.
5. استفاده ابزار DevTools Chrome برای بررسی Reflow ها
در تب Performance در DevTools، رکورد بگیرید. نوارهای زرد یا قرمز به معنی Reflow و Layout هستند. اگر زیاد باشد، نشانه خطای Reflow است. میتوانید دقیقا ببینید کدام فایل جاوااسکریپت یا کدام تابع باعث آن شدهاست.
خطای LCP Request Discovery
خطای LCP Request Discovery در گزارش نمایش داده میشود مربوط به زمان کشف (discovery) منابعی است که برای بارگذاری المان Largest Contentful Paint (LCP) نیاز هستند. این خطا زمانی نشان داده میشود که مرورگر دیر متوجه شود که چه منبعی برای نمایش محتوای اصلی مانند تصویر یا متن بزرگ نیاز است، و به همین دلیل لود آن منبع با تأخیر انجام میشود. بنابراین:
وقتی شما در کد HTML خود مثلاً در <img>, <video>, یا حتی عناصر متن بزرگ در CSS از منابعی استفاده میکنید که:
بهصورت غیرمستقیم لود میشوند، مثلاً از طریق CSS یا JavaScript،
یا از طریق lazy load دستی یا با کتابخانههایی مثل jQuery اضافه میشوند،
یا در اسکرول اول نیستند و بعداً با جاوااسکریپت به صفحه تزریق میشوند،
مرورگر برای کشف این منابع باید منتظر بماند تا جاوااسکریپت اجرا شود یا CSS لود شود تا بفهمد چه چیزی باید لود شود. این تاخیر در شناسایی، باعث میشود که بارگذاری LCP بهجای شروع بلافاصله، چند صد میلیثانیه دیرتر شروع شود. این یعنی زمان بیشتری صرف میشود تا کاربر محتوی اصلی را ببیند و در نتیجه تجربه کاربری ضعیف میشود.
راهحلهای کامل و کاربردی برای برطرف کردن این خطا
منابع LCP را مستقیماً در HTML معرفی کنید:
مثلاً اگر تصویر LCP شماست، آن را در بالای HTML درون <img> قرار دهید و از بارگذاری با جاوااسکریپت پرهیز کنید.
از rel="preload" استفاده کنید:
اگر منبع LCP مثل تصویر یا فونت است، آن را در <head> با preload معرفی کنید تا مرورگر سریعتر آن را بشناسد و لود کند.
از بارگذاری تنبل یا Lazy Load با دقت استفاده کنید
اگر تصویری واقعاً در اولین اسکرول کاربر ظاهر میشود یعنی همان تصویر LCP است، نباید ویژگی lazy داشته باشد چون بارگذاری را عقب میاندازد. مطمئن شوید که loading="lazy" برای این تصویر استفاده نشده است.
کاهش عمق وابستگی منابع
اگر CSS یا JS زیادی قبل از کشف منبع LCP نیاز است، ساختار کد را بهگونهای بهینهسازی کنید که وابستگیها کمتر شود و فایل اصلی زودتر کشف شود.
در Page Speed و DevTools بررسی کنید که کدام منبع بهعنوان LCP شناخته شده:
در Chrome DevTools > تب Performance میتوانید دقیقاً ببینید چه چیزی LCP است و چطور بارگذاری میشود. با این تحلیل میتوان مسیر بارگذاری را بهینه کرد.
خطای Network Dependency Tree
خطای Network Dependency Tree در گزارش Page Speed زمانی نشان داده میشود که ترتیب و وابستگی بین منابعی که توسط مرورگر برای بارگذاری صفحه وب درخواست میشوند، بهینه و کارآمد نباشد. این خطا معمولاً زمانی ظاهر میشود که فایلهای ضروری مثل CSS، فونتها، اسکریپتها یا عکسها بهجای آنکه در زمان مناسب بارگذاری شوند، به تأخیر افتاده یا بارگذاری آنها به منابع دیگری وابسته شده باشد. در این شرایط مرورگر باید ابتدا منتظر بماند تا یک یا چند فایل دیگر لود شوند و سپس بتواند به فایل اصلی برسد. این فرآیند باعث زنجیرهای از تاخیرها میشود که سرعت بارگذاری صفحه را به شدت پایین میآورد و بر معیارهایی مانند LCP تاثیر منفی میگذارد. بنایراین:
زمانی که فایلهای مهم مثل CSS اصلی، فونتها یا جاوااسکریپتها در پایین صفحه یا با دستور async/defer اشتباه مدیریت شوند.
زمانی که فایلهای جاوااسکریپت یا CSS با حجم بالا و بدون فشردهسازی یا تقسیم بارگیری (code-splitting) استفاده شوند.
اگر منابع کلیدی (critical resources) از دامنههای دیگر فراخوانی شوند که سرعت پاسخدهی آنها پایین است. وقتی ترتیب بارگذاری منابع اشتباه باشد؛ مثلاً ابتدا فونت یا تصویر بارگذاری شود، ولی استایل یا جاوااسکریپت مربوط به نمایش آن با تأخیر بیاید.
راهحلهای کامل و کاربردی برای برطرف کردن این خطا
۱. شناسایی منابع بحرانی (Critical Resources): ابتدا باید فایلهایی را که برای نمایش بخش بالای صفحه (above the fold) ضروری هستند شناسایی کرده و آنها را در ابتدای کد HTML با بارگذاری سریع قرار دهید برای مثال با <link rel="preload"> یا قرار دادن CSS کلیدی داخل <style> در <head>.
۲. پیشبارگذاری منابع (Preload, Preconnect): از دستورات preload, prefetch, preconnect استفاده کنید تا مرورگر قبل از رسیدن به نقطه استفاده از آن فایلها، ارتباط را برقرار کند یا حتی آنها را بارگیری کند. این کار وابستگی بین منابع را کوتاهتر میکند.
۳. تقسیم منابع بزرگ (Code Splitting): اسکریپتها و استایلهای حجیم را با ابزارهایی مانند Webpack یا Parcel به تکههای کوچک تقسیم کنید تا فقط آنچه در ابتدا نیاز است بارگذاری شود.
فشردهسازی فایلها (Minify + Gzip/Brotli): منابع CSS و JS و فونتها را فشردهسازی کنید تا سریعتر بارگذاری شوند.
استفاده از CDNهای سریع و قابل اعتماد: اگر فایلها از منبع خارجی فراخوانی میشوند، مطمئن شوید که از CDNهای معتبر و پرسرعت مثل Cloudflare، Google Fonts یا jsDelivr استفاده میکنید.
درخت وابستگی را بهینه کنید (Flatten Dependency Tree): با بررسی ابزارهایی مثل DevTools یا Lighthouse ببینید کدام فایلها به چه منابعی وابستهاند و آن زنجیرهها را کوتاهتر یا مستقیمتر کنید.
تأخیر در بارگذاری منابع غیرضروری (Lazy Load / Defer / Async): برای منابعی که برای اولین بار دیدن صفحه حیاتی نیستند، از async, defer یا lazy load استفاده کنید.
خطای Use Efficient Cache Lifetimes
خطای Use Efficient Cache Lifetimes زمانی نمایش داده میشود که منابع استاتیک سایت مانند فایلهای CSS، JavaScript، تصاویر و فونتها بهدرستی برای کش شدن در مرورگر کاربر تنظیم نشدهاند یا زمان کش آنها کوتاه است. این خطا به این معناست که هر بار کاربر به سایت شما مراجعه میکند، مرورگرش مجبور است دوباره این منابع را از سرور دانلود کند؛ درحالیکه اگر این منابع مدتزمان بیشتری در حافظه کش باقی میماندند، سرعت بارگذاری صفحه بسیار بیشتر میشد. بنابراین:
وقتی هدرهای HTTP مربوط به کش (Cache-Control یا Expires) بهدرستی تعریف نشده باشند یا مدت زمان کش آنها خیلی کوتاه تعیین شده باشد مثلاً در حد چند دقیقه یا چند ساعت، این هشدار به شما داده میشود. Page Speed این منابع را بررسی میکند و اگر ببیند فایلی مثل لوگوی سایت، فایل استایل یا اسکریپتها هر بار باید مجدد بارگذاری شوند، آنها را در لیست منابع ناکارآمد قرار میدهد.
همچنین اگر برخی فایلها روی دامنههای دیگر مثلاً CDNها، یا فایلهای فونت از گوگل، یا تگهای آنالیتیکس قرار داشته باشند ولی تنظیمات کش آنها توسط ارائهدهنده اصلی محدود شده باشد، باز هم این خطا را دریافت میکنید؛ حتی اگر کنترل مستقیم روی آن منابع نداشته باشید.
راهحلهای کامل و کاربردی برای برطرف کردن این خطا
1. فعالسازی کش مرورگر برای منابع استاتیک
باید در تنظیمات سرور یا فایلهای پیکربندی سایت مثل .htaccess برای Apache یا تنظیمات Nginx مشخص کنید که کدام فایلها و برای چه مدتی در کش مرورگر باقی بمانند. برای منابعی که بهندرت تغییر میکنند مانند فونتها، لوگو، استایل اصلی، معمولاً یک سال توصیه میشود.
2. استفاده از Cache-Control Header
در سرورهایی که از Apache یا Nginx یا Node.js استفاده میکنند، میتوان هدر Cache-Control را اضافه کرد تا صرفا مدت زمان نگهداری فایلها در کش مشخص شود.
این فایل ها به مدت ۱ سال (۳۱۵۳۶۰۰۰ ثانیه) کش شود و تغییر نمیکند.
3. استفاده از versioning یا hashing در URL منابع
وقتی منابع استاتیک را برای مدت طولانی کش میکنید، اگر بخواهید آنها را در آینده تغییر دهید باید نسخه جدیدی از آنها را معرفی کنید تا مرورگر بداند فایل جدیدی وجود دارد.
4. استفاده از CDN با تنظیمات کش بهینه
اگر از CDN مانند Cloudflare، BunnyCDN یا Amazon CloudFront استفاده میکنید، باید در پنل آنها تنظیمات کش را انجام دهید. مثلاً برای فایلهای استاتیک حداقل ۶ ماه کش و استفاده از گزینههایی مثل Cache Everything یا Edge Cache TTL.
5. بررسی فایلهای سمت شخص ثالث
برای منابعی که از سرورهای خارجی میآیند مثلاً فونت گوگل یا اسکریپتهای آنالیتیکس، نمیتوان بهطور مستقیم تنظیمات کش را تغییر داد. در این حالت:
اگر ممکن بود فایل را دانلود کرده و بهصورت local در سایت خودتان میزبانی کنید.
یا با استفاده از CDN داخلی، فایل را از آنجا کش کنید.
یا در صورت غیرقابل تغییر بودن، نادیده بگیرید ولی توجه داشته باشید که Page Speed ممکن است همچنان آن را هشدار دهد.
خطای Use Legacy JavaScript
خطای Use Legacy JavaScript یکی از هشدارهایی است که در بخش Best Practices و Performance برای سایتهایی که از اسکریپتهای جاوااسکریپت قدیمی استفاده میکنند، نمایش میدهد. این اسکریپتها معمولاً با مرورگرهای قدیمی سازگار هستند ولی باعث کاهش عملکرد و افزایش زمان بارگذاری سایت در مرورگرهای جدید میشوند.
وقتی شما در سایتتان از فایلهای جاوااسکریپت استفاده میکنید که برای پشتیبانی از مرورگرهای خیلی قدیمی مثلاً اینترنت اکسپلورر 11 یا نسخههای اولیهی اندروید وبویو نوشته شدهاند، این کدها شامل ویژگیهایی هستند که یا دیگر در مرورگرهای جدید موردنیاز نیستند، یا به شیوهای قدیمی نوشته شدهاند که اجرای آنها زمانبر است. این باعث میشود مرورگر مجبور شود جاوااسکریپت بیشتری پردازش کند، که زمان تحلیل، ترجمه، و اجرا کد را افزایش میدهد.
به عنوان مثال، استفاده از کتابخانههایی که نسخههای ES5 یا حتی پایینتر را خروجی میدهند، درحالیکه بیشتر کاربران از مرورگرهایی استفاده میکنند که از ES6 و ویژگیهای مدرن پشتیبانی میکنند، موجب اتلاف منابع و زمان میشود. بنابراین:
افزایش زمان بارگذاری صفحه (خصوصاً روی موبایل).
کاهش امتیاز PageSpeed و Core Web Vitals مثل LCP و TTI.
مصرف بیشتر منابع پردازشی دستگاه کاربر.
در سایتهای شلوغ یا پیچیده، این مشکل میتواند منجر به پرشهای صفحه یا دیرتر رندر شدن محتوا شود.
راهحلهای کامل و کاربردی برای برطرف کردن این خطا
برای حل این مشکل باید از مدرنترین نسخهی جاوااسکریپت استفاده کرد که مرورگرهای امروزی پشتیبانی میکنند. راهکار:
استفاده از ماژولهای مدرن جاوااسکریپت
فایلهای جاوااسکریپت را طوری تنظیم کنید که در صورت پشتیبانی مرورگر، نسخهی مدرن لود شود.
استفاده از ابزارهایی مانند Babel بهصورت هدفمند اگر از Babel برای تبدیل کد ES6 به ES5 استفاده میکنید، مطمئن شوید که فقط برای مرورگرهایی که واقعاً به آن نیاز دارند این کار انجام میشود. میتوانید از preset هایی مثل @babel/preset-env با تنظیم targets استفاده کنید تا خروجی فقط برای مرورگرهایی که مخاطب شما هستند بهینه شود.
خارج کردن بستههای قدیمی یا جایگزینی با کتابخانههای مدرنتر برخی از کتابخانهها مثل jQuery در نسخههای قدیمیتر کدهای legacy زیادی دارند. اگر سایت شما به نسخههای مدرن مرورگر محدود است، میتوانید از نسخههای سبُکتر یا pure JavaScript استفاده کنید.
تحلیل مخاطبین سایت و تصمیمگیری آگاهانه اگر سایت شما کاربران خاصی دارد برای مثال فقط کاربران موبایل ایران در سال ۲۰۲۵، میتوانید با استفاده از آمار Google Analytics بفهمید که آیا کاربران شما به مرورگرهای قدیمی دسترسی دارند یا نه. اگر ندارند، دیگر نیازی به پشتیبانی از کدهای Legacy نیست.
بهروزرسانی وابستگیها و بستهها (Dependencies) ابزارها و کتابخانههای قدیمیتر مانند نسخههای قبلی React، Angular، Vue، Bootstrap را به آخرین نسخه ارتقا دهید. این نسخههای جدید معمولاً کدهایی بهینهتر و مدرنتر دارند.
خطای Layout Shift Culprits
خطای Layout Shift Culprits در گزارش Page Speed زمانی نمایش داده میشود که عناصری در صفحه باعث جابهجایی ناگهانی یا ناخواسته بخشهایی از محتوا در حین بارگذاری یا تعامل کاربر با صفحه شوند. به زبان ساده، این خطا زمانی رخ میدهد که وقتی کاربر در حال مشاهده یا خواندن چیزی است، بهطور ناگهانی یک بخش از صفحه جابهجا میشود و موقعیت آن تغییر میکند. این اتفاق معمولاً تجربه کاربری را بهشدت تحتتأثیر قرار میدهد و حتی میتواند باعث کلیکهای اشتباهی یا سردرگمی شود. بنابراین:
۱. بارگذاری تصاویر بدون مشخص کردن اندازه (width و height) اگر در کد HTML تصاویر بدون تعیین ابعاد مشخص بارگذاری شوند، مرورگر ابتدا فضای محدودی برای آنها در نظر میگیرد و پس از لود شدن تصویر، فضا را تغییر میدهد. این باعث حرکت ناگهانی سایر عناصر صفحه میشود.
۲. فونتهای سفارشی بدون روش لود کنترلشده هنگامیکه فونتها از منابع خارجی بارگذاری میشوند و نمایش متنها تا زمان بارگذاری کامل آنها به تأخیر میافتد، ممکن است جایگاه متنها در صفحه تغییر کند برای مثال از یک فونت پیشفرض به فونت سفارشی بزرگتر یا کوچکتر.
تبلیغات یا iframe های تأخیری و بدون جایگاه ثابت تبلیغات یا عناصر خارجی مانند ویدیوها که بدون در نظر گرفتن فضای مناسب، پس از لود شدن نمایش داده میشوند، منجر به جابهجایی سایر عناصر میشوند.
محتوای داینامیک (دکمهها یا بنرهای پاپآپ) اگر اسکریپتها یا اکشنهایی در صفحه باعث اضافه شدن محتوای جدید شوند، مثل بنرهای هشدار یا دکمههای شناور، و برای آنها از قبل فضا در نظر گرفته نشده باشد، باعث پرش سایر بخشها میشوند.
راهحلهای کامل و کاربردی برای برطرف کردن این خطا
۱. تعیین صریح اندازه برای تصاویر و ویدیوها در HTML در تگ <img> و <video> همیشه مقدار ابعاد را بهصورت دستی تعیین کنید. این کار باعث میشود مرورگر از ابتدا فضای کافی برای آن عکس یا فیلم رزرو کند و هنگام بارگذاری، تغییری در ساختار صفحه رخ ندهد.
۲. استفاده از ویژگی aspect-ratio در CSS برای عناصر دارای سایز متغیر برای عناصری که اندازه آنها ممکن است براساس محتوای داخلی تغییر کند، مقدار نسبت ابعاد را مشخص کنید تا مرورگر از ابتدا جای مناسب برای آنها در نظر بگیرد.
۳. بارگیری فونتها با استراتژیهای بهینه برای جلوگیری از جابهجایی متن ها، از خاصیتهای font-display: swap یا fallback در تعریف فونت استفاده کنید تا ابتدا فونت پیشفرض بارگذاری شود و پس از دریافت فونت اصلی، بدون پرش یا جابهجایی جایگزین شود.
۴. رزرو فضای مشخص برای تبلیغات و iframe ها اگر تبلیغات، iframe یا ویجتهای خارجی در سایت استفاده میکنید، قبل از لود آنها باید با استفاده از CSS یا جاوااسکریپت فضای مناسب برایشان رزرو شود. این کار باعث میشود در صورت لود تأخیری، تغییری در ساختار کلی صفحه ایجاد نشود.
۵. استفاده از Skeleton Screens یا Placeholder ها برای بخشهایی که بارگذاری آنها طول میکشد مثلاً عکسها یا کارتهای محصول، استفاده از قالب اولیهی اسکلت صفحه کمک میکند تا جای آن عنصر از ابتدا مشخص باشد.
۶. استفاده از ابزارهای مانیتورینگ و تحلیل CLS (Cumulative Layout Shift) از ابزارهایی مانند Lighthouse یا Web Vitals extension در مرورگر برای تحلیل دقیق نقاطی که بیشترین تغییر در چیدمان دارند استفاده کنید. این ابزارها بهصورت دقیق نشان میدهند کدام عناصر باعث پرش میشوند.