داینامیک رندرینگ در دنیای تکنیکال چیست؟

داینامیک رندرینگ (Dynamic Rendering) یک راهکار میانی بود که برای حل تضاد همیشگی بین سایت‌های جاوااسکریپتی و نیاز موتورهای جستجو به HTML قابل‌خزش مطرح شد. این که کاربران بتوانند جاوااسکریپت اجرا کنند و محتوای نهایی را ببینند، اما خزنده‌هایی که با JS مشکل دارند(خزنده های گوگل)، بدون نیاز به اجرای جاوااسکریپت، محتوای اصلی صفحات سایت را ببینند.

با این حال، گوگل طی به‌روزرسانی مستنداتش صراحتاً تأکید کرده که داینامیک رندرینگ راهکار موقتی بوده و راه‌حل بلندمدت توصیه‌شده نیست و به‌جای آن باید به سمت SSR، Static Rendering یا Hydration رفت.

چرا اصلاً Dynamic Rendering به وجود آمد؟

اگر یک سایت به صورت Client-Side Rendering ساخته شود، بخش مهمی از محتوا ممکن است بعد از لود اولیه و با اجرای جاوااسکریپت تولید شود. در عمل، این یعنی:

• کاربر در مرورگر، همه چیز را می‌بیند.
• اما خزنده‌ای که JS را اجرا نمی‌کند یا محدودیت دارد، ممکن است HTML ناقص دریافت کند و «محتوای اصلی» را نبیند.

از نگاه گوگل، اجرای جاوااسکریپت برای تمام صفحات وب هزینه‌بر است؛ هم از نظر پردازشی، هم زمان‌بندی و صف رندر. به همین دلیل گوگل سال‌هاست روی این نکته تأکید دارد که جاوااسکریپت در Search محدودیت‌هایی دارد و همه‌ی سناریوها مثل مرورگر کاربر تضمین‌شده نیست. ( منبع )

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

Dynamic Rendering دقیقاً چطور کار می‌کند؟

در تعریف رسمی گوگل، داینامیک رندرینگ این‌طور عمل می‌کند: سرور سایت با تشخیص خزنده‌ها (از روی User-Agent یا IP) درخواست را به یک rendering server می‌فرستد تا خروجی HTML رندرشده تولید شود و به خزنده برگردد. بدون اینکه هیچ کد جاوااسکریپتی اجرا شود. اما کاربران عادی یعنی انسان ها مجبورند در مرورگر خود جاوااسکریپت را اجرا کنند. که در حالت پیش فرض و عادی همین اتفاق می افتد.

پس شما عملاً دو مسیر تحویل محتوا دارید:

1. مسیر کاربران: اجرای جاوااسکریپت روی مرورگر به صورت خودکار و سپس نمایش محتوا به کاربر(CSR)
2. مسیر خزنده‌ها: درخواست خزنده گوگل به سرور و گرفتن محتوای صفحه درخواست شده بدون اجرای یک خط کد جاوااسکریپت(SSR)

چرا گوگل دیگر Dynamic Rendering را پیشنهاد نمی‌کند؟

گوگل در مستنداتش با جمله‌ای شفاف، مسیر را عوض کرده: داینامیک رندرینگ «workaround» بوده و «راه‌حل بلندمدت نیست» و جایگزین‌های توصیه‌شده را هم نام می‌برد: SSR، Static Rendering، Hydration. ( منبع )

علت اصلی این تغییر موضع را می‌شود این‌طور خلاصه کرد:

• پیچیدگی عملیاتی بالا: شما یک سیستم اضافه (rendering server / queue / cache) به معماری‌تان تزریق می‌کنید.
• ریسک ناهماهنگی محتوا: اگر نسخه‌ی رندرشده با نسخه‌ی کاربر فرق کند، تبدیل به کلاکینگ می شود.
• هزینه نگهداری: هر تغییر UI/فرانت ممکن است خروجی رندر برای خزنده را هم بهم بزند.
• گزینه‌های بهتر وجود دارد: SSR یا Static Rendering (و گاهی Hydration) هم از نظر سئو و هم از نظر سرعت، معمولا قابل تکیه ترند.

در محتوای آموزشی محسن طاووسی هم روی همین نکته مانور داده شده که داینامیک رندرینگ «عملاً منسوخ شد» و گوگل خودش عقب‌نشینی کرد و دوباره SSR مطلق و فرزندان قدیمی SSR را پیشنهاد داد. فرزندان یعنی Static Rendering و Hydration.( منبع )

Dynamic Rendering با Cloaking فرق دارد یا نه؟

یکی از حساس‌ترین نگرانی‌ها این است: «اگر به ربات‌ها نسخه‌ی متفاوت بدهیم، این کلاکینگ نیست؟»

گوگل می‌گوید: معمولاً داینامیک رندرینگ را کلاکینگ تلقی نمی‌کند، به شرطی که محتوا “مشابه” باشد. اگر به کاربر یک چیز و به خزنده چیز دیگری بدهید (مثلاً موضوع صفحه عوض شود)، آن‌وقت می‌تواند کلاکینگ حساب شود.

جایگزین‌های بهتر از نگاه گوگل و تیم سئو

1) SSR (Server-Side Rendering)

SSR یعنی HTML نهایی همان لحظه روی سرور تولید شود و خزنده در View Source هم محتوای اصلی را ببیند. در منابع محسن طاووسی هم همین تعریف «سئو محور» تاکید شده: معیار شما سورس HTML است که هنوز جاوااسکریپت اجرا نشده است. یعنی Ctrl + U، نه DOM بعد از اجرای جاوااسکریپت.

2) Static Rendering

نسخه‌های HTML از قبل ساخته می‌شوند و با سرعت بالا از CDN سرو می‌شوند. این رویکرد معمولاً هم سئو را ساده‌تر می‌کند و هم پرفورمنس را بهتر. ( منبع )

3) Hydration

صفحه ابتدا با HTML رندرشده می‌آید، بعد JS می‌آید و تعامل‌پذیری را اضافه می‌کند. این یعنی خزنده‌ها (و کاربران با اینترنت ضعیف) حداقل یک خروجی قابل‌خواندن دارند.

چک‌لیست آموزشی برای تشخیص اینکه «Dynamic Rendering دارید یا مشکل رندر دارید»

اگر تیم فنی می‌گوید «همه چیز اوکیه، چون توی Inspect می‌بینیم محتوا هست»، شما باید تست‌هایی انجام دهید که مستقل از DOM باشد:

1. View Source را ببینید: آیا محتوای اصلی در HTML اولیه هست؟ (نه در Inspect یا DOM)
2. URL Inspection در Search Console: خروجی رندر گوگل را با نسخه‌ی واقعی کاربر مقایسه کنید.
3. محتوای کلیدی را “بدون JS” بررسی کنید: اگر JS را خاموش کنید، آیا حداقل متن/لینک‌های اصلی وجود دارند؟ البته مشاهده view-soruce کافی است و نیازی به خاموش کردن جاوااسکریپت مرورگر نیست.
4. مقایسه‌ی خروجی برای User-Agent و IP های مختلف: اگر برای خزنده‌ها HTML متفاوت می‌دهید، باید مطمئن شوید “محتوای اصلی” تغییر نکرده است.
5. از عملکرد صفحات ساخته شده به واسطه فیلتر های جستجوی سایت اطمینان حاصل کنید. همیشه بحث Faceted Navigation با جاوااسکریپت و سئو گره خورده است. منبع نسخه فارسی پیاده سازی Faceted Navigation به شکل سازگار با SEO در این لینک و راهنمای خود گوگل در این باره را در این لینک ببینید.

جمع‌بندی: تصمیم درست برای سئو چیست؟

• داینامیک رندرینگ از نگاه گوگل راهکار موقتی بوده و امروز توصیه‌ی اصلی نیست.
• اگر نمایش محتوای سایت شما نیاز به اجرای جاوااسکریپت روی مرورگر است و محتوای اصلی در HTML اولیه یا Soruce نیست، عملا سایت شما سئو فرندلی نیست و باید به سمت SSR / Static Rendering / Hydration بروید.