من جانب العميل مقابل جانب الخادم مقابل العرض المسبق لتطبيقات الويب

هناك شيء ما يحدث داخل مجتمع الواجهة الأمامية مؤخرًا. يحظى العرض من جانب الخادم بمزيد من الجذب بفضل React وميزة الترطيب المدمجة في جانب الخادم. لكنه ليس الحل الوحيد لتقديم تجربة سريعة للمستخدم مع درجة فائقة السرعة من الوقت إلى البايت الأول (TTFB): يعد العرض المسبق أيضًا إستراتيجية جيدة جدًا. ما الفرق بين هذه الحلول والتطبيق المقدم من العميل بالكامل؟

التطبيق المقدم من العميل

نظرًا لوجود أطر عمل مثل Angular و Ember.js و Backbone ، فإن مطوري الواجهة الأمامية يميلون إلى تقديم كل شيء إلى جانب العميل. بفضل Google وقدرتها على "قراءة" JavaScript ، فإنها تعمل بشكل جيد ، كما أنها صديقة لتحسين محركات البحث.

باستخدام حل التقديم من جانب العميل ، يمكنك إعادة توجيه الطلب إلى ملف HTML واحد وسيقوم الخادم بتسليمه بدون أي محتوى (أو مع شاشة تحميل) حتى تقوم بإحضار كل JavaScript والسماح للمتصفح بترجمة كل شيء قبل عرض المحتوى.

في ظل اتصال إنترنت جيد وموثوق ، فهو سريع جدًا ويعمل بشكل جيد. ولكن يمكن أن يكون أفضل بكثير ، ولا يجب أن يكون من الصعب القيام بذلك على هذا النحو. هذا ما سنراه في الأقسام التالية.

العرض من جانب الخادم (SSR)

حل SSR هو شيء اعتدنا القيام به كثيرًا ، منذ سنوات عديدة ، لكننا نميل إلى نسيانه لصالح حل التقديم من جانب العميل.

باستخدام حلول العرض القديمة من جانب الخادم ، قمت بإنشاء صفحة ويب - باستخدام PHP على سبيل المثال - قام الخادم بتجميع كل شيء ، وتضمين البيانات ، وتسليم صفحة HTML ممتلئة بالكامل إلى العميل. كانت سريعة وفعالة.

لكن ... في كل مرة تقوم فيها بالانتقال إلى مسار آخر ، كان على الخادم أن يقوم بالعمل مرة أخرى: احصل على ملف PHP ، وقم بترجمته ، وقم بتسليم HTML ، مع تأخير جميع CSS و JS لتحميل الصفحة إلى بضع مئات من مللي ثانية أو حتى ثواني كاملة.

ماذا لو كان بإمكانك تحميل الصفحة الأولى باستخدام حل SSR ، ثم استخدام إطار عمل للقيام بالتوجيه الديناميكي باستخدام AJAX ، مع جلب البيانات الضرورية فقط؟

هذا هو سبب حصول SSR على المزيد والمزيد من الجاذبية داخل المجتمع لأن React قامت بنشر هذه المشكلة بحل سهل الاستخدام: طريقة RenderToString .

يسمى هذا النوع الجديد من تطبيقات الويب تطبيقًا عالميًا أو تطبيقًا متماثلًا . لا يزال هناك بعض الجدل حول المعاني الدقيقة لهذه المصطلحات والعلاقة بينها ، لكن الكثير من الناس يستخدمونها بالتبادل.

على أي حال ، تتمثل ميزة هذا الحل في القدرة على تطوير جانب خادم التطبيق وجانب العميل بنفس الكود وتقديم تجربة سريعة حقًا للمستخدم ببيانات مخصصة. العيب هو أنك تحتاج إلى تشغيل الخادم.

يستخدم SSR لجلب البيانات وملء الصفحة مسبقًا بمحتوى مخصص ، مما يعزز اتصال الإنترنت الموثوق به للخادم. وهذا يعني أن اتصال الإنترنت الخاص بالخادم أفضل من اتصال مستخدم لديه الكذب فاي) ، لذلك فهو قادر على الجلب المسبق للبيانات ودمجها قبل تسليمها إلى المستخدم.

باستخدام البيانات التي تم تعبئتها مسبقًا ، يمكن أن يؤدي استخدام تطبيق SSR أيضًا إلى إصلاح مشكلة تواجهها التطبيقات التي يقدمها العميل مع المشاركة الاجتماعية ونظام OpenGraph. على سبيل المثال ، إذا كان لديك ملف index.html واحد لتسليمه إلى العميل ، فسيكون لديه نوع واحد فقط من البيانات الوصفية - على الأرجح البيانات الوصفية لصفحتك الرئيسية. لن يتم تحديد هذا السياق عندما تريد مشاركة مسار مختلف ، لذلك لن يتم عرض أي من مساراتك على مواقع أخرى مع محتوى المستخدم المناسب (الوصف وصورة المعاينة) التي قد يرغب المستخدمون في مشاركتها مع العالم.

التقديم المسبق

يمكن أن يكون الخادم الإلزامي لتطبيق عالمي رادعًا للبعض وقد يكون مبالغة في استخدام تطبيق صغير. هذا هو السبب في أن العرض المسبق يمكن أن يكون بديلاً رائعًا حقًا.

لقد اكتشفت هذا الحل باستخدام Preact و CLI الخاص به والذي يسمح لك بتجميع جميع المسارات المحددة مسبقًا حتى تتمكن من تخزين ملف HTML ممتلئ بالكامل على خادم ثابت . يتيح لك ذلك تقديم تجربة فائقة السرعة للمستخدم ، بفضل وظيفة الترطيب Preact / React ، دون الحاجة إلى Node.js.

المهم هو ، نظرًا لأن هذا ليس SSR ، ليس لديك بيانات خاصة بالمستخدم لإظهارها في هذه المرحلة - إنه مجرد ملف ثابت (وعام إلى حد ما) يتم إرساله مباشرة عند الطلب الأول ، كما هو. لذلك إذا كانت لديك بيانات خاصة بالمستخدم ، فإليك المكان الذي يمكنك فيه دمج هيكل عظمي مصمم بشكل جميل لإظهار وصول بيانات المستخدم ، لتجنب بعض الإحباط من جانبهم:

هناك مشكلة أخرى: لكي تعمل هذه التقنية ، ما زلت بحاجة إلى وكيل أو شيء ما لإعادة توجيه المستخدم إلى الملف الصحيح.

لماذا ا؟

باستخدام تطبيق أحادي الصفحة ، تحتاج إلى إعادة توجيه جميع الطلبات إلى الملف الجذر ، ثم يقوم إطار العمل بإعادة توجيه المستخدم باستخدام نظام التوجيه المدمج الخاص به. لذلك يكون تحميل الصفحة الأولى دائمًا هو نفس ملف الجذر.

لكي يعمل حل العرض المسبق ، يجب أن تخبر الوكيل أن بعض المسارات تحتاج إلى ملفات معينة وليس دائمًا ملف index.html الجذر.

على سبيل المثال ، لنفترض أن لديك أربعة مسارات ( / ، /about ، /jobs ، blog ) وكلها لها تخطيطات مختلفة. أنت بحاجة إلى أربعة ملفات HTML مختلفة لتسليم الهيكل العظمي للمستخدم الذي سيسمح بعد ذلك لـ React / Preact / إلخ. ترطيبها بالبيانات. لذلك إذا قمت بإعادة توجيه كل هذه المسارات إلى ملف index.html الجذر ، فستشعرك الصفحة بشعور غير سار أثناء التحميل ، حيث سيرى المستخدم الهيكل العظمي للصفحة الخطأ حتى ينتهي التحميل ويحل محل التخطيط. على سبيل المثال ، قد يرى المستخدم هيكلًا عظميًا للصفحة الرئيسية به عمود واحد فقط ، عندما يطلبون صفحة مختلفة بمعرض يشبه Pinterest.

الحل هو إخبار وكيلك بأن كل مسار من هذه المسارات الأربعة يحتاج إلى ملف معين:

• https://my-website.com → إعادة التوجيه إلى ملف index.html الجذر
• https://my-website.com/about → أعد التوجيه إلى ملف /about/index.html
• https://my-website.com/jobs → أعد التوجيه إلى ملف /jobs/index.html
• https://my-website.com/blog → أعد التوجيه إلى ملف /blog/index.html

هذا هو السبب في أن هذا الحل يمكن أن يكون مفيدًا للتطبيقات الصغيرة - يمكنك أن ترى كم سيكون الأمر مؤلمًا إذا كان لديك بضع مئات من الصفحات.

بالمعنى الدقيق للكلمة ، ليس من الضروري القيام بذلك بهذه الطريقة - يمكنك فقط استخدام ملف ثابت مباشرة. على سبيل المثال ، سيعمل https://my-website.com/about/ دون أي إعادة توجيه لأنه سيبحث تلقائيًا عن index.html داخل دليله. لكنك تحتاج إلى هذا الوكيل إذا كان لديك عناوين url للمعلمات - سيحتاج https://my-website.com/profile/guillaume إلى إعادة توجيه الطلب إلى /profile/index.html بتخطيطه الخاص ، لأن profile/guillaume/index.html غير موجود وسيؤدي إلى ظهور خطأ 404.

باختصار ، هناك ثلاث طرق عرض أساسية تعمل مع استراتيجيات العرض الموضحة أعلاه: شاشة تحميل ، وهيكل عظمي ، والصفحة الكاملة بمجرد عرضها أخيرًا.

اعتمادًا على الإستراتيجية ، نستخدم أحيانًا جميع طرق العرض الثلاثة هذه ، وأحيانًا ننتقل مباشرةً إلى صفحة كاملة العرض. في حالة استخدام واحدة فقط ، نضطر إلى استخدام نهج مختلف:

غالبًا ما يكون العرض الخاص بالعميل فقط غير كافٍ

التطبيقات التي يقدمها العميل هي شيء يجب أن نتجنبه الآن لأنه يمكننا تحسين أداء المستخدم. والقيام بعمل أفضل ، في هذه الحالة ، يكون سهلاً مثل حل العرض المسبق. إنه بالتأكيد تحسين على العرض الخاص بالعميل فقط وأسهل في التنفيذ من تطبيق يتم عرضه بالكامل من جانب الخادم.

يمكن أن يكون التطبيق العام / SSR قويًا حقًا إذا كان لديك تطبيق كبير به الكثير من الصفحات المختلفة. يسمح للمحتوى الخاص بك أن يكون مركزًا وملائمًا عند التحدث إلى الزاحف الاجتماعي. ينطبق هذا أيضًا على روبوتات محركات البحث ، والتي تأخذ الآن أداء موقعك في الاعتبار عند ترتيبه.

ترقبوا برنامجًا تعليميًا للمتابعة ، حيث سأستعرض عملية تحويل SPA إلى إصدارات معروضة مسبقًا و SSR ، وأقارن بين أدائهم.