فجر تطبيقات SPA ذات الصفحة الواحدة
نمت شعبية نموذج تطبيق الصفحة الواحدة (SPA) على مدار السنوات القليلة الماضية. من المفهوم أن هذا النهج يعطي ربحًا معينًا من حيث السرعة وجودة الخدمة ويخلق الأساس لأنماط جديدة لتطوير الويب للعميل.
كما أعتقد ، يدرك الجميع جيدًا ، يعمل SPA داخل المتصفح ولا يتطلب إعادة تحميل الصفحة أثناء الاستخدام.
فكرة عظيمة! لكن ، بالطبع ، هناك عيوب.
من بين الحالات الأكثر شيوعًا (إذا كنت تأخذ أي برنامج تعليمي حول رد الفعل أو vue) ، تحتوي صفحة index.html الرئيسية على ملف HTML فارغ تقريبًا مع عدد صغير من CSS وجافا سكريبت والخطوط وما إلى ذلك ، وهي عالمية للمشروع بأكمله.
هذه هي المشكلة:
- أثناء العرض الأولي ، سيتعين على المستخدم الانتظار حتى يتم تحميل قاعدة التعليمات البرمجية بالكامل وجميع الموارد (بالطبع ، هناك استثناءات ، ويمكنك تنفيذ التحميل الديناميكي لما يسمى أجزاء js / css ، ولكن هذه قصة أخرى)
- سترى بعض برامج الزحف أو المحللون الذين لا يمكنهم انتظار تحميل الطلبات غير المتزامنة جميع الصفحات فارغة
جيد، لقد وصلتك الفكرة:
<!DOCTYPE html>
<html>
<head>
<title>My first SPA app</title>
<script src="https://cdn__"></script>
</head>
<body>
<div id="app"></div>
<script>
...
,
...
</script>
</body>
</html>
تقديم جانب الخادم SSR
بخلاف عرض جانب العميل (CSR) ، الذي يستخدم المتصفح لعرض كل محتوى التطبيق واسترداد البيانات من واجهات برمجة التطبيقات وما شابه ، يستخدم SSR ... الخادم. أي أن كل نفس العرض واسترجاع البيانات تتم معالجته بواسطة الخادم (NodeJS باستخدام Express أو Next أو Vue SSR أو Nuxt أو أيًا كان ...) ، ثم استجابة بترميز HTML والأنماط والبرامج النصية والبيانات المستلمة من واجهة برمجة التطبيقات ، إرسالها إلى المتصفح.
وبالتالي ، يمكنك الاستفادة من طريقتين: السرعة / تحسين محركات البحث والتفاعل / تجربة المستخدم.
إذن ، ما هو الترطيب / الجفاف؟
معالجة الجفاف هي نوع من الجسور بين SSR و CSR.
يوجد مؤشر لأداء صفحة الويب مثل First Contentful Paint (FCP) - مترجم تقريبًا ، سيبدو مثل "أول عرض مهم" - الوقت الذي بدأ فيه المتصفح في عرض أي نص أو صور (بما في ذلك الخلفية). هذه هي العناصر الأولى التي سيراها المستخدم على الصفحة. عند إنشاء تقرير باستخدام Lighthouse في Chrome ، ضمن علامة تبويب الأداء ، سترى هذا المقياس على الفور.
الوقت المستغرق في إنشاء المحتوى على الخادم سيكون وقت First Contentful Paint.
بعد ذلك مباشرة ، يبدأ JavaScript من جانب العميل في التنفيذ لإنشاء تطبيق عميل كامل (في معظم الحالات ، تكون الأطر الشائعة هي dom الظاهري وواجهة ملزمة لإدارتها).
في هذه المرحلة ، ليست هناك حاجة لإعادة عرض DOM بالكامل على العميل ، ولكن من الضروري إضافة الأحداث والطرق المفقودة ، وفي بعض الحالات ، العناصر التي لم يتم عرضها على الخادم.
هذه هي العملية التي تسمى الترطيب / إعادة الترطيب. يمكن العثور على وصف أكثر تفصيلاً قليلاً في دليل Vue SSR (وهو أيضًا باللغة الروسية) ، ولكن وفقًا لذلك ، مع بعض ميزات هذا الإطار المحدد.
أداء
لكن في هذا الجزء تظهر بعض المشاكل. الجفاف له عيب معين - إنه الوقت قبل التفاعل أو وقت التفاعل ، والذي يمكن رؤيته في نفس الشيء المعروف لنا ، Lighthouse Chrome. حتى إذا قمت بتنظيم كل شيء بشكل مثالي على جانب الخادم وكانت الصفحة تحتوي على أول عرض سريع للمحتوى ، فلن يتمكن المستخدم من التفاعل معها إلا بعد معالجة CSR ، والتي تكون أحيانًا بطيئة جدًا. هذا عيب كبير من حيث UX.
مؤشر آخر على الحد الأقصى المحتمل لتأخير الإدخال الأول هو تأخير الإدخال الأول (FID) - أحد مقاييس أداء صفحة الويب التي تصف الوقت المنقضي منذ أن بدأ المستخدم لأول مرة في التفاعل مع صفحة الويب ، أي ه. النقر فوق ارتباط أو زر أو استخدام عنصر تحكم قائم على JavaScript حتى يتمكن متصفح الويب من الاستجابة للتفاعل (كما هو محدد من موقع mozilla).
ووقت معالجة الجفاف يؤثر بشكل مباشر على هذا المؤشر. وكلما زاد عدد المكونات والمنطق على صفحتك ، زادت سرعة هذا المؤشر.
أحد الحلول هو الحمل البطيء للترطيب.
مثال على تنفيذ نهج مماثل في Vue SSR / NuxtJS هو حزمة vue-lazy-hydration(في مستودع npm) ، والذي يطبق الترطيب فقط في الجزء المرئي من منفذ العرض للمتصفح و "يرطب" الباقي فقط إذا تم تمرير الصفحة. تم العثور أيضًا على توصيات لاستخدام هذه الحزمة على habr في البرنامج التعليمي. أنشأنا متجرًا عبر الإنترنت على Nuxt.js ، والذي قام مؤلفهانطون موسكالشينكوأريد أن أعبر عن امتناني الخاص. في مقالته ، حقق Lighthouse Chrome أداءً بنسبة 100٪.