مشکلات سایت دیجی کالا؛ چه درس‌هایی برای شما دارد؟

بررسی مشکلات سایت دیجی کالا قرار نیست ثابت کنه یک فروشگاه بزرگ سایت ضعیفی داره. هدف اینه که با چند نمونه ثبت‌شده از نسخه‌های قدیمی سایت یاد بگیریم تصاویر نامتناسب، ایرادهای نمایش در موبایل، فایل‌های سنگین، منابع مسدودکننده و فونت‌ها چطور می‌تونن تجربه خرید رو سخت کنن. بعد همین موارد رو قدم‌به‌قدم در فروشگاه خودتون بررسی می‌کنیم.

نکته مهم اینه که نتیجه هر تست فقط وضعیت یک صفحه در همون زمان و شرایط رو نشون می‌ده. پس تصاویر قدیمی این مقاله رو نباید گزارش قطعی از وضعیت فعلی دیجی کالا بدونید. این نمونه‌ها کمک می‌کنن روش درست آزمایش و اولویت‌بندی مشکلات رو یاد بگیرید؛ روشی که برای فروشگاه‌های وردپرسی و سایت‌های اختصاصی کاربرد داره.

مشکلات سایت دیجی کالا رو چطور بررسی کنیم؟

قبل از نتیجه‌گیری به تاریخ و شرایط تست دقت کنید

ظاهر و کد یک فروشگاه بزرگ مرتب تغییر می‌کنه. حتی نتیجه دو آزمایش پشت‌سرهم هم ممکنه به‌خاطر سرعت اینترنت، شلوغی سرور، حافظه موقت مرورگر یا محتوای متفاوت صفحه یکسان نباشه. برای همین، قبل از اینکه یک هشدار رو مشکل قطعی بدونید، تاریخ تست، آدرس دقیق صفحه، نوع دستگاه، اندازه صفحه و وضعیت اتصال اینترنت رو یادداشت کنید.

اگه از Lighthouse استفاده می‌کنید، بهتره چند بار با شرایط ثابت آزمایش بگیرید و نتیجه میانی رو ملاک قرار بدید. Lighthouse ابزار آزمایش مرورگره و عملکرد صفحه رو در شرایط شبیه‌سازی‌شده بررسی می‌کنه. امتیاز این ابزار به‌تنهایی هدف نهایی نیست؛ مهم‌تر از اون، مشکلیه که کاربر واقعی موقع دیدن یا خرید محصول حس می‌کنه.

صفحه اصلی، دسته‌بندی و محصول رو جداگانه بسنجید

یک نتیجه از صفحه اصلی، وضعیت کل فروشگاه رو نشون نمی‌ده. صفحه اصلی معمولاً بنر و پیشنهادهای زیادی داره، صفحه دسته‌بندی فیلتر و تعداد زیادی کارت محصول رو نمایش می‌ده و صفحه محصول هم گالری، مشخصات، نظرها و دکمه خرید داره. هرکدوم از این صفحه‌ها فایل‌ها و رفتار متفاوتی دارن.

حداقل یک صفحه از هر نوع رو آزمایش کنید. اگه فروشگاهتون صفحه سبد خرید و تسویه‌حساب هم داره، اون‌ها رو جدا ببینید. سرعت صفحه محصول مهمه، ولی خراب‌شدن دکمه پرداخت یا سخت‌بودن کار با فرم تسویه‌حساب اثر مستقیم‌تری روی فروش داره.

مشکلات تصاویر در سایت دیجی کالا

نمایش تصاویر بزرگ‌تر از اندازه موردنیاز

یکی از نمونه‌های ثبت‌شده در نسخه قبلی این مقاله، تصویری با اندازه ۸۵۶ در ۴۲۸ پیکسل بود. همون تصویر در فضایی نزدیک به ۴۳۷ در ۲۱۸ پیکسل نمایش داده می‌شد. مرورگر می‌تونه تصویر بزرگ رو کوچک نشون بده، ولی معمولاً مجبور می‌شه داده بیشتری دانلود کنه. تصویر زیر یک نمونه تاریخیه و وضعیت فعلی دیجی کالا رو تأیید نمی‌کنه.

این تصویر نمونه فقط شرایط همون آزمایش قدیمی رو نشون می‌ده و برای اثبات وضعیت فعلی همه تصاویر دیجی کالا کافی نیست. برای بررسی امروز باید صفحه موردنظرتون رو دوباره آزمایش کنید و ببینید مرورگر چه فایل تصویری رو با چه ابعادی دریافت می‌کنه.

در فروشگاه خودتون هم به تفاوت «اندازه اصلی فایل» و «اندازه محل نمایش» دقت کنید. مثلاً اگه یک تصویر ۱۶۰۰ پیکسلی داخل کارت ۳۰۰ پیکسلی دیده می‌شه، بهتره مرورگر نسخه‌ای نزدیک‌تر به همون اندازه رو دریافت کنه. البته نمایشگرهای پُرتراکم ممکنه به تصویری کمی بزرگ‌تر از اندازه ظاهری نیاز داشته باشن تا عکس تار نشه.

بررسی Properly Size Images به زبان ساده

Properly Size Images یعنی تصاویر رو با اندازه مناسب محل نمایش تحویل بدید. این عبارت در بعضی گزارش‌های جدیدتر به‌جای اصطلاح قدیمی Serve Scaled Images دیده می‌شه، ولی نام و محل این بررسی ممکنه بین ابزارها و نسخه‌های مختلف فرق کنه. اصل موضوع همونه: بعضی تصاویر نباید خیلی بزرگ‌تر از چیزی دانلود بشن که کاربر واقعاً می‌بینه. راهنمای نمایش تصویر با ابعاد مناسب در web.dev جزئیات این موضوع رو توضیح می‌ده.

برای بررسی جزئیات، گزارش فعلی Lighthouse رو باز کنید و بخش‌های مربوط به تصاویر رو ببینید. بسته به نسخه ابزار، ممکنه فهرست فایل‌های مشکل‌دار و مقدار تقریبی کاهش حجم هم نمایش داده بشه. اول سراغ عکس‌هایی برید که حجم بیشتری دارن و در بالای صفحه دیده می‌شن؛ چون این عکس‌ها معمولاً زودتر جلوی چشم کاربر قرار می‌گیرن.

نقش srcset و sizes در انتخاب اندازه مناسب تصویر

srcset فهرستی از نسخه‌های مختلف یک تصویر رو به مرورگر معرفی می‌کنه. sizes هم به مرورگر سرنخ می‌ده که تصویر در اندازه‌های مختلف صفحه تقریباً چقدر فضا می‌گیره. مرورگر با کمک این دو ویژگی، نسخه مناسب‌تری رو انتخاب می‌کنه.

وردپرس برای تصاویر بارگذاری‌شده در کتابخانه رسانه معمولاً این اطلاعات رو به‌صورت خودکار تولید می‌کنه. ولی این قابلیت تضمین نمی‌کنه که همه‌چیز همیشه بی‌نقص باشه. قالب باید مقدار sizes درستی بسازه، اندازه‌های مناسب تصویر باید روی سرور آماده باشن و افزونه یا صفحه‌ساز هم نباید خروجی رو خراب کنه. جزئیات فنی این قابلیت در مستندات تصاویر واکنش‌گرای وردپرس اومده. اگه تازه با این سیستم آشنا شدید، مقاله وردپرس چیست و چطور با وردپرس سایت بسازیم نقطه شروع ساده‌ایه.

فرمت جدید، CDN و ابعاد مشخص چه کمکی می‌کنن؟

فرمت‌هایی مثل WebP و AVIF در خیلی از تصاویر می‌تونن حجم رو بدون افت آزاردهنده کیفیت کمتر کنن. نتیجه دقیق به نوع عکس و تنظیمات فشرده‌سازی بستگی داره، پس بهتره کیفیت نسخه نهایی رو با چشم هم بررسی کنید. برای عکس محصول، جزئیات مهم‌تر از اینه که فقط کوچک‌ترین فایل ممکن رو بسازید.

CDN تصویر یعنی شبکه‌ای که عکس رو از سروری نزدیک‌تر به کاربر تحویل می‌ده و گاهی اندازه و فرمت مناسب رو هم همون لحظه آماده می‌کنه. این راهکار برای فروشگاه‌های پُرتصویر مفیده، ولی تنظیم اشتباه کش یا فشرده‌سازی می‌تونه تصویر قدیمی یا کم‌کیفیت نشون بده.

مشخص‌کردن width و height هم به مرورگر کمک می‌کنه قبل از دانلود عکس، فضای لازم رو کنار بذاره. این کار احتمال جابه‌جایی ناگهانی متن و دکمه‌ها رو کمتر می‌کنه. این ویژگی جای انتخاب اندازه درست فایل رو نمی‌گیره؛ هر دو مورد باید کنار هم تنظیم بشن.

مشکلات احتمالی ریسپانسیو در صفحه‌های فروشگاه

منو، فیلتر و کارت محصول در موبایل و تبلت

ریسپانسیو یعنی صفحه خودش رو با اندازه نمایشگر هماهنگ کنه. در نمونه ثبت‌شده قبلی، ستون فیلتر یک صفحه دسته‌بندی روی اندازه شبیه آیپد جای مناسبی نداشت. تصویر زیر فقط وضعیت همون نسخه قدیمی از صفحه رو نشون می‌ده و بدون آزمایش تازه نمی‌شه اون رو مشکل فعلی دیجی کالا دونست.

در فروشگاه خودتون فقط به کوچک‌شدن اجزا نگاه نکنید. منو باید راحت باز و بسته بشه، فیلتر نباید روی محصولات گیر کنه، عنوان و قیمت کارت‌ها نباید بریزن و دکمه افزودن به سبد خرید هم باید با انگشت راحت لمس بشه. صفحه رو در حالت عمودی و افقی هم ببینید.

تست با حالت Device Mode مرورگر کروم

برای یک بررسی سریع، صفحه رو در Google Chrome باز کنید. با راست‌کلیک روی صفحه گزینه Inspect رو بزنید. بعد نماد موبایل و تبلت رو در نوار ابزار توسعه‌دهنده انتخاب کنید. این بخش Device Mode نام داره و ظاهر صفحه رو در اندازه‌های مختلف شبیه‌سازی می‌کنه. حالا می‌تونید اندازه‌هایی مثل موبایل، تبلت یا یک عرض دلخواه رو آزمایش کنید.

فقط چند دستگاه آماده رو انتخاب نکنید. عرض صفحه رو آروم کم و زیاد کنید تا فاصله بین اندازه‌های رایج هم بررسی بشه. خیلی از ایرادهای چیدمان دقیقاً در عرضی دیده می‌شن که داخل فهرست دستگاه‌های آماده نیست. منو، فیلتر، گالری، جدول مشخصات، پنجره‌های بازشو و فرم‌ها رو هم واقعاً استفاده کنید.

چرا باید نتیجه رو روی دستگاه واقعی هم بررسی کنید؟

Device Mode اندازه صفحه و بعضی ویژگی‌های دستگاه رو شبیه‌سازی می‌کنه، ولی خودش یک موبایل یا تبلت واقعی نیست. لمس با انگشت، نوارهای مرورگر موبایل، صفحه‌کلید، توان پردازنده، حافظه و رفتار بعضی قابلیت‌ها روی دستگاه واقعی فرق دارن.

پس اگه در شبیه‌ساز مشکلی دیدید، اون رو روی دستگاه واقعی تأیید کنید. برعکسش هم مهمه: سالم‌بودن ظاهر در شبیه‌ساز تضمین نمی‌کنه تجربه واقعی خوب باشه. بهتره دست‌کم یک گوشی ضعیف‌تر و یک گوشی جدیدتر رو در برنامه تستتون داشته باشید.

مشکلات سرعت و فایل‌های CSS و JavaScript

مینیفای‌کردن فایل‌ها دقیقاً چه کاری انجام می‌ده؟

CSS ظاهر صفحه رو کنترل می‌کنه و JavaScript رفتارهایی مثل بازشدن منو، فیلتر یا گالری رو می‌سازه. مینیفای‌کردن یعنی فاصله‌ها، توضیح‌های داخل کد و بخش‌های غیرضروری فایل حذف بشن تا حجم انتقال کمتر بشه. این کار با فشرده‌سازی سمت سرور فرق داره، هرچند هر دو می‌تونن کنار هم استفاده بشن.

تصویر زیر نتیجه یک آزمایش قدیمی از فایل‌های سایت رو نشون می‌ده و وضعیت فعلی دیجی کالا رو تأیید نمی‌کنه. برای قضاوت درباره وضعیت امروز باید فایل‌های زنده دوباره بررسی بشن. اسم فایل هم به‌تنهایی کافی نیست؛ محتوای دریافتی و حجم انتقال‌یافته مهمه.

مینیفای‌کردن کار مفیدیه، ولی معمولاً بزرگ‌ترین فرصت بهینه‌سازی نیست. یک فایل کوچک و مینیفای‌شده هنوز ممکنه کد زیادی داشته باشه که صفحه بهش نیاز نداره. پس کنار مینیفای، مقدار کد استفاده‌نشده و زمان اجرای JavaScript رو هم بررسی کنید.

چطور فایل‌های استفاده‌نشده و کدهای سنگین رو پیدا کنید؟

ابزار Coverage در DevTools کروم نشون می‌ده چه بخشی از CSS و JavaScript در آزمایش فعلی استفاده شده. Coverage یعنی گزارش میزان استفاده از کدهای هر فایل. برای بازکردنش وارد Inspect بشید، منوی ابزارها رو باز کنید و Coverage رو پیدا کنید. بعد صفحه رو دوباره بارگذاری کنید و چند کار اصلی مثل بازکردن منو یا فیلتر رو انجام بدید.

قرمزبودن بخشی از فایل به این معنی نیست که باید فوری حذفش کنید. شاید اون کد بعد از کلیک، ورود کاربر یا رفتن به مرحله بعدی خرید لازم بشه. اگه برنامه‌نویس نیستید، خودتون کد قرمز رو حذف نکنید. اول مشخص کنید فایل از کدوم قالب، افزونه یا سرویس اومده و بعد غیرفعال‌کردن یا بارگذاری شرطی اون رو در یک نسخه آزمایشی از سایت امتحان کنید.

پنل Performance هم یک جدول زمانی از کارهای مرورگر نشون می‌ده. اگه یک اسکریپت برای مدت طولانی پردازنده رو مشغول کنه، صفحه ممکنه دیده بشه ولی به لمس یا کلیک کاربر دیر جواب بده. در چنین شرایطی، تقسیم کد، اجرای دیرتر یا حذف قابلیت غیرضروری می‌تونه از چند کیلوبایت کاهش حجم مهم‌تر باشه.

چرا کم‌شدن حجم فایل همیشه به همون اندازه سرعت رو بیشتر نمی‌کنه؟

زمان بارگذاری فقط به حجم فایل وابسته نیست. فاصله کاربر تا سرور، تأخیر شبکه، کش مرورگر، فشرده‌سازی، تعداد درخواست‌ها و توان پردازنده دستگاه هم اثر دارن. کم‌شدن چند کیلوبایت مفیده، ولی نمی‌شه اون رو مستقیم به تعداد ثانیه مشخصی از صرفه‌جویی تبدیل کرد.

به‌جای ضرب‌کردن حجم فایل در تعداد بازدید، نتیجه رو با آزمایش قبل و بعد بسنجید. سرعت نمایش محتوای اصلی، زمان پاسخ‌گویی به کلیک و حجم انتقال رو ثبت کنید. بعد ببینید تغییر انجام‌شده واقعاً تجربه کاربر رو بهتر کرده یا فقط امتیاز یک بخش گزارش رو بالا برده.

منابع مسدودکننده نمایش صفحه

Render-Blocking یعنی چی؟

Render-Blocking یعنی مرورگر قبل از نمایش بخش قابل‌دیدن صفحه منتظر دریافت یا پردازش یک منبع می‌مونه. به زبان ساده، یک فایل جلوی نمایش سریع صفحه رو می‌گیره. این منبع معمولاً یک فایل CSS یا JavaScript هست. اگه فایل بزرگ یا سرور کند باشه، کاربر مدت بیشتری صفحه سفید یا ناقص می‌بینه.

بااین‌حال، هر فایلی که در ابتدای صفحه بارگذاری می‌شه بد نیست. بخشی از CSS برای نمایش درست عنوان، تصویر اصلی، منو و دکمه‌ها لازمه. هدف این نیست که همه منابع رو عقب بندازید؛ باید کد ضروری رو سریع برسونید و کد غیرضروری رو از مسیر نمایش اولیه کنار بزنید.

کدهای ضروری برای نمایش اولیه صفحه

نمایش اولیه همون بخشی از صفحه‌ست که کاربر بدون اسکرول می‌بینه. در صفحه محصول، این بخش ممکنه هدر، نام محصول، تصویر، قیمت و دکمه خرید رو شامل بشه. استایل لازم برای این عناصر باید زود در دسترس مرورگر قرار بگیره.

اول مشخص کنید بالای هر نوع صفحه چه اجزایی داره. بعد فایل‌ها رو بررسی کنید تا بفهمید کد لازم برای همون اجزا کجاست. اگه یک فایل بزرگ، استایل همه صفحه‌های سایت رو یکجا حمل می‌کنه، تقسیم منطقی یا بارگذاری شرطی می‌تونه مفید باشه. این تغییرها فنی هستن؛ پس اگه با کد آشنا نیستید، بهتره اجرای اون‌ها رو به توسعه‌دهنده بسپارید.

کاربرد Critical CSS برای نمایش سریع‌تر بخش بالای صفحه

Critical CSS یعنی بخش کوچکی از استایل‌های ضروری برای محتوای بالای صفحه. این کد می‌تونه مستقیم داخل صفحه قرار بگیره تا مرورگر بدون انتظار برای فایل کامل CSS، ظاهر اولیه رو بسازه. فایل‌های باقی‌مونده بعدتر دریافت می‌شن. راهنمای بهینه‌سازی LCP در web.dev درباره سریع‌تر نمایش‌دادن محتوای اصلی صفحه توضیح بیشتری می‌ده.

ساخت Critical CSS باید برای قالب و انواع صفحه درست انجام بشه. کد ناقص ممکنه برای چند لحظه صفحه‌ای به‌هم‌ریخته نشون بده و کد بیش‌ازحد بزرگ هم فایده این روش رو کم می‌کنه. بعد از هر تغییر قالب، افزونه یا چیدمان باید خروجی دوباره آزمایش بشه.

تفاوت defer و async برای فایل‌های JavaScript

برای فایل‌های JavaScript کلاسیک و بیرونی، ویژگی defer اجازه می‌ده فایل هم‌زمان با ادامه خواندن HTML دانلود بشه، ولی اجرای اون تا بعد از آماده‌شدن ساختار صفحه عقب می‌افته. ترتیب اجرای چند فایل defer هم براساس ترتیب اون‌ها در صفحه حفظ می‌شه. این ویژگی برای اسکریپت‌هایی که به ساختار صفحه یا فایل قبلی وابسته‌ان انتخاب رایج‌تریه.

ویژگی async هم دانلود رو موازی انجام می‌ده، ولی فایل به‌محض آماده‌شدن اجرا می‌شه و ترتیب مشخصی بین چند فایل async نداره. برای اسکریپت‌های مستقل می‌تونه مناسب باشه. اگه فایل به اسکریپت دیگه یا عناصر صفحه وابسته‌ست، استفاده ناآگاهانه از async ممکنه قابلیت‌هایی مثل فیلتر، گالری یا سبد خرید رو خراب کنه.

چرا انتقال همه فایل‌ها به فوتر راه‌حل مناسبی نیست؟

انتقال یکجای همه CSS و JavaScript به انتهای صفحه نسخه ساده ولی خطرناکی از بهینه‌سازیه. اگه CSS اصلی دیر برسه، کاربر اول متن و عناصر بدون ظاهر درست رو می‌بینه. اگه JavaScript ضروری دیر اجرا بشه، منو، دکمه یا فرم ممکنه چند لحظه کار نکنه.

راه بهتر اینه که وابستگی هر فایل رو بشناسید. CSS لازم برای نمایش اولیه رو زود نگه دارید، JavaScript غیرضروری رو با روش مناسب عقب بندازید و نتیجه رو در مسیر واقعی خرید آزمایش کنید. ظاهر خوب بدون امکان خرید کافی نیست و امتیاز سرعت خوب هم نباید به قیمت خراب‌شدن امکانات تموم بشه.

مشکلات بارگذاری فونت و نمایش متن

تأخیر در نمایش متن چه اثری روی تجربه کاربر داره؟

در نمونه قدیمی مقاله، تا قبل از دریافت فونت بخشی از متن دیده نمی‌شد. تصویر زیر فقط برای توضیح رفتار بارگذاری فونت در همون آزمایش قدیمیه و وضعیت فعلی سایت رو ثابت نمی‌کنه. برای بررسی امروز باید فایل CSS و درخواست‌های فونت همون صفحه دوباره آزمایش بشن.

وقتی متن دیر دیده می‌شه، کاربر نمی‌تونه سریع عنوان، قیمت یا توضیح محصول رو بخونه. این مشکل روی اتصال کند بیشتر خودش رو نشون می‌ده. از طرف دیگه، اگه اول فونت جایگزین نمایش داده بشه و بعد فونت اصلی شکل متن رو عوض کنه، چیدمان ممکنه جابه‌جا بشه.

تفاوت font-display: swap، fallback و optional

font-display: swap متن رو سریع با یک فونت جایگزین نشون می‌ده و بعد از آماده‌شدن فونت اصلی، اون رو عوض می‌کنه. مزیتش اینه که متن پنهان نمی‌مونه. ولی تفاوت اندازه دو فونت ممکنه باعث جابه‌جایی عناصر بشه.

fallback مدت کوتاهی برای فونت اصلی صبر می‌کنه و بعد سراغ فونت جایگزین می‌ره. فرصت تعویض بعدی هم محدودتره. optional اختیار بیشتری به مرورگر می‌ده تا در اتصال ضعیف از همون فونت جایگزین استفاده کنه و دانلود فونت اصلی رو برای نمایش فعلی ضروری ندونه.

هیچ‌کدوم برای همه سایت‌ها بهترین گزینه نیستن. انتخاب درست به اهمیت فونت برند، نوع متن و میزان تفاوت فونت جایگزین بستگی داره. راهنمای بهترین روش‌های بارگذاری فونت در web.dev تفاوت این انتخاب‌ها رو توضیح می‌ده. برای رفع یک خطای رایج هم می‌تونید راهنمای رفع خطای Ensure Text Remains Visible در GTmetrix رو بخونید.

چطور بین نمایش سریع متن و جلوگیری از جابه‌جایی صفحه تعادل بسازید؟

اول فونت‌های غیرضروری و وزن‌هایی رو که استفاده نمی‌کنید حذف کنید. مثلاً اگه فقط وزن معمولی و بولد لازم دارید، دانلود چند وزن اضافه فایده‌ای نداره. بعد فایل فونت رو از منبع سریع تحویل بدید و فقط فونت‌های واقعاً مهم رو زودتر بارگذاری کنید.

فونت جایگزینی انتخاب کنید که عرض و ارتفاع حروفش به فونت اصلی نزدیک باشه. بعد صفحه رو با اینترنت کند آزمایش کنید و به حرکت عنوان، قیمت، دکمه خرید و منو دقت کنید. گزینه swap، fallback یا optional رو براساس همین نتیجه واقعی انتخاب کنید، نه فقط یک توصیه عمومی.

تأثیر مشکلات فنی فروشگاه روی کاربر و فروش

کندی صفحه و رهاکردن فرایند خرید

کاربر برای دیدن محصول، مقایسه، افزودن به سبد و پرداخت چند صفحه رو پشت‌سرهم باز می‌کنه. تأخیرهای کوچک در هر مرحله روی هم جمع می‌شن. اگه صفحه دیر جواب بده یا کاربر مطمئن نباشه کلیکش ثبت شده، ممکنه دوباره کلیک کنه، به مرحله قبل برگرده یا خرید رو کنار بذاره.

برای فهمیدن اثر واقعی مشکل فقط به تست آزمایشگاهی تکیه نکنید. رفتار کاربران رو هم ببینید. ابزارهایی مثل مایکروسافت کلاریتی می‌تونن ضبط جلسه و نقشه کلیک رو در اختیارتون بذارن تا نقاط سردرگمی رو پیدا کنید. هنگام استفاده از این ابزارها، تنظیمات حریم خصوصی و مخفی‌کردن اطلاعات حساس رو جدی بگیرید.

مشکلات موبایل و سخت‌شدن پیدا کردن محصول

اگه فیلتر در موبایل درست باز نشه، کاربر بین تعداد زیادی محصول گیر می‌کنه. اگه نام، قیمت یا وضعیت موجودی کامل دیده نشه، مقایسه سخت می‌شه. دکمه‌های کوچک و نزدیک به هم هم احتمال لمس اشتباه رو بالا می‌برن.

یک آزمایش ساده انجام بدید: فقط با یک دست محصولی رو جست‌وجو کنید، فیلتر بذارید، وارد صفحه محصول بشید و اون رو به سبد اضافه کنید. هرجایی که مجبور شدید زوم کنید، چند بار بزنید یا دنبال دکمه بگردید، یک مشکل واقعی تجربه کاربر پیدا کردید.

جابه‌جایی عناصر و کلیک اشتباه کاربر

تصویر، بنر یا فونتی که دیر بارگذاری می‌شه ممکنه عناصر صفحه رو حرکت بده. کاربر قصد داره روی «افزودن به سبد خرید» بزنه، ولی همون لحظه یک بخش جدید بالای دکمه ظاهر می‌شه و محل اون رو عوض می‌کنه. نتیجه می‌تونه کلیک اشتباه و حس بی‌اعتمادی باشه.

برای کاهش این اتفاق، فضای تصویر و ویدئو رو از قبل مشخص کنید، جای پیام‌های بالای صفحه رو ثابت نگه دارید و بارگذاری فونت رو آزمایش کنید. تبلیغ یا نوار اطلاع‌رسانی هم نباید بعد از شروع تعامل کاربر ناگهان بالای صفحه اضافه بشه.

چطور همین مشکلات رو در فروشگاه خودتون پیدا کنید؟

1. صفحه‌های مهم فروشگاه رو مشخص کنید. صفحه اصلی، یک دسته‌بندی شلوغ، یک محصول پُربازدید، سبد خرید و تسویه‌حساب رو انتخاب کنید. اگه چند قالب متفاوت برای محصول دارید، از هرکدوم یک نمونه بردارید.
2. تست Lighthouse رو با شرایط ثابت انجام بدید. در کروم وارد Inspect و بعد Lighthouse بشید. نوع دستگاه و دسته Performance رو انتخاب کنید. هر صفحه رو چند بار با شرایط مشابه آزمایش کنید و تاریخ و نتیجه رو نگه دارید.
3. گزارش Network و Performance رو بررسی کنید. Network یعنی فهرست درخواست‌های صفحه و حجم و زمان دریافت فایل‌ها رو نشون می‌ده. Performance هم یک جدول زمانی از کارهای مرورگر می‌سازه تا کدهای سنگین و تأخیر در پاسخ صفحه رو راحت‌تر ببینید.
4. فروشگاه رو در چند اندازه صفحه آزمایش کنید. فقط اندازه یک موبایل رو نبینید. عرض صفحه رو تغییر بدید و منو، جست‌وجو، فیلتر، گالری، دکمه خرید و فرم‌ها رو استفاده کنید.
5. نتیجه رو روی موبایل یا تبلت واقعی تأیید کنید. بهتره یک دستگاه معمولی یا ضعیف‌تر هم داشته باشید. آزمایش فقط روی گوشی سریع و اینترنت پُرسرعت بخشی از مشکلات کاربران رو پنهان می‌کنه.
6. مشکلات رو براساس اثرشون روی کاربر اولویت‌بندی کنید. خرابی پرداخت، کارنکردن دکمه خرید و دیده‌نشدن قیمت از یک هشدار کوچک مینیفای مهم‌ترن. اول مواردی رو درست کنید که جلوی پیدا کردن یا خرید محصول رو می‌گیرن.

قبل از تغییر قالب یا افزونه، از سایت نسخه پشتیبان بگیرید و بهینه‌سازی‌ها رو در محیط آزمایشی انجام بدید. اگه با CSS یا JavaScript آشنا نیستید، حذف فایل یا تغییر ترتیب اجرای اون رو به یک متخصص بسپارید. بعد از هر تغییر فقط امتیاز رو نبینید؛ جست‌وجو، ورود، سبد خرید، کد تخفیف و پرداخت رو هم دوباره امتحان کنید.

چک‌لیست جلوگیری از مشکلات مشابه در فروشگاه اینترنتی

• تصاویر رو متناسب با محل نمایش آماده کنید و نسخه خیلی بزرگ رو برای کارت کوچک نفرستید.
• ابعاد تصاویر رو از قبل مشخص کنید تا صفحه موقع بارگذاری جابه‌جا نشه.
• خروجی srcset و sizes رو در قالب و صفحه‌های مهم بررسی کنید.
• فایل‌های اضافی CSS و JavaScript رو پیدا کنید و فقط بعد از آزمایش امن کمشون کنید.
• اجرای JavaScript غیرضروری رو با defer یا روش مناسب عقب بندازید.
• CSS ضروری بالای صفحه رو سریع تحویل بدید و باقی استایل‌ها رو بدون ایجاد ظاهر به‌هم‌ریخته مدیریت کنید.
• روش بارگذاری فونت رو با سرعت نمایش متن و میزان جابه‌جایی صفحه بسنجید.
• منو، فیلتر، کارت محصول و فرایند پرداخت رو روی دستگاه واقعی امتحان کنید.
• صفحه‌های فروشگاه رو بعد از تغییر قالب، افزونه، بنر یا کد رهگیری دوباره تست کنید.

جمع‌بندی مشکلات سایت دیجی کالا

نمونه‌های قدیمی مشکلات سایت دیجی کالا به ما یاد می‌دن که حتی یک فروشگاه شناخته‌شده هم باید تصاویر، چیدمان صفحه، فایل‌های CSS و JavaScript و فونت‌ها رو مرتب آزمایش کنه. ولی هیچ تصویر یا گزارش قدیمی برای قضاوت درباره وضعیت امروز یک سایت کافی نیست. هر ادعا باید با تست تازه، صفحه مشخص و شرایط ثبت‌شده بررسی بشه.

برای فروشگاه خودتون از صفحه‌های مهم شروع کنید و مشکل‌ها رو براساس اثر روی کاربر بچینید. اول خرابی‌های مسیر خرید و نمایش موبایل رو برطرف کنید. بعد سراغ تصاویر سنگین، کدهای استفاده‌نشده، منابع مسدودکننده و فونت‌ها برید. این نگاه عملی کمک می‌کنه به‌جای دنبال‌کردن یک امتیاز، فروشگاهی سریع‌تر و راحت‌تر برای مشتری بسازید. برای دیدن ارتباط تجربه بهتر با درآمد هم می‌تونید مقاله تأثیر سئو در فروش و افزایش درآمد سایت رو بخونید.

سؤال‌های رایج درباره مشکلات سایت دیجی کالا

تیم تولید محتوا

ما در تیم تولید محتوای میهن وردپرس در تلاش هستیم تا بهترین مقالات آموزشی در زمینه وردپرس و کسب‌و‌کارهای اینترنتی را تهیه کنیم. صحت محتوای این صفحه توسط رضا راد بررسی خواهد شد.