رندر سمت مشتری از HTML و تعامل

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

Jeremy Wagner

تجزیه و رندر HTML چیزی است که مرورگرها به‌طور پیش‌فرض برای وب‌سایت‌هایی که از منطق ناوبری داخلی مرورگر استفاده می‌کنند، به خوبی انجام می‌دهند – که گاهی اوقات «بارگذاری صفحه سنتی» یا «ناوبری سخت» نامیده می‌شود. چنین وب سایت هایی گاهی اوقات برنامه های چند صفحه ای (MPA) نامیده می شوند.

با این حال، توسعه‌دهندگان ممکن است روی پیش‌فرض‌های مرورگر کار کنند تا مطابق با نیازهای برنامه‌شان باشد. مطمئناً این مورد برای وب‌سایت‌هایی است که از الگوی برنامه تک صفحه‌ای (SPA) استفاده می‌کنند، که به صورت پویا بخش‌های بزرگی از HTML/DOM را با جاوا اسکریپت روی مشتری ایجاد می‌کند. رندر سمت مشتری نام این الگوی طراحی است، و اگر کار بیش از حد انجام شود، می‌تواند بر روی تعامل وب‌سایت شما با رنگ بعدی (INP) تأثیر بگذارد.

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

چگونه مرورگر HTML ارائه شده توسط سرور را رندر می کند

الگوی ناوبری مورد استفاده در بارگیری صفحات سنتی شامل دریافت HTML از سرور در هر مسیریابی است. اگر یک URL را در نوار آدرس مرورگر خود وارد کنید یا روی پیوندی در MPA کلیک کنید، مجموعه ای از رویدادها رخ می دهد:

1. مرورگر یک درخواست ناوبری برای URL ارائه شده ارسال می کند.
2. سرور با HTML در تکه ها پاسخ می دهد.

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

تجزیه و رندر HTML ارائه شده توسط سرور همانطور که در پانل عملکرد Chrome DevTools تجسم شده است. وظایف مربوط به تجزیه HTML و رندر کردن آن به قطعات تقسیم می شوند.

مانند بسیاری از چیزهایی که در مرورگر اتفاق می‌افتد، تجزیه HTML در وظایف انجام می‌شود. هنگامی که HTML از سرور به مرورگر پخش می شود، مرورگر تجزیه آن HTML را با انجام این کار به صورت تکه تکه در زمانی که بیت های آن جریان به صورت تکه تکه می رسد، بهینه می کند. نتیجه این است که مرورگر پس از پردازش هر تکه به صورت دوره ای به رشته اصلی تسلیم می شود، که از انجام کارهای طولانی جلوگیری می کند. این بدان معناست که کارهای دیگری در حین تجزیه HTML ممکن است رخ دهد، از جمله کار رندر افزایشی لازم برای ارائه یک صفحه به کاربر، و همچنین پردازش تعاملات کاربر که ممکن است در طول دوره راه اندازی بسیار مهم صفحه رخ دهد. این رویکرد به امتیاز بهتری از Interaction to Next Paint (INP) برای صفحه تبدیل می‌شود.

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

چگونه مرورگر HTML ارائه شده توسط جاوا اسکریپت را رندر می کند

در حالی که هر درخواست ناوبری به یک صفحه نیاز به مقداری HTML دارد که توسط سرور ارائه شود، برخی از وب سایت ها از الگوی SPA استفاده می کنند. این رویکرد اغلب شامل حداقل بار اولیه HTML است که توسط سرور ارائه می شود، اما سپس مشتری منطقه محتوای اصلی یک صفحه را با HTML جمع آوری شده از داده های واکشی شده از سرور پر می کند. پیمایش های بعدی - که در این مورد گاهی اوقات به عنوان "ناوبری نرم" شناخته می شود - به طور کامل توسط جاوا اسکریپت انجام می شود تا صفحه با HTML جدید پر شود.

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

چند راه متداول برای ایجاد HTML یا افزودن به DOM از طریق جاوا اسکریپت وجود دارد:

1. ویژگی innerHTML به شما این امکان را می دهد که محتوا را روی یک عنصر موجود از طریق یک رشته تنظیم کنید که مرورگر آن را به DOM تجزیه می کند.
2. متد document.createElement به شما امکان می دهد بدون استفاده از تجزیه HTML مرورگر، عناصر جدیدی ایجاد کنید تا به DOM اضافه شوند.
3. متد document.write به شما امکان می دهد HTML را در سند بنویسید (و مرورگر آن را تجزیه می کند، درست مانند روش شماره 1). با این حال، به دلایل متعددی ، استفاده از document.write به شدت ممنوع است.

تجزیه و رندر HTML از طریق جاوا اسکریپت بر روی کلاینت همانطور که در پانل عملکرد Chrome DevTools تجسم شده است. وظایف مربوط به تجزیه و رندر کردن آن تکه تکه نمی شود، در نتیجه یک کار طولانی است که رشته اصلی را مسدود می کند.

عواقب ایجاد HTML/DOM از طریق جاوا اسکریپت سمت سرویس گیرنده می تواند قابل توجه باشد:

• برخلاف HTML که توسط سرور در پاسخ به درخواست ناوبری پخش می شود، وظایف جاوا اسکریپت روی کلاینت به طور خودکار تکه تکه نمی شوند، که ممکن است منجر به کارهای طولانی شود که رشته اصلی را مسدود می کند. این به این معنی است که اگر HTML/DOM بیش از حد در یک زمان روی مشتری ایجاد می‌کنید، INP صفحه شما می‌تواند تأثیر منفی بگذارد.
• اگر HTML در هنگام راه‌اندازی روی کلاینت ایجاد شود، منابع ارجاع‌شده در آن توسط اسکنر پیش‌بارگذاری مرورگر کشف نمی‌شوند . این مطمئناً تأثیر منفی بر بزرگترین رنگ محتوای صفحه (LCP) خواهد داشت. در حالی که این یک مشکل عملکرد زمان اجرا نیست (به جای آن مشکل تاخیر شبکه در واکشی منابع مهم است)، شما نمی خواهید LCP وب سایت شما با کنار گذاشتن این بهینه سازی عملکرد اساسی مرورگر تحت تأثیر قرار گیرد.

آنچه می توانید در مورد تأثیر عملکرد رندر سمت مشتری انجام دهید

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

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

تا حد امکان HTML را از سرور ارائه دهید

همانطور که قبلا ذکر شد، مرورگر به طور پیش فرض HTML را از سرور به روشی بسیار کارآمد مدیریت می کند. تجزیه و رندر HTML را به گونه ای تجزیه می کند که از انجام کارهای طولانی جلوگیری می کند و مقدار کل زمان موضوع اصلی را بهینه می کند. این منجر به کاهش زمان مسدود کردن کل (TBT) می شود و TBT به شدت با INP همبستگی دارد.

ممکن است برای ساخت وب سایت خود به یک فریمورک frontend متکی باشید. اگر چنین است، باید مطمئن شوید که جزء HTML را روی سرور رندر می کنید. این مقدار رندر اولیه وب سایت شما را محدود می کند و باید به تجربه بهتری منجر شود.

• برای React، باید از Server DOM API برای رندر HTML روی سرور استفاده کنید. اما توجه داشته باشید: روش سنتی رندر سمت سرور از یک رویکرد همزمان استفاده می‌کند که می‌تواند منجر به طولانی‌تر شدن زمان تا اولین بایت (TTFB) و همچنین معیارهای بعدی مانند First Contentful Paint (FCP) و LCP شود. در صورت امکان، مطمئن شوید که از API های جریان برای Node.js یا سایر زمان های اجرا جاوا اسکریپت استفاده می کنید تا سرور بتواند در اسرع وقت شروع به پخش HTML به مرورگر کند. Next.js – یک چارچوب مبتنی بر React – به‌طور پیش‌فرض بهترین روش‌ها را ارائه می‌کند. علاوه بر رندر خودکار HTML در سرور، همچنین می تواند به صورت ایستا HTML برای صفحاتی که بر اساس زمینه کاربر تغییر نمی کنند (مانند احراز هویت) ایجاد کند.
• Vue همچنین به صورت پیش فرض رندر سمت کلاینت را انجام می دهد. با این حال، مانند React، Vue همچنین می‌تواند کامپوننت شما را HTML بر روی سرور رندر کند . یا در صورت امکان از این API های سمت سرور استفاده کنید، یا یک انتزاع سطح بالاتر برای پروژه Vue خود در نظر بگیرید تا بهترین روش ها را برای پیاده سازی آسان تر کنید.
• Svelte به طور پیش‌فرض HTML را بر روی سرور ارائه می‌کند - اگرچه اگر کد مؤلفه شما نیاز به دسترسی به فضاهای نام اختصاصی مرورگر دارد (برای مثال window )، ممکن است نتوانید HTML آن مؤلفه را در سرور رندر کنید. تا جایی که ممکن است رویکردهای جایگزین را بررسی کنید تا باعث رندر غیرضروری در سمت مشتری نشوید. SvelteKit - که برای Svelte مانند Next.js برای React است - تا حد امکان بهترین روش‌ها را در پروژه‌های Svelte شما تعبیه می‌کند، بنابراین می‌توانید از مشکلات احتمالی در پروژه‌هایی که به تنهایی از Svelte استفاده می‌کنند جلوگیری کنید.

نکته کلیدی: اگر برنامه شما از یکی از این فریم ورک ها استفاده می کند و نیاز به تعامل با مشتری دارد، همچنان باید اجزای خود را روی کلاینت هیدراته کنید تا تعاملی باشند. برای یک ارزیابی جامع از رویکردهای مختلف برای رندر HTML، و برای برخی توصیه‌ها در مورد نحوه مدیریت هیدراتاسیون مؤلفه در مشتری با در نظر گرفتن عملکرد، Rendering در وب را بخوانید.

تعداد گره های DOM ایجاد شده روی مشتری را محدود کنید

هنگامی که DOM ها بزرگ هستند، پردازش مورد نیاز برای ارائه آنها افزایش می یابد. چه وب سایت شما یک SPA تمام عیار باشد، چه در حال تزریق گره های جدید به DOM موجود در نتیجه تعامل برای MPA باشد، در نظر بگیرید که آن DOM ها را تا حد امکان کوچک نگه دارید. این کار به کاهش کار مورد نیاز در حین رندر سمت مشتری برای نمایش آن HTML کمک می کند، امیدواریم به پایین نگه داشتن INP وب سایت شما کمک کند.

برای کسب اطلاعات بیشتر بخوانید: اندازه DOM و تعامل .

معماری کارگر سرویس استریم را در نظر بگیرید

این یک تکنیک پیشرفته است - تکنیکی که ممکن است به راحتی با هر موردی کار نکند - اما تکنیکی است که می تواند MPA شما را به وب سایتی تبدیل کند که وقتی کاربران از صفحه ای به صفحه دیگر حرکت می کنند، احساس می شود فورا بارگذاری می شود. می توانید از یک سرویس دهنده برای پیش کش کردن قسمت های ثابت وب سایت خود در CacheStorage استفاده کنید، در حالی که از ReadableStream API برای واکشی بقیه HTML صفحه از سرور استفاده می کنید.

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

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

نتیجه

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

رندر HTML سمت کلاینت تعدادی از مشکلات عملکرد بالقوه را معرفی می کند که در بسیاری از موارد قابل اجتناب هستند. با توجه به الزامات هر وب سایت، 100٪ مواقع کاملاً قابل اجتناب نیست. برای کاهش وظایف طولانی بالقوه ای که می تواند ناشی از رندر بیش از حد از سایت مشتری باشد، مطمئن شوید که هر زمان ممکن است HTML وب سایت خود را از سرور ارسال می کنید. مشتری، و معماری های جایگزین را برای سرعت بخشیدن به تحویل HTML به مشتری در نظر بگیرید و در عین حال از تجزیه و تحلیل تدریجی و رندر مرورگر برای HTML بارگیری شده از سرور نیز بهره ببرید.

اگر بتوانید رندر سمت مشتری وب سایت خود را به حداقل ممکن برسانید، نه تنها INP وب سایت خود را بهبود می بخشید، بلکه معیارهای دیگر مانند LCP، TBT و احتمالاً حتی TTFB خود را در برخی موارد بهبود می بخشید.

تصویر قهرمان از Unsplash , توسط Maik Jonietz .