اشتباهات بصری در کدهای تولیدشده با هوش مصنوعی سرعت موبایل را می‌گیرد

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

طبق گزارش ۲۳ ژوئن ۲۰۲۶ در وب‌سایت dev.to، یک توسعه‌دهنده متوجه شد که یک قالب سفارشی‌ساز شده توسط هوش مصنوعی، در حالی که در دسکتاپ نمره ۱۰۰ را داشت، پس از اعمال ویرایش‌های جزئی در محتوا، در نسخه موبایل به نمره ۸۹ سقوط کرد. این افت عملکرد، تله‌ای رایج برای «توسعه‌دهندگان مشتاق» است که برای ایجاد اسکلت‌بندی وب‌سایت‌ها به مدل‌های زبانی بزرگ (LLM) تکیه می‌کنند. این مدل‌ها — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — اگرچه کدهای HTML تمیزی می‌نویسند، اما فاقد «آگاهی مکان‌مند» هستند. یعنی نمی‌دانند یک صفحه در واقعیت چگونه در چشم کاربر دیده می‌شود. برای مثال، هوش مصنوعی ممکن است فرض کند اولین تصویر موجود در کد، مهم‌ترین تصویر است و نادیده بگیرد که سایر عناصر گرافیکی یا متنی، آن تصویر را به جایی بسیار پایین‌تر از محدوده دید اولیه (Below the fold) منتقل می‌کنند.

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

زمینه: ساختار پروژه

پروژه مذکور، یک سایت وردپرسی اختصاصی بود که روی بازی‌های کلاسیک PC دهه ۹۰ تمرکز داشت. توسعه‌دهنده به جای کدنویسی دستی قالب، چیدمان مورد نظر را توصیف کرد، محتوای صفحه اصلی را ارائه داد و از هوش مصنوعی خواست تا قالب را از صفر بسازد.e لانچ اولیه موفقیت‌آمیز بود؛ هیچ آشفتگی ظاهری دیده نمی‌شد و سرعت بارگذاری در هر دو نوع دستگاه (دسکتاپ و موبایل) سریع بود.

بر اساس مستندات این گزارش در dev.to، هوش مصنوعی ویژگی fetchpriority="high" را به اسکرین‌شاتی از بازی «علاءالدین» دیزنی اختصاص داد. در کد منبع (Source Code)، این اقدام کاملاً درست و بهینه به نظر می‌رسید. اما در واقعیت، این تصویر زیر یک جدول داده‌ای عظیم با ۲۵ ردیف از بازی‌های PC قرار داشت که در سایت bestclassicpcgames.com قابل مشاهده است. در نمای موبایل (Viewport)، این جدول به‌طور کامل صفحه را می‌پوشاند و بخش‌های مربوط به بازی‌ها را به اعماق پایین صفحه می‌راند. در نتیجه، مرورگر مجبور می‌شد پهنای باند محدود 4G را برای دریافت دارایی پنهانی هدر دهد که کاربر هنوز آن را نمی‌بیند.

جزئیات: شکست فنی

بررسی قالب پوسته، خطای کدنویسی خاصی را آشکار کرد:

• کد معیوب: <img src="..." alt="Aladdin video game" width="800" height="450" fetchpriority="high">
• پیش‌فرض ساده‌انگارانه: هوش مصنوعی تصور کرد اولین تگ <img> در کد منبع HTML، همان تصویر قهرمان یا اصلی (Hero Image) است. در حالی که این منطق برای چیدمان‌های استاندارد وبلاگی صادق است، اما در اینجا به دلیل تغییر سلسله‌مراتب مکانی ناشی از جدول داده‌ای، شکست خورد.
• راه حل: این ویژگی به صورت دستی به <img src="..." alt="Aladdin video game" width="800" height="450" loading="lazy"> تغییر یافت.

این اصلاح ساده باعث شد زمان LCP (بزرگ‌ترین رنگ‌آمیزی محتوایی) در موبایل دوباره به رقم پایدار ۱.۰ ثانیه بازگردد. همچنین این فرآیند یک تله رایج در عیب‌یابی (Debugging) را برجسته کرد: کش-سرور (Server-side caching). این لایه از کش در ابتدا اثر اصلاحیه را می‌پوشاند و باعث شد به نظر برسد که کد تغییر نکرده است. توسعه‌دهنده ۲۰ دقیقه زمان صرف جستجو برای یافتن یک لایه‌ی بهینه‌سازی شبحی یا فیلتر وردپرس کرد، تا اینکه متوجه شد لایه‌ی کش در حال سرو کردن نسخه‌ی HTML پیش از ویرایش است.

این سناریو نوعی «بدهی فنی هوش مصنوعی» (AI Technical Debt) را آشکار می‌کند. چون مدل‌ها بر اساس پیش‌فرض‌های ساده‌انگارانه عمل می‌کنند — مانند اینکه ترتیب DOM برابر با ترتیب بصری است — کدی تولید می‌کنند که در ظاهر «تمیز» است اما در عمل، استراتژی‌های بهینه‌سازی ارسال دارایی‌ها را معکوس می‌کند. چنین نقاط کوری را می‌توان با ابزارهای تخصصی شناسایی کرد؛ برای مثال پلتفرم Boostora از هوش مصنوعی برای یافتن نقاط شکست در تجربه کاربری و بهینه‌سازی نرخ تبدیل استفاده می‌کند تا این شکاف‌های عملکردی را پیش‌بینی کند.

برای کسانی که از LLMها برای ساخت کامپوننت‌ها استفاده می‌کنند، درس این است: فرض‌های ساختاری باید در برابر Viewport واقعی بررسی شوند. شما نمی‌توانید تنها به نمرات Lighthouse اعتماد کنید، زیرا اتصالات سریع دسکتاپ اغلب گلوگاه‌هایی را می‌پوشانند که تنها در شرایط شبیه‌سازی محدودیت سرعت موبایل (Mobile Throttling) ظاهر می‌شوند.

برای اجتناب از این تله‌ها، یک بررسی سراسری (Global Grep) به خط لوله بازبینی خود اضافه کنید:

• حسابرسی fetchpriority و loading="lazy": این ویژگی‌ها را بر اساس سلسله‌مراتب بصری واقعی در صفحه بررسی کنید، نه ترتیب قرارگیری در کد DOM.
• شناسایی دارایی‌های پنهان: به دنبال تصاویری بگردید که زیر اسلایدرهای اصلی، عناصر سنگین چیدمان یا جداول داده‌ای بزرگ دفن شده‌اند.
• جداسازی محیط‌ها: همیشه قبل از تست مجدد، لایه‌های کش سرور را پاک کنید (Purge) تا از بازرسی کدهای قدیمی و تجربه «پانیک عیب‌یابی» جلوگیری کنید.

کدهای تولید شده توسط هوش مصنوعی اکنون به اندازه کافی تمیز هستند که منتشر شوند، اما همچنان یک «اسکلت» هستند، نه یک محصول نهایی. نقش انسان از نوشتن خطوط کد به تأیید این موضوع تغییر کرده است که منطق هوش مصنوعی با واقعیت فیزیکی صفحه نمایش مطابقت داشته باشد.