می‌خوای سرعت بارگذاری صفحات وب سایتت رو بالا ببری؟ پس باید روش رندرینگ درست رو انتخاب کنی. بیا با هم تفاوت بین رندرینگ سمت کلاینت و سمت سرور رو یاد بگیریم تا بتونی تجربه کاربری بهتری رو ارائه بدی.
سرعت بالای بارگذاری صفحات وب سایت نقش مهمی در تجربه کاربری و سئو داره. در واقع، سرعت بارگذاری صفحه یکی از فاکتورهای مهم الگوریتم گوگله.
یه توسعه‌دهنده فرانت‌اند باید بهترین روش رندر کردن وبسایت رو انتخاب کنه تا هم سریع باشه و هم محتوای پویا ارائه بده.
دو تا از روش‌های محبوب رندرینگ، رندرینگ سمت کلاینت (CSR) و رندرینگ سمت سرور (SSR) هستن.
از اونجایی که هر وبسایتی نیازهای متفاوتی داره، درک تفاوت بین رندرینگ سمت کلاینت و سمت سرور می‌تونه کمکت کنه وبسایتت رو طوری رندر کنی که با اهداف کسب و کارت همخونی داشته باشه.
گوگل و جاوااسکریپت
گوگل مستندات گسترده‌ای درباره نحوه برخوردش با جاوااسکریپت داره. کارمندای گوگل هم مرتب از طریق کانال‌های مختلف – چه رسمی و چه غیررسمی – اطلاعات جدید میدن و به سوالات مربوط به جاوااسکریپت جواب میدن.
مثلاً، تو یکی از پادکست های Search Off The Record گفته شد که گوگل همه صفحات رو برای جستجو رندر می‌کنه، حتی اونایی که از جاوااسکریپت سنگین استفاده می‌کنن.
این موضوع باعث شد بحث مفصلی تو لینکدین شکل بگیره و چند تا نکته مهم از این پادکست و بحث‌های بعدش بیرون اومد:
- گوگل پیگیر این نیست که رندر کردن صفحات خاص چقدر براش هزینه‌بر بوده.
- گوگل همه صفحات رو رندر می‌کنه تا محتوا رو ببینه – فرقی نمی‌کنه از جاوااسکریپت استفاده کرده باشن یا نه.
این بحث‌ها کمک کرد خیلی از افسانه‌ها و برداشت‌های غلط درباره اینکه گوگل چطور با جاوااسکریپت برخورد می‌کنه و منابعش رو تخصیص میده، از بین بره.
نظر کامل مارتین اسپلیت تو لینکدین درباره این موضوع این بود:
“ما پیگیر این نیستیم که ‘این صفحه چقدر برامون هزینه داشت؟’ یا چیزی شبیه این. ما می‌دونیم که بخش قابل توجهی از وب از جاوااسکریپت برای اضافه کردن، حذف کردن یا تغییر محتوا تو صفحات وب استفاده می‌کنه. ما فقط باید رندر کنیم تا همه چیز رو ببینیم. واقعاً فرقی نمی‌کنه که یه صفحه از جاوااسکریپت استفاده می‌کنه یا نه، چون ما فقط وقتی می‌تونیم با اطمینان نسبی همه محتوا رو ببینیم که رندر شده باشه.”
مارتین همچنین تأیید کرد که یه صف و تأخیر احتمالی بین خزش و ایندکس شدن وجود داره، اما نه فقط به این دلیل که چیزی جاوااسکریپته یا نه. این یه مسئله “مبهم” نیست که وجود جاوااسکریپت علت اصلی ایندکس نشدن URLها باشه.
بهترین روش‌های کلی برای جاوااسکریپت
قبل از اینکه وارد بحث کلاینت-ساید در مقابل سرور-ساید بشیم، مهمه که بهترین روش‌های کلی رو هم رعایت کنیم تا هر کدوم از این رویکردها درست کار کنن:
- منابع جاوااسکریپت رو از طریق Robots.txt یا قوانین سرور مسدود نکنید.
- از رندر بلاکینگ اجتناب کنید.
- از تزریق جاوااسکریپت در DOM خودداری کنید.
رندرینگ سمت کلاینت چیه و چطور کار می‌کنه؟
رندرینگ سمت کلاینت یه رویکرد نسبتاً جدید برای رندر کردن وبسایت‌هاست.
این روش وقتی محبوب شد که کتابخونه‌های جاوااسکریپت شروع به استفاده ازش کردن. Angular و React.js از بهترین نمونه‌های کتابخونه‌هایی هستن که تو این نوع رندرینگ استفاده میشن.
این روش با رندر کردن جاوااسکریپت وبسایت تو مرورگر شما به جای سرور کار می‌کنه.
سرور به جای اینکه همه محتوا رو از سند HTML بگیره، یه سند HTML ساده با فایل‌های JS میفرسته.
اگرچه زمان آپلود اولیه یکم کنده، اما بارگذاری‌های بعدی صفحه خیلی سریع میشن چون به یه صفحه HTML جداگانه برای هر مسیر نیاز ندارن.
سایت‌هایی که سمت کلاینت رندر میشن همه کار رو “مستقل” انجام میدن، از مدیریت منطق گرفته تا دریافت داده از یه API. صفحه بعد از اجرای کد در دسترس قرار می‌گیره، چون هر صفحه‌ای که کاربر بازدید می‌کنه و URL مربوط به اون به صورت پویا ایجاد میشن.
فرآیند CSR به این صورته:
- کاربر URL مورد نظرش رو تو نوار آدرس وارد می‌کنه.
- یه درخواست داده به سرور تو URL مشخص شده فرستاده میشه.
- تو اولین درخواست کاربر برای سایت، سرور فایل‌های استاتیک (CSS و HTML) رو به مرورگر کاربر تحویل میده.
- مرورگر کاربر اول محتوای HTML رو دانلود می‌کنه، بعدش جاوااسکریپت رو. این فایل‌های HTML جاوااسکریپت رو وصل می‌کنن و فرآیند بارگذاری رو با نمایش نمادهای بارگذاری که توسعه‌دهنده تعریف کرده شروع می‌کنن. تو این مرحله، وبسایت هنوز برای کاربر قابل مشاهده نیست.
- بعد از دانلود جاوااسکریپت، محتوا به صورت پویا روی مرورگر کاربر تولید میشه.
- محتوای وب سایت همینطور که کاربر تو وبسایت می‌گرده و باهاش تعامل می‌کنه قابل مشاهده میشه.
رندرینگ سمت سرور چیه و چطور کار می‌کنه؟
رندرینگ سمت سرور روش رایج‌تری برای نمایش اطلاعات روی صفحه است.
مرورگر وب یه درخواست اطلاعات رو به سرور میفرسته، داده‌های مخصوص کاربر رو می‌گیره تا ازشون استفاده کنه و یه صفحه HTML کاملاً رندر شده رو به کلاینت میفرسته.
هر بار که کاربر یه صفحه جدید تو سایت باز می‌کنه، سرور کل این فرآیند رو تکرار می‌کنه.
فرآیند SSR قدم به قدم به این صورته:
- کاربر URL مورد نظرش رو تو نوار آدرس وارد می‌کنه.
- سرور یه پاسخ HTML آماده رندر شدن رو به مرورگر میفرسته.
- مرورگر صفحه رو رندر می‌کنه (حالا قابل مشاهده است) و جاوااسکریپت رو دانلود می‌کنه.
- مرورگر React رو اجرا می‌کنه و در نتیجه صفحه قابل تعامل میشه.
تفاوت‌های بین رندرینگ سمت کلاینت و سمت سرور چیه؟
تفاوت اصلی بین این دو روش رندرینگ تو الگوریتم عملکردشونه. CSR قبل از بارگذاری یه صفحه خالی نشون میده، در حالی که SSR تو اولین بارگذاری یه صفحه HTML کاملاً رندر شده رو نمایش میده.
این به رندرینگ سمت سرور یه مزیت سرعت نسبت به رندرینگ سمت کلاینت میده، چون مرورگر نیازی به پردازش فایل‌های بزرگ جاوااسکریپت نداره. محتوا اغلب تو چند میلی‌ثانیه قابل مشاهده میشه.
موتورهای جستجو می‌تونن سایت رو برای سئوی بهتر خزش کنن و این باعث میشه ایندکس کردن صفحات وبت راحت‌تر بشه. این خوانایی به شکل متن دقیقاً همون شکلیه که سایت‌های SSR تو مرورگر ظاهر میشن.
با این حال، رندرینگ سمت کلاینت یه گزینه ارزون‌تر برای صاحبان وبسایت‌هاست.
این روش بار رو از روی سرورهات برمی‌داره و مسئولیت رندر کردن رو به کلاینت (بات یا کاربری که می‌خواد صفحه‌ت رو ببینه) منتقل می‌کنه. همچنین بعد از بارگذاری اولیه، تعاملات غنی با سایت رو با ارائه تعامل سریع وبسایت فراهم می‌کنه.
با CSR درخواست‌های HTTP کمتری به سرور فرستاده میشه، برخلاف SSR که هر صفحه از اول رندر میشه و این باعث میشه انتقال بین صفحات کندتر باشه.
SSR هم می‌تونه زیر بار زیاد سرور از کار بیفته، اگه سرور همزمان درخواست‌های زیادی از کاربرهای مختلف دریافت کنه.
نقطه ضعف CSR زمان بارگذاری اولیه طولانی‌تره. این می‌تونه روی سئو تأثیر بذاره؛ خزنده‌ها ممکنه منتظر بارگذاری محتوا نمونن و از سایت خارج بشن.
این رویکرد دو مرحله‌ای احتمال دیدن محتوای خالی تو صفحه‌ت رو بالا می‌بره، چون ممکنه بعد از خزش و ایندکس کردن اولیه HTML یه صفحه، محتوای جاوااسکریپت از دست بره. یادت باشه که تو بیشتر موارد، CSR به یه کتابخونه خارجی نیاز داره.
کی از رندرینگ سمت سرور استفاده کنیم
اگه می‌خوای قابلیت دیده شدن در گوگل رو بهبود بدی و تو صفحات نتایج موتورهای جستجو رتبه بالایی بگیری، رندرینگ سمت سرور انتخاب شماره یکه.
وبسایت‌های آموزش آنلاین، بازارهای آنلاین و برنامه‌هایی که رابط کاربری ساده‌ای با صفحات، ویژگی‌ها و داده‌های پویای کمتری دارن، همه از این نوع رندرینگ سود می‌برن.
کی از رندرینگ سمت کلاینت استفاده کنیم
رندرینگ سمت کلاینت معمولاً با برنامه‌های تحت وب پویا مثل شبکه‌های اجتماعی یا پیام‌رسان‌های آنلاین خوب جفت میشه. دلیلش اینه که اطلاعات این برنامه‌ها دائماً در حال تغییره و باید با داده‌های بزرگ و پویا سر و کار داشته باشن تا بتونن به‌روزرسانی‌های سریعی انجام بدن و نیاز کاربرا رو برآورده کنن.
تمرکز اینجا روی یه سایت غنی با کاربرهای زیاده که تجربه کاربری رو به سئو اولویت میده.
کدوم بهتره: رندرینگ سمت سرور یا سمت کلاینت؟
وقتی می‌خوای تصمیم بگیری کدوم رویکرد بهتره، نه تنها باید نیازهای سئوت رو در نظر بگیری، بلکه باید به این هم فکر کنی که وبسایت چطور برای کاربرا کار می‌کنه و چه ارزشی بهشون میده.
به پروژه‌ت فکر کن و اینکه رندرینگی که انتخاب می‌کنی چه تأثیری روی جایگاهت تو نتایج جستجو و تجربه کاربری وبسایتت میذاره.
به طور کلی، CSR برای وبسایت‌های پویا بهتره، در حالی که SSR برای وبسایت‌های استاتیک مناسب‌تره.
تناوب به‌روزرسانی محتوا
وبسایت‌هایی که اطلاعات خیلی پویایی دارن، مثل سایت‌های شرط‌بندی یا فارکس، هر ثانیه محتواشون رو به‌روز می‌کنن. تو این سناریو احتمالاً CSR رو به SSR ترجیح می‌دی – یا تصمیم می‌گیری بسته به استراتژی جذب کاربرت از CSR فقط برای صفحات فرود خاصی استفاده کنی و نه همه صفحات.
اگه محتوای سایتت به تعامل زیاد کاربر نیاز نداره، SSR مؤثرتره. این روش تأثیر مثبتی روی دسترس‌پذیری، زمان بارگذاری صفحه، سئو و پشتیبانی از شبکه‌های اجتماعی داره.
از طرف دیگه، CSR برای ارائه رندرینگ مقرون به صرفه برای برنامه‌های تحت وب عالیه و ساخت و نگهداریش راحت‌تره. همچنین برای First Input Delay (FID) بهتره.
یه نکته دیگه درباره CSR اینه که متاتگ‌ها (توضیحات، عنوان)، URLهای کانونیکال و تگ‌های Hreflang باید سمت سرور رندر بشن یا تو پاسخ HTML اولیه ارائه بشن تا خزنده‌ها بتونن هر چه سریع‌تر اونا رو شناسایی کنن، نه اینکه فقط تو HTML رندر شده ظاهر بشن.
ملاحظات پلتفرم
فناوری CSR معمولاً نگهداری گرون‌تری داره چون نرخ ساعتی توسعه‌دهنده‌هایی که تو React.js یا Node.js مهارت دارن معمولاً بالاتر از توسعه‌دهنده‌های PHP یا وردپرسه.
علاوه بر این، پلاگین‌های آماده یا راه‌حل‌های از پیش آماده‌ای که برای فریم‌ورک‌های CSR در دسترسه، در مقایسه با اکوسیستم بزرگ‌تر پلاگین‌هایی که کاربرای وردپرس بهش دسترسی دارن، کمتره.
برای اونایی که به فکر راه‌اندازی یه وردپرس هدلس هستن، مثلاً با استفاده از Frontity، مهمه که بدونن باید هم توسعه‌دهنده React.js و هم توسعه‌دهنده PHP استخدام کنن.
دلیلش اینه که وردپرس هدلس برای فرانت‌اند به React.js متکیه در حالی که هنوز برای بک‌اند به PHP نیاز داره.
مهمه که یادت باشه همه پلاگین‌های وردپرس با ست‌آپ‌های هدلس سازگار نیستن و این می‌تونه قابلیت‌ها رو محدود کنه یا نیاز به توسعه سفارشی اضافی داشته باشه.
عملکرد و هدف وبسایت
گاهی اوقات مجبور نیستی بین این دو تا انتخاب کنی چون راه‌حل‌های ترکیبی هم وجود داره. هم SSR و هم CSR رو میشه تو یه وبسایت یا صفحه وب واحد پیاده‌سازی کرد.
مثلاً، تو یه فروشگاه آنلاین، صفحات حاوی توضیحات محصول رو میشه روی سرور رندر کرد، چون استاتیک هستن و باید به راحتی توسط موتورهای جستجو ایندکس بشن.
اگه سطح بالایی از شخصی‌سازی برای کاربرا تو تعدادی از صفحات داری، نمی‌تونی محتوا رو برای بات‌ها SSR رندر کنی. پس باید یه جور محتوای پیش‌فرض برای Googlebot تعریف کنی که بدون کوکی و وضعیت خزش می‌کنه.
صفحاتی مثل حساب‌های کاربری نیازی به رتبه‌بندی تو صفحات نتایج موتورهای جستجو (SERPs) ندارن، پس رویکرد CSR ممکنه برای تجربه کاربری بهتر باشه.
هم CSR و هم SSR رویکردهای محبوبی برای رندر کردن وبسایت‌ها هستن. تو و تیمت باید این تصمیم رو تو مرحله اولیه توسعه محصول بگیرید.
