هناك تدقيق فني للتحقق من سرعة الموقع وتحديد أسباب التأخير. يوصى بإجراء ذلك حتى لو بدا أن النظام يعمل بشكل صحيح ولا توجد مشكلات في الأداء. الحقيقة هي أنه لا يزال من الممكن تحسينه: سيؤدي تحسين البنية التحتية إلى تسريع تسليم التعليمات البرمجية ، وستساعد إعادة هيكلة قاعدة التعليمات البرمجية في تقليل تكاليف الصيانة.
في هذه المقالة ، سوف نوضح كيف تسير عملية التدقيق الفني لموقع ما على سبيل المثال لمورد إخباري مشهور ، يزوره عشرات الآلاف من المستخدمين في الساعة. دعنا نفكر في المراحل المستقلة للتحقق والتحليل ، ونتيجة لذلك سنظهر بوضوح كيف يمكنك تحسين المشروع والقضاء على الاختناقات التي تبطئ تحميل الصفحة.
مجموعة من المقاييس وتحليل موارد الموقع الثابتة
تأكد من جمع المقاييس وقياس كل شيء يمكنك باستخدام أدوات جاهزة مثل Google Page Speed و Lighthouse و Web.dev. هذه هي أسرع طريقة للحصول على المقاييس التي ستكون بمثابة نقطة انطلاق لبحثك. بمساعدتهم ، ستفهم ما الذي يستحق الانتباه إليه في المقام الأول ، وما الذي يمكن تحسينه.
ننصحك بإجراء التحليل مع تشغيل مانع الإعلانات وإيقاف تشغيله. نتيجةً لذلك ، سوف تكتشف مدى سرعة حدوث العرض الأول للمحتوى ، وعدد البرامج النصية التابعة لجهات خارجية المتصلة بالموقع.
في هذه المرحلة ، سترى أيضًا عدد العمليات الأساسية التي تحدث عند عرض الموقع:
من المحتمل أن تشير المقاييس التي تم جمعها إلى مساحة لتحسين أصول الموقع الثابتة: الصور ومقاطع الفيديو والنصوص والأنماط والخطوط. قم بتحليل هذه البيانات وتأكد من اتباع الممارسات العامة للعمل مع الموارد الثابتة. ومع ذلك ، تذكر أن هذه مجرد إرشادات وليست متطلبات صارمة.
في مثالنا ، يتم تخزين جميع الصور بتنسيق jpg. إذا كنت تستخدم webp ، المدعوم تمامًا بواسطة المتصفحات ، فسيتم تقليل حجم الملف بمعدل 20٪. يمكنك إعداد ضغط صفحات الويب التلقائي للصور عالية الدقة فقط. يوصى بتحويل مقاطع الفيديو عالية الدقة إلى webm للمتصفحات التي تدعم هذا التنسيق. لتقليل الحمل على الشبكة ، يُنصح بتعطيل التشغيل التلقائي لمقاطع الفيديو غير المرئية. يمكن القيام بذلك باستخدام واجهة برمجة تطبيقات Intersection Observer.
تأكد من أن موقعك يحتوي على تنزيلات تدريجية وأضف الضغط في كل مكان إن أمكن. تأكد من استخدام تقنيات ضغط البرنامج النصي الحديثة مثل brotli و gzip و deflate.
لا تقم بتحميل ما لم يتم استخدامه. يمكن أن ينطبق هذا على الكود والأنماط والرموز والصور. إذا كان الموقع ، على سبيل المثال ، يحتوي على زر يظهر في واحدة من آلاف الحالات ، فيجب أن يتم توصيل النص البرمجي الذي يعالج ذلك الزر عند الطلب فقط.
في المثال أعلاه ، يمكنك أن ترى أن 93٪ من إجمالي الشفرة غير مستخدمة (340 كيلوبايت تقريبًا) تعتبر الحزمة التي تحتوي على رمز مثالية إذا كانت تغطيتها 100٪ أثناء تغطية جميع الحالات دون إعادة تحميل الصفحة. يمكن أن يحدث هذا إذا لم يتم استخدام الشفرة على الإطلاق أو إذا تم تكوين تقسيم الشفرة بشكل غير صحيح ، أو تم استخدامه ، ولكن في صفحات أخرى ، أو عند الوصول إلى سيناريو معين.
يتمثل حل هذه المشكلة في نقل المكونات القابلة لإعادة الاستخدام إلى ملفات منفصلة (أجزاء) ، والتي يتم توصيلها بعد ذلك فقط في الأماكن التي تحتاج إليها.
كما قلنا ، هذه المتطلبات اختيارية ، لكن تحسين الموارد الثابتة مهم ، كما يلاحظها المستخدم أولاً.
لنأخذ الخطوط كمثال - في هذا المشروع استغرق تحميلها وقتًا طويلاً. نظرًا لأننا لا نريد أن يرى المستخدم الخطوط القياسية ، فإننا نقوم بتحميلها في البداية ، في قسم css الحرج. كيفية حل هذه المشكلة؟ يمكنك تحسين الخطوط على مستوى الكود ، وتغيير ترتيب الاتصال ، واستبدال ttf بـ woff2.
يمكنك أيضًا محاولة تقليل عدد الخطوط المستخدمة ، مما يستلزم إعادة تصميم التصميم ، لكن هذا ليس مبررًا دائمًا. إذا كان الموقع يستخدم مكتبة Google Fonts ، فقم بإزالة الأحرف غير المستخدمة من الملفات ، فهذا ليس محظورًا بموجب حقوق النشر.
لكن في بعض الأحيان يكون من الأسهل ترك الأشياء كما هي والتركيز على الاحتمالات الأخرى.
فحص طلبات HTTP
في هذه المرحلة ، نتحقق مما إذا كانت الواجهة الأمامية تتفاعل مع النهاية الخلفية بشكل صحيح ، وهي:
- تكوين ضغط لطلبات API ؛
- لا توجد استعلامات طفيلية تقوم بتحميل الاتصال ، ولا يتم استخدام نتائجها في أي مكان ؛
- لا توجد طلبات يتم إرجاعها بخطأ دون إكمال المستخدم لحالة أعمال معينة ؛
- عندما يتم تحميل الصفحة في البداية ، لا يرسل المتصفح طلبات إلى واجهة برمجة التطبيقات (إذا كان الموقع يستخدم عرضًا من جانب الخادم ، كما في مثالنا) ؛
- لا توجد طلبات مكررة. إذا تم تقديم طلب عند الانتقال إلى أي صفحة ، فمن الأفضل إرساله مرة واحدة وحفظ البيانات لإعادة الاستخدام ؛
- pending , . , , , . , — , .
يتم تمييز الطلبات التي تم حظرها باللون الأحمر ، لكن الموقع يستمر في العمل.
أيضًا ، عند تحليل الطلبات ، قد تجد أخطاء. هذه هي الطريقة التي واجهنا بها العملية الخاطئة لتطبيق الواجهة الأمامية ، والتي يمكن أن ترسل أكثر من 100 طلب في الثانية ، مما يؤدي إلى تحميل الخادم بشكل كبير. تومض الشاشة ، ولف اللودر إلى ما لا نهاية ، إلخ. تم إخفاء السبب في لفافة تم تنفيذها بشكل غير صحيح. احتفظ المتصفح بموقعه في أسفل الصفحة عند ظهور عناصر جديدة. أي عند التمرير عبر الصفحة ، تم تشغيل أداة تحميل ، مما أدى إلى دفع الصفحة لأسفل. أعاد معالج Javascript إرسال الطلب ، مما أدى بدوره إلى ظهور الرسوم المتحركة للمحمل مرة أخرى ، بسبب تغيير حجم الصفحة ، وهكذا إلى ما لا نهاية.
نظرًا للتشغيل غير الصحيح للودر ، فإن عدد الطلبات ينمو بلا حدود
تحليل النصوص والموارد الخارجية
في هذه المرحلة ، يجب عليك تحديد الموارد من مواقع الجهات الخارجية التي تستغرق وقتًا أطول للتحميل.
يتيح لك الويب الحديث تحديد أولويات أي تنزيلات. في كثير من الأحيان ، يتم تحميل المقاييس والإعلانات قبل عرض الصفحة ، وهو أمر لا معنى له في حد ذاته ، نظرًا لأن المستخدم سيظل غير قادر على رؤية الإعلان ، لكن الموقع سيستغرق وقتًا أطول للتحميل. نوصي بعرض الإعلانات فور تقديم الموقع ، مما لن يؤثر على الإحصائيات بأي شكل من الأشكال - وإلا سيرى المستخدم شاشة بيضاء لبعض الوقت.
التنميط الصفحات
استخدم أدوات chrome dev لتوصيف صفحات موقعك لتتبع الطلبات الطويلة وزيادة استخدام وحدة المعالجة المركزية. نتيجة لذلك ، سترى بوضوح ما يتم تحميل الموقع.
تُظهر لقطة الشاشة أن تحميل Jquery يستغرق 19 مللي ثانية ، وهو أمر غير مطلوب في الوقت الحالي. من الأفضل تحميل jquery بعد الموارد الرئيسية ، ويفضل أن يكون ذلك بعد حدث تحميل ناجح (مثل onload و domcontentloaded.)
تحليل عدد الطلبات ومدتها
في هذه المرحلة ، سوف نستكشف كيف تتفاعل الواجهة الأمامية مع الواجهة الخلفية. للقيام بذلك ، تحتاج إلى تحليل عدد ومدة جميع الطلبات. للحصول على صورة أكثر اكتمالاً ، تحتاج إلى قياس متوسط وقت الاستجابة لطلب واحد وللطلبات الموازية.
من أجل الوضوح ، ادمج البيانات التي تم الحصول عليها في مخطط ملخص. بهذه الطريقة ، يمكنك تحديد الاستعلامات التي تستغرق وقتًا أطول بكثير من غيرها بسرعة.
إذا تم تثبيت الموقع على خادم قوي ، فيجب ألا يتجاوز وقت تنفيذ 100 طلب متوازي وقت التنفيذ لطلب واحد. في المثال ، نلاحظ فرقًا بمقدار 30 مرة. يجب التحقيق في الاستعلامات الأطول تشغيلًا أولاً.
في هذا المشروع ، بالنسبة لبعض الطلبات ، حدثت مهلة البوابة ، أي أن الاستجابة من الخادم لم تأت على الإطلاق.
النفقات العامة في المشاريع عالية التحميل أمر طبيعي. ولكن كلما أمكن ، يجب أن تحاول تقسيم الطلبات إلى الأجزاء المكونة لها في الحالات التي يكون فيها طلب واحد مسؤولاً عن عدة إجراءات. قم بتنفيذ هذه الأجزاء في خيوط متوازية.
ما الذي يمكن عمله لتحسين الخادم؟ قم بتوصيل المكتبة لمراقبة الخادم وإعادة تشغيل التطبيق (في حالة node.js ، هذا هو pm2). يوصى أيضًا بتوصيل أداة مراقبة الأخطاء مثل Sentry. تكوين إخراج الخطأ وتسجيل إيقاف التشغيل في حالات الطوارئ. بهذه الطريقة يمكنك تتبع وقت توقف التطبيق الخاص بك.
من الناحية المثالية ، قم بإعداد مسجل غير متزامن لمراقبة أي نشاط على الموقع (طلبات API ، طلبات قاعدة البيانات ، واجهات برمجة التطبيقات الخارجية ، إلى نظام الملفات أو الخدمات للعمل مع نظام الملفات) ، والتي ستسجلها في قاعدة بيانات منفصلة.
التحليل الثابت للكود المصدري
يتم تنفيذ هذا التحليل بواسطة الأدوات المساعدة التي ستشير إلى الشفرة الخاطئة وتساعد في التخلص من "الشفرة الميتة". تجدر الإشارة إلى أنه يجب استخدام هذه الأدوات تلقائيًا أثناء التطوير ، ولكن لا يتعين عليك دائمًا الاعتماد على نزاهة المطورين ، لذلك من الأفضل عدم تخطي هذا الفحص.
لإجراء تحليل ثابت ، تحتاج إلى استخدام eslint linters وغيرها من الأدوات المساعدة لتنسيق الكود مثل أجمل وسونار التي تتعقب انتهاكات الكود.
نتيجة لذلك ، بناءً على الانتهاكات المحددة ، يمكنك إعداد مستند:
في العادة ، لا تؤثر مثل هذه الانتهاكات على أداء الموقع ، ولكنها تعقد قراءة وكتابة الكود ، مما يعني أن صيانته سيكون أكثر تكلفة. على سبيل المثال ، في هذا المشروع ، وجدنا وظيفة بها ثلاث حجج ، لم يتم استخدام إحداها - مثل هذه التفاهات مجتمعة تزيد الدين الفني للمشروع.
التحليل الدلالي للكود المصدري
في هذه المرحلة ، سيحتاج المبرمج إلى فحص ملفات المشروع يدويًا. تجدر الإشارة إلى أنه سيكون من الممكن فقط تقييم الأخطاء الواضحة في سلوك الكود المصدري ؛ لإجراء تحليل أعمق ، تحتاج إلى معرفة منطق المشروع جيدًا. في هذه المرحلة ، يمكنك العثور على رمز متكرر يمكن وضعه في مكان واحد (فئة أو دالة أو ثابت) لتقليل عدد الأسطر وتقليل احتمالية ظهور البق.
سيساعد هذا التحليل أحيانًا في تحديد ما إذا كان فريق التطوير يواجه مشكلات. من سطور التعليمات البرمجية من Git ، يمكنك تحديد المؤلف وتحديد أداء الموظفين الفرديين. قد تجد أن أكثر من نصف التعليقات تشير إلى مطور واحد.
على سبيل المثال ، حددنا هنا عشر عمليات غير متزامنة تعمل على تحديث قاعدة البيانات ، ولكن تم إجراؤها واحدة تلو الأخرى ، دون الاتصال ببعضها البعض. هذا يعني أنه يمكن مضاعفة أدائهم عن طريق تشغيلهم بالتوازي.استخدم التوازي كلما أمكن ذلك ، لأنه حتى في إصدارات PHP الحالية ، يمكنك ضبط التوازي الاصطناعي لتحسين أداء النظام.
النتيجة
ينطوي تطوير البرامج على الكثير من المخاطر ، وفي الواقع ، غالبًا ما يتعين عليك تقديم تنازلات من أجل بدء المشروع وتشغيله في الوقت المحدد. لذلك ، عادة ما يتم إعداد الوثائق بأثر رجعي ، ويتم تأجيل تحسين الموقع حتى اللحظة الأخيرة.
ولكن لم يفت الأوان بعد لمعالجة تحسينات الأداء. سيؤدي تسريع موقع الويب الخاص بك إلى تحسين تجربة المستخدم وإعطاء استجابة إيجابية للجمهور. بمساعدة التدقيق الفني ، يمكنك تحديد أسباب التأخير في عمل الموقع - تطبيق الواجهة الأمامية أو الخلفية. تم هنا جمع التوصيات حول كيفية إجراء تدقيق الواجهة الأمامية. فهي عامة في طبيعتها ومناسبة لاختبار أي موقع.
سنخبرك قريبًا بكيفية إجراء تدقيق تقني للخلفية في منشورنا التالي.