رندر سمت سرور یک لحظه دارد

چارچوب‌های مبتنی بر React که صفحات وب را بر روی سرور ارائه می‌کنند، می‌توانند به‌طور متناقضی آینده توسعه front-end باشند. در اینجا دلیل است.

امروزه، توسعه front-end و جاوا اسکریپت مترادف هستند. و در حالی که به نظر می رسد یک چارچوب جاوا اسکریپت یا ابزار اکوسیستم داغ، جدید و پیشرفته هر چند ماه یکبار وارد بازار می شود، نویدبخش زمان ساخت سریعتر یا تجربه کاربر نهایی سریعتر است، چارچوب های React ساده و مبتنی بر React مانند Next.js همچنان تسلط دارند. وقتی به چارچوب‌های واسط کاربری مرورگر که توسط مشتریان Sentry استفاده می‌شود نگاه می‌کنیم، جای تعجب نیست که اکوسیستم React به میزان زیادی پیشرو است.

در Sentry، ما هم به معیارهای صنعت و هم به داده‌های پذیرش SDK داخلی خود نگاه می‌کنیم تا تصمیم بگیریم در کدام چارچوب سرمایه‌گذاری کنیم. ما داده های زیادی داریم که به ما می گوید توسعه دهندگان چه می خواهند.

در این مقاله، ما از این داده‌ها استفاده می‌کنیم تا روندهای جالبی را در مورد اینکه فریم‌ورک‌های فرانت‌اند به کجا هدایت می‌شوند، و چرا فکر می‌کنیم چارچوب‌های مبتنی بر React مانند Next.js – چارچوب‌هایی که رندر کردن صفحات وب را آسان می‌کنند، شناسایی می‌کنیم. سرور—به طور متناقضی می تواند آینده توسعه front-end باشد.

«Plain» React سرنخ‌ها… در حال حاضر

React ایجاد رابط‌های کاربری پویا را سریع و نسبتاً آسان می‌کند و دستکاری دستی DOM را دور از چشم و دور از ذهن می‌گذارد. در حالی که توسعه دهندگان React ممکن است زمان زیادی را برای رفع اشکال از کتابخانه اصلی React صرف نکنند، خطاها همچنان رخ می دهد. و از آنجایی که Sentry به کاربران خود “زمان، چه، و چرا” پشت خطاهای برنامه را می گوید، می توانیم تعداد دفعات وقوع خطاهای پروژه مبتنی بر React را اندازه گیری کنیم.

به غیر از خطاها، نمی توان انکار کرد که React به چارچوب جاوا اسکریپت تبدیل شده است. یکی از دلایل محبوب شدن React این است که توسعه دهندگان به راحتی می توانند رابط کاربری پویا را در مرورگر بسازند. اما نوآوری جاوا اسکریپت انجام نشده است.

قابلیت‌های رندر سمت سرور (SSR) به سرعت به یکی از ویژگی‌های برجسته‌تر چارچوب‌های جاوا اسکریپت تبدیل می‌شوند. SSR جدید نیست (به عنوان مثال PHP، Ruby، و غیره)، و همچنین SSR توسط جاوا اسکریپت (Node.js) پشتیبانی نمی شود. چیز جدیدی که وجود دارد این است که چارچوب‌های در حال ظهور، استفاده از ابزارهایی را که برای ایجاد تجربه‌های سمت سرویس گیرنده استفاده می‌کنند، مانند React، برای توسعه‌دهندگان جلویی آسان می‌کنند و از آن‌ها به طور مؤثر برای ارائه محتوا در سرور استفاده می‌کنند.

فریم‌ورک‌های دارای قابلیت SSR مانند Next.js که در بالای React قرار می‌گیرد، به توسعه‌دهندگان اجازه می‌دهد که React را همانطور که قبلاً می‌نوشتند بنویسند، اما این فریم ورک به هر دوی اینها کمک می‌کند که در ابتدا آن محتوا را در سرور ارائه کنند. و در بخش‌های «هیدرات کردن مجدد» رابط کاربری مشتری پس از بارگیری در مرورگر.

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

با بازگرداندن آن به کاربر نهایی، رندر سمت سرور یک مزیت بزرگ نسبت به چارچوب‌های رندر سمت مشتری (CSR) ارائه می‌کند: ارائه محتوای آماده به مرور، سریع‌تر. و زمانی که همه ما در سطح توجه ماهی قرمز هستیم، نیم ثانیه بیشتر منتظر ماندن با بارگیری صفحه می تواند تفاوت بین کاربرانی باشد که سبد خرید خود را رها می کنند و چک می کنند. شایان ذکر است که SSR می تواند به SEO نیز کمک کند، اما ابتدا، بیایید روی سرعت تمرکز کنیم.

SSR منجر به وب سریعتر می شود

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

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

رندر سمت سرور با Next.js برای بهبود عملکرد درک شده برنامه شما عالی است، اما مراقب هزینه هیدراتاسیون در رشته JS خود باشید. صفحه شما می تواند سریع به نظر برسد، اما زمان بیشتری صرف می شود تا کاربر واقعاً قابل استفاده باشد.

– بن زوهر، مهندس نرم‌افزار Sr. Arcade

از کجا بفهمیم توسعه دهندگانی که از SSR استفاده می کنند به سرعت اهمیت می دهند؟ در نظر بگیرید که کاربران Sentry می توانند عملکرد برنامه را با ارسال داده های تراکنش به Sentry نظارت کنند. ما منطقاً انتظار داریم که اگر کاربران Sentry که برنامه‌هایی با چارچوب‌های SSR می‌سازند به عملکرد اهمیت دهند، شاهد فعالیت بیشتری از آن پروژه‌ها باشیم.

نمودار سمت چپ نشان می‌دهد که چه درصدی از سازمان‌ها (با نام مستعار حساب‌های Sentry) با یک پروژه CSR یا SSR اصلی نصب شده، بر عملکرد نظارت می‌کنند (معروف به ارسال تراکنش‌ها به Sentry). برای چارچوب‌های CSR، مظنون‌های معمول را شامل می‌کنیم: React، Vue، Ember و Angular. برای دسته بندی SSR، Svelte، Remix و Next.js را در نظر گرفتیم. با توجه به نظارت ۹۱ درصدی پروژه‌های SSR بر عملکرد و ۸۱ درصد از پروژه‌های CSR که بر عملکرد نظارت می‌کنند، نمی‌توان گفت که توسعه‌دهندگانی که از چارچوب‌های دارای SSR استفاده می‌کنند، توجه بیشتری به عملکرد برنامه‌های خود دارند.

در Sentry، Next.js مورد علاقه طرفداران – که تمرکز زیادی بر SSR دارد – به‌سرعت به عنوان دومین فریم‌ورک محبوب‌ترین فریم‌اند پس از برنامه‌های سنتی React CSR در حال ظهور است. با توجه به تمرکز چارچوب بر عملکرد و تجربه توسعه‌دهنده، این تعجبی ندارد. این تمرکز روی عملکرد احتمالاً دلیلی است که ما شاهد رشد تعداد پروژه‌های Next.js بوده‌ایم که سالانه ۲۴۰٪ در سال در Sentry عظیم رشد کرده است.

بهینه سازی برای SEO

از آنجایی که Google می‌خواهد کاربران را به صفحاتی بفرستد که سریع بارگیری می‌شوند (معروف به توپ‌های ساحلی بدون چرخش)، صفحاتی که سریع‌تر بارگذاری می‌شوند در نتایج جستجوی ارگانیک رتبه بالاتری دارند. بهبود سرعت بارگذاری صفحه یک مزیت بزرگ SEO برای چارچوب‌های SSR است، اما چیزی بیش از سرعت بارگذاری صفحه وجود دارد که SSR را بهتر از CSR برای SEO می‌کند.

وقتی خزنده وب Google (با نام مستعار Googlebot) تصمیم می‌گیرد چه چیزی را در نتایج جستجو نشان دهد، HTML یک صفحه را فهرست می‌کند و زمانی که Google منابع محاسباتی در دسترس دارد، آن را در جاوا اسکریپت ارائه می‌کند. اگر از CSR استفاده می‌کنید، این بخش «وقتی منابع در دسترس هستند» به این معنی است که برای ارائه وب‌سایت خود به Googlebot وابسته هستید. با SSR، Google صفحات کاملاً رندر شده را می‌خزد تا تمام محتوای شما فهرست شود. نسخه TLDR: SSR به Googlebot اجازه می‌دهد تا همه محتوای شما را سریع‌تر در نظر بگیرد، بنابراین شانس بیشتری برای نمایش در نتایج جستجو دارید.

ما در نهایت تصمیم گرفتیم که رندر سمت سرور بهترین پایگاه کد را برای موفقیت در سئو ایجاد کند. و Next.js را به عنوان چارچوبی برای تسهیل آن انتخاب کنید.

– ریچل چرچ، مهندس نرم افزار، Airtable

آیا این پایان CSR است؟

برای فریم‌ورک‌های فرانت‌اند یک اندازه مناسب وجود ندارد. از آنجایی که CSR و SSR نیازهای متفاوتی را برطرف می کنند، انتظار نداریم به این زودی شاهد ناپدید شدن هر یک از آنها باشیم. اما همانطور که توسعه‌دهندگان به دنبال راه‌هایی برای سریع‌تر کردن برنامه‌های خود هستند، معتقدیم چارچوب‌هایی که SSR را آسان می‌کنند (مانند Next.js) همچنان مورد توجه قرار خواهند گرفت.

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

مهم نیست که چه نوع برنامه وب را می سازید، چارچوب ها و ابزارهای وب جدید ایجاد محتوای پویا را آسان تر می کنند. و با توجه به هزینه رو به کاهش قدرت محاسباتی (از ارائه دهندگان خدمات ابری متشکریم)، ​​آینده چارچوب هایی که SSR را آسان تر می کنند، مانند Next.js، روشن به نظر می رسد.

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

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.