في مؤتمر Google IO لعام 2018، قدّمنا مجموعة من الأدوات والمكتبات وأساليب التحسين التي تسهّل تحسين أداء الويب. سنوضّح هذه الميزات باستخدام تطبيق Oodles Theater، ونتحدث أيضًا عن تجاربنا مع التحميل التوقّعي ومبادرة Guess.js الجديدة.
لقد كنا مشغولين جدًا خلال العام الماضي في محاولة معرفة كيفية جعل الويب أسرع و أكثر أداءً. وقد أدّى ذلك إلى توفير أدوات وطُرق ومكتبات جديدة نريد مشاركتها معك في هذه المقالة. في الجزء الأول، سنعرض لك بعض تقنيات التحسين التي استخدمناها في الممارسة أثناء تطوير تطبيق Oodles Theater. في الجزء الثاني، سنتحدث عن تجاربنا مع التحميل التوقّعي ومبادرة Guess.js الجديدة.
الحاجة إلى الأداء
يزداد حجم المحتوى على الإنترنت كل عام. إذا اطّلعنا على حالة الويب، يمكننا أن نرى أنّ متوسّط حجم الصفحة على الأجهزة الجوّالة يبلغ حوالي 1.5 ميغابايت، ويشكّل JavaScript والصور معظم هذا الحجم.
يساهم حجم المواقع الإلكترونية المتزايد، بالإضافة إلى عوامل أخرى، مثل وقت استجابة الشبكة وحدود وحدة المعالجة المركزية وأنماط حظر العرض أو الرموز البرمجية الإضافية التابعة لجهات خارجية، في الصعوبة المعقدة التي تواجهها في ما يتعلّق بالأداء.
يصنّف معظم المستخدمين السرعة على أنّها في أعلى التسلسل الهرمي لتجربة المستخدم حسب احتياجاتهم. ليس هذا الأمر مفاجئًا جدًا، لأنّه لا يمكنك فعل الكثير إلى أن تكتمل عملية تحميل الصفحة. لا يمكنك الاستفادة من الصفحة، ولا يمكنك الإعجاب بجمالها.
نعلم أنّ الأداء مهمّ للمستخدمين، ولكن قد يبدو أيضًا أنّه من الصعب معرفة من أين تبدأ عملية التحسين. لحسن الحظ، تتوفّر أدوات يمكنها مساعدتك في ذلك.
Lighthouse: قاعدة لعملية سير العمل المتعلّقة بالأداء
Lighthouse هي جزء من "أدوات مطوّري البرامج في Chrome"، وهي أداة تسمح لك بإجراء تدقيق في موقعك الإلكتروني وتمنحك نصائح حول كيفية تحسينه.
أطلقنا مؤخرًا مجموعة من عمليات تدقيق الأداء الجديدة التي تُعدّ مفيدة جدًا في سير عمل التطوير اليومي.
لنلقِ نظرة على كيفية الاستفادة منها من خلال مثال عملي: تطبيق Oodles Theater. وهو تطبيق ويب تجريبي صغير، يمكنك من خلاله تجربة بعض رسوم Google Doodles التفاعلية المفضّلة لدينا وحتى تشغيل لعبة أو اثنتين.
أثناء إنشاء التطبيق، أردنا التأكّد من أنّه يحقّق أفضل أداء ممكن. كانت نقطة البدء في التحسين هي تقرير Lighthouse.
كان الأداء الأولي لتطبيقنا كما هو موضّح في تقرير Lighthouse سيئًا جدًا. عند استخدام شبكة الجيل الثالث، كان على المستخدم الانتظار لمدة 15 ثانية حتى يظهر أول رسم ذي معنى، أو حتى يصبح التطبيق تفاعليًا. رصدت أداة Lighthouse الكثير من المشاكل في موقعنا الإلكتروني، وعكست نتيجة الأداء العامة التي بلغت 23 ذلك تمامًا.
كان حجم الصفحة حوالي 3.4 ميغابايت، لذا كان علينا تقليل حجمها.
بدأنا بتحدّي الأداء الأول: العثور على العناصر التي يمكننا إزالتها بسهولة بدون التأثير في التجربة العامة.
فرص تحسين الأداء
إزالة الموارد غير الضرورية
هناك بعض العناصر الواضحة التي يمكن إزالتها بأمان: المسافات البيضاء والتعليقات.
يُبرز Lighthouse هذه الفرصة في تدقيق CSS وJavaScript غير المُكثَّفة. لقد كنا نستخدم webpack لعملية التصميم، لذلك لاستخدام ميزة التصغير، استخدمنا ببساطة مكوّن Uglify JS الإضافي.
تُعدّ عملية التصغير مهمة شائعة، لذا من المفترض أن تتمكّن من العثور على حلّ جاهز لأي عملية إنشاء تستخدمها.
ومن عمليات التدقيق المفيدة الأخرى في هذه المساحة تفعيل ضغط النص. ما مِن سبب لمحاولة إرسال ملفات غير مضغوطة، وغالبية شبكات توصيل المحتوى (CDN) تتيح ذلك تلقائيًا في الوقت الحالي.
كنا نستخدم استضافة Firebase لاستضافة الرمز البرمجي، وتفعّل Firebase ضغط gzip تلقائيًا، لذلك حصلنا على ذلك مجانًا بفضل استضافة الرمز البرمجي على شبكة توصيل محتوى مناسبة.
على الرغم من أنّ gzip هي طريقة شائعة جدًا للضغط، إلا أنّ آليات أخرى مثل Zopfli وBrotli تشهد أيضًا رواجًا. تتوفر تقنية Brotli في معظم المتصفّحات، ويمكنك استخدام ملف ثنائي لضغط مواد العرض مسبقًا قبل إرسالها إلى الخادم.
استخدام سياسات ذاكرة التخزين المؤقت الفعّالة
كانت خطوتنا التالية هي التأكّد من عدم إرسال الموارد مرتين إذا لم يكن ذلك ضروريًا.
ساعدتنا عملية تدقيق سياسة ذاكرة التخزين المؤقت غير الفعّالة في Lighthouse على ملاحظة أنّه يمكننا تحسين استراتيجيات التخزين المؤقت لتحقيق ذلك بالضبط. من خلال ضبط عنوان صلاحية max-age في خادمنا، تأكّدنا من أنّه يمكن للمستخدم إعادة استخدام الموارد التي سبق له تنزيلها عند الزيارة المتكررة.
من الأفضل أن تستهدف تخزين أكبر عدد ممكن من الموارد بأمان قدر الإمكان لأطول مدّة ممكنة، وتوفير الرموز المميّزة للتحقق من إعادة التحقّق بكفاءة من الموارد التي تم تعديلها.
إزالة الرموز غير المستخدَمة
لقد أزلنا حتى الآن الأجزاء الواضحة من عمليات التنزيل غير الضرورية، ولكن ماذا عن الأجزاء الأقل وضوحًا؟ على سبيل المثال، الرمز غير المستخدَم.
في بعض الأحيان، نضيف إلى تطبيقاتنا رمزًا برمجيًا غير ضروري. ويحدث ذلك بشكل خاص إذا كنت تعمل على تطبيقك لفترة زمنية أطول، أو إذا تغيّر فريقك أو تبعاتك، ويكون أحيانًا هناك مكتبة متعلّقة بتطبيق آخر تم إيقافها. هذا بالضبط ما حدث لنا.
في البداية، كنا نستخدم مكتبة Material Components لإنشاء نماذج أولية لتطبيقنا بسرعة. وبمرور الوقت، انتقلنا إلى مظهر ومضمون أكثر تخصيصًا ونسياننا هذه المكتبة تمامًا. لحسن الحظ، ساعدنا التحقّق من تغطية الرمز البرمجي في إعادة اكتشافه في حِزمنا.
يمكنك الاطّلاع على إحصاءات تغطية الرمز في DevTools، سواءً لفترة التشغيل أو وقت تحميل تطبيقك. يمكنك رؤية الشريطَين الأحمرَين الكبيرَين في لقطة الشاشة في أسفل الصفحة. كان لدينا أكثر من %95 من CSS غير مستخدَم، بالإضافة إلى مجموعة كبيرة من JavaScript.
رصدت أداة Lighthouse هذه المشكلة أيضًا في عملية تدقيق قواعد CSS غير المستخدَمة. وقد أظهرت إمكانية توفير أكثر من 400 كيلوبايت. لذلك عدنا إلى الرمز البرمجي وأزلنا كلّ من JavaScript وCSS من تلك المكتبة.
وقد أدّى ذلك إلى تقليل حِزمة CSS بمقدار 20 مرة، وهو أمر جيد جدًا لتعديل صغير مكوّن من سطرَين.
بطبيعة الحال، أدّى ذلك إلى ارتفاع نتيجة الأداء، كما تحسّن أيضًا الوقت المستغرَق للتفاعل.
ومع ذلك، مع إجراء تغييرات كهذه، لا يكفي التحقّق من المقاييس والنتائج وحدها. لا تتم إزالة الرمز البرمجي الفعلي بدون مخاطر، لذا عليك دائمًا البحث عن أيّ تراجعات محتملة.
لم يتم استخدام الرمز في %95 من المواقع، ولكن لا يزال هناك% 5 من المواقع التي تم استخدام الرمز فيها. يبدو أنّ أحد مكوّناتنا كان لا يزال يستخدم الأنماط من هذه المكتبة، وهي الأسهم الصغيرة في شريط التمرير الخاص بالرسومات. ولأنّه كان صغيرًا جدًا، كان بإمكاننا ببساطة دمج هذه الأنماط يدويًا في الأزرار.
لذلك، إذا أزلت رمزًا، تأكَّد من أنّ لديك سير عمل اختباريًا مناسبًا لمساعدتك في الحماية من حالات التراجع المرئية المحتمَلة.
تجنُّب الأحمال الكبيرة على الشبكة
ندرك أنّ الموارد الكبيرة يمكن أن تبطئ عملية تحميل صفحات الويب. ويمكن أن تؤدي إلى خسارة المستخدمين للمال، وتأثير كبير في خطط بياناتهم، لذا من المهم جدًا الانتباه إلى ذلك.
تمكّنت أداة Lighthouse من رصد مشكلة في بعض حِزم بيانات المستخدمين على الشبكة باستخدام عملية التدقيق في حِزم بيانات المستخدمين الكبيرة جدًا على الشبكة.
تبيّن لنا أنّنا نرسل أكثر من 3 ميغابايت من الرموز البرمجية، وهو رقم كبير جدًا، خاصةً على الأجهزة الجوّالة.
في أعلى هذه القائمة، لفتت أداة Lighthouse إلى أنّنا نستخدم حِزمة مطوّر JavaScript كانت تتضمن رمزًا غير مضغوط بحجم 2 ميغابايت. وهذه أيضًا مشكلة يُبرزها Webpack.
كما يقول المثل: أسرع طلب هو الطلب الذي لم يتم تقديمه.
من الأفضل قياس قيمة كل مادة عرض تقدّمها للمستخدمين، وقياس أداء مواد العرض هذه، وتحديد ما إذا كان من المفيد إرسالها مع التجربة الأولية. لأنّه يمكن أحيانًا تأجيل تحميل مواد العرض هذه أو تحميلها بشكلٍ بطيء أو معالجتها أثناء وقت الاستراحة.
في حالتنا، لأنّنا نتعامل مع الكثير من حِزم JavaScript، كان من حسن حظّنا أنّه يتوفر لدى منتدى JavaScript مجموعة غنية من أدوات تدقيق حِزم JavaScript.
بدأنا باستخدام أداة تحليل حِزم Webpack، التي أبلغتنا بأنّنا نضمّن ملفًا تابعًا يُسمى unicode يبلغ حجمه 1.6 ميغابايت من JavaScript تم تحليله، أي أنّه كبير جدًا.
انتقلنا بعد ذلك إلى المحرِّر وباستخدام مكوّن "استيراد التكلفة" الإضافي لـ Visual Code، تمكّنا من تمثيل تكلفة كل وحدة كنا نستوردها. سمح لنا ذلك باكتشاف المكوّن الذي يتضمّن رمزًا يشير إلى هذه الوحدة.
بعد ذلك، انتقلنا إلى أداة أخرى، وهي BundlePhobia. هذه أداة تتيح لك إدخال اسم أي حزمة NPM والاطّلاع على الحجم المقدَّر للحزمة بعد تصغيرها وملفها المضغوط. لقد عثرنا على بديل رائع لوحدة العنوان الذي كنا نستخدمه الذي لا يزن سوى 2.2 كيلوبايت، لذا استبدلناه.
وقد كان لهذا الإجراء تأثير كبير في أداؤنا. من خلال هذا التغيير واكتشاف فرص أخرى لتقليل حجم حِزمة JavaScript، تمكّنا من توفير 2.1 ميغابايت من الرموز البرمجية.
لقد شهدنا تحسينات بنسبة% 65 بشكل عام، بعد احتساب حجم هذه الحِزم المضغوطة والمُكثَّفة. وتبيّن لنا أنّ هذه العملية جديرة بالاهتمام.
لذلك، ننصحك بشكل عام بتجنُّب عمليات التنزيل غير الضرورية في مواقعك الإلكترونية وتطبيقاتك. يمكن أن يؤدي إنشاء مستودع لمواد العرض وقياس تأثير أدائها إلى اختلافٍ كبير جدًا، لذا احرص على تدقيق مواد العرض بانتظام.
تقليل وقت بدء تشغيل JavaScript من خلال تقسيم الرموز
على الرغم من أنّ الأحمال الكبيرة على الشبكة يمكن أن تؤثر بشكل كبير في تطبيقنا، هناك عامل آخر يمكن أن يؤدي إلى تأثير كبير جدًا، وهو JavaScript.
JavaScript هي أغلى مادة عرض. على الأجهزة الجوّالة، إذا كنت تُرسِل حزمًا كبيرة من JavaScript، قد يؤدي ذلك إلى تأخير وقت تفاعل المستخدمين مع مكونات واجهة المستخدم. وهذا يعني أنّه يمكنهم النقر على واجهة المستخدم بدون حدوث أيّ تفاعل ذي معنى فعلي. لذلك، من المهم معرفة سبب ارتفاع تكلفة JavaScript.
هذه هي الطريقة التي يعالج بها المتصفّح لغة JavaScript.
علينا أولاً تنزيل هذا النص البرمجي، ولدينا محرّك JavaScript الذي يحتاج بعد ذلك إلى تحليل هذا الرمز البرمجي وتجميعه وتنفيذه.
لا تستغرق هذه المراحل الآن الكثير من الوقت على جهاز متطوّر مثل جهاز كمبيوتر مكتبي أو كمبيوتر محمول، أو حتى هاتف متطوّر. ولكن على هاتف جوّال متوسط، يمكن أن تستغرق هذه العملية مدة تتراوح بين خمس وعشر مرات أطول. وهذا ما يؤخّر التفاعل، لذلك من المهم أن نحاول تقليل هذا الوقت.
لمساعدتك في اكتشاف هذه المشاكل في تطبيقك، أضفنا تدقيقًا جديدًا في وقت بدء تشغيل JavaScript إلى Lighthouse.
وفي ما يتعلّق بتطبيق Oodle، تبيّن لنا أنّه استغرق 1.8 ثانية في عملية بدء تشغيل JavaScript. ما كان يحدث هو أنّنا كنّا نستورِد بشكلٍ ثابت جميع المسارات والمكونات في حِزمة JavaScript واحدة موحّدة.
ومن بين التقنيات التي يمكن استخدامها لحلّ هذه المشكلة هي تقسيم الرموز البرمجية.
تقسيم الرموز البرمجية هو مفهوم يشير إلى أنّه بدلاً من منح المستخدمين رمز JavaScript بحجم فطيرة كاملة، ماذا لو منحتهم شريحة واحدة فقط في كل مرة حسب الحاجة؟
يمكن تطبيق تقسيم الرموز البرمجية على مستوى المسار أو على مستوى المكوّن. وهو يعمل بشكل رائع مع React وReact Loadable وVue.js وAngular وPolymer وPreact ومكتبات أخرى متعددة.
لقد دمجنا ميزة "تقسيم الرموز البرمجية" في تطبيقنا، وبدّلنا من عمليات الاستيراد الثابتة إلى عمليات الاستيراد الديناميكية، ما سمح لنا بتحميل الرموز البرمجية بشكل غير متزامن عند الحاجة إليها.
وقد أدّى ذلك إلى تصغير حجم حِزمنا، فضلاً عن تقليل وقت بدء تشغيل JavaScript. تم خفض هذا الوقت إلى 0.78 ثانية، ما جعل التطبيق أسرع بنسبة% 56.
بشكل عام، إذا كنت بصدد إنشاء تجربة تعتمد بشكل كبير على JavaScript، احرص على إرسال الرمز البرمجي إلى المستخدِم الذي يحتاج إليه فقط.
يمكنك الاستفادة من مفاهيم مثل تقسيم الرموز البرمجية واستكشاف أفكار مثل إزالة المحتوى غير الضروري من الشجرة، والاطّلاع على webpack-libs-optimizations repo للحصول على بعض الأفكار حول كيفية تقليل حجم مكتبتك إذا كنت تستخدم webpack.
تحسين الصور
في تطبيق Oodle، نستخدم الكثير من الصور. لسوء الحظ، لم يكن فريق Lighthouse متحمّسًا لهذه الميزة بقدر ما كنا متحمّسين لها. في الواقع، تعذّر علينا اجتياز عمليات التدقيق الثلاث المتعلّقة بالصور.
لقد نسيْنا تحسين صورنا، ولم نكن نحدّد حجمها بشكل صحيح، ويمكننا أيضًا تحقيق بعض الفوائد من استخدام تنسيقات صور أخرى.
بدأنا بتحسين صورنا.
لإجراء جولة تحسين لمرة واحدة، يمكنك استخدام أدوات مرئية مثل ImageOptim أو XNConvert.
يمكنك اتّباع نهج أكثر آلية من خلال إضافة خطوة تحسين الصور إلى عملية الإنشاء، باستخدام مكتبات مثل imagemin.
بهذه الطريقة، يمكنك التأكّد من تحسين الصور المُضافة في المستقبل تلقائيًا. تقدّم لك بعض شبكات توصيل المحتوى، مثل Akamai أو الحلول التابعة لجهات خارجية، مثل Cloudinary أو Fastly أو Uploadcare، حلولًا شاملة لتحسين الصور، ما يتيح لك أيضًا استضافة صورك على هذه الخدمات بسهولة.
إذا كنت لا تريد إجراء ذلك بسبب التكلفة أو مشاكل وقت الاستجابة، تقدّم مشاريع مثل Thumbor أو Imageflow بدائل مستضافة ذاتيًا.
تم وضع علامة على صورة PNG للخلفية في webpack على أنّها كبيرة، وهذا صحيح. بعد ضبط حجمها بشكل صحيح لتلائم إطار العرض وتشغيلها من خلال ImageOptim، تم تقليل حجمها إلى 100 كيلوبايت، وهو حجم مقبول.
وقد سمح لنا تكرار ذلك لعدة صور على موقعنا الإلكتروني بخفض إجمالي وزن الصفحة بشكل كبير.
استخدام التنسيق المناسب للمحتوى المتحرك
يمكن أن تصبح ملفات GIF باهظة الثمن. من المفاجئ أنّ تنسيق GIF لم يكن مخصّصًا في الأساس لعرض الرسوم المتحركة. لذلك، يؤدي التبديل إلى تنسيق فيديو أكثر ملاءمةً إلى تقليل حجم الملف بشكلٍ كبير.
في تطبيق Oodle، كنا نستخدم صورة GIF كسلسلة افتتاحية على الصفحة الرئيسية. وفقًا لخدمة Lighthouse، يمكننا توفير أكثر من 7 ميغابايت من خلال التبديل إلى تنسيق فيديو أكثر فعالية. كان حجم المقطع لدينا حوالي 7.3 ميغابايت، وهو حجم كبير جدًا لأي موقع إلكتروني معقول، لذلك بدلاً من ذلك، حوّلناه إلى عنصر فيديو يتضمّن ملفّين مصدرَين، هما mp4 وWebM لتوفير توافق أوسع مع المتصفّحات.
استخدمنا أداة FFmpeg لتحويل الصورة المتحركة بتنسيق GIF إلى ملف mp4. يوفّر لك تنسيق WebM وفورات أكبر، إذ يمكن لواجهة برمجة التطبيقات ImageOptim API إجراء عملية التحويل هذه نيابةً عنك.
ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4
لقد نجحنا في توفير أكثر من% 80 من الوزن الإجمالي بفضل عملية التحويل هذه. وقد ساعدنا ذلك في تقليل حجم الملف إلى 1 ميغابايت تقريبًا.
ومع ذلك، يُعدّ 1 ميغابايت موردًا كبيرًا لخفض سرعة التحميل، خاصةً للمستخدم الذي يستخدم سرعة نقل بيانات محدودة. لحسن الحظ، تمكّنا من استخدام Effective Type API لمعرفة أنّ سرعة نقل البيانات منخفضة، وتقديم ملف JPEG أصغر حجمًا بدلاً من ذلك.
تستخدِم هذه الواجهة وقت الرحلة ذهابًا وإيابًا الفعّال وقيم التحميل لتقدير نوع الشبكة التي يستخدمها المستخدم. ويعرض ببساطة سلسلة، مثل شبكة الجيل الثاني البطيئة أو شبكة الجيل الثاني أو شبكة الجيل الثالث أو شبكة الجيل الرابع. وبناءً على هذه القيمة، إذا كان المستخدم يستخدم شبكة أقل من شبكة الجيل الرابع، يمكننا استبدال عنصر الفيديو بالصورة.
if (navigator.connection.effectiveType) { ... }
يُقلّل ذلك من تجربة المستخدم، ولكن على الأقل يمكن استخدام الموقع الإلكتروني على اتصال بطيء.
تحميل الصور غير المعروضة على الشاشة بأسلوب "التحميل الكسول"
غالبًا ما تحمّل العروض الدوّارة أو أشرطة التمرير أو الصفحات الطويلة جدًا الصور، حتى لو لم يتمكّن المستخدم من رؤيتها على الصفحة على الفور.
سيُبلغ Lighthouse عن هذا السلوك في تدقيق الصور التي لا تظهر على الشاشة، ويمكنك أيضًا الاطّلاع عليه بنفسك في لوحة الشبكة في DevTools. إذا لاحظت أنّ هناك الكثير من الصور الواردة بينما تظهر بضع صور فقط على الصفحة، يعني ذلك أنّه يمكنك استخدام ميزة "التحميل البطيء" بدلاً من ذلك.
لا يتوفّر التحميل البطيء بعد في المتصفح، لذا علينا استخدام JavaScript لإضافته. لقد استخدمنا مكتبة Lazysizes لإضافة سلوك التحميل المُتأخّر إلى أغلفة Oodle.
<!-- Import library -->
import lazysizes from 'lazysizes' <!-- or -->
<script src="lazysizes.min.js"></script>
<!-- Use it -->
<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
data-sizes="auto"
data-src="image2.jpg"
data-srcset="image1.jpg 300w,
image2.jpg 600w,
image3.jpg 900w"/>
إنّ ميزة Lazysizes ذكية لأنّها لا تتتبّع تغييرات مستوى ظهور العنصر فحسب، بل تُجري أيضًا
عمليات جلب مسبق للعناصر القريبة من إطار العرض بشكل استباقي لتوفير تجربة مثالية للمستخدم.
ويقدّم أيضًا عملية دمج اختيارية مع IntersectionObserver
، ما يمنحك عمليات بحث فائقة فعالية عن مستوى الرؤية.
بعد هذا التغيير، يتم جلب صورنا عند الطلب. إذا أردت التعمّق أكثر في هذا الموضوع، يمكنك الاطّلاع على images.guide، وهو مرجع مفيد وشامل للغاية.
مساعدة المتصفّح في عرض الموارد المهمة في وقت مبكر
لا تتمتع كل بايتة يتم إرسالها إلى المتصفّح بالأهمية نفسها، ويعرف المتصفّح ذلك. تتضمّن الكثير من المتصفّحات أساليب استقرائية لتحديد ما يجب جلبه أولاً. لذلك، أحيانًا سيجلب محرّك البحث CSS قبل الصور أو النصوص البرمجية.
من المفيد أن نخبر المتصفّح بما هو مهم بالنسبة إلينا كمؤلفين للصفحة. لحسن الحظ، خلال السنتَين الماضيتَين، أضاف مورّدو المتصفّحات
عددًا من الميزات لمساعدتنا في ذلك، مثل
إشارات الموارد مثل link rel=preconnect
أو preload
أو prefetch
.
تساعد هذه الإمكانات التي تم توفيرها لمنصّة الويب المتصفّح في جلب المحتوى المناسب في الوقت المناسب، ويمكن أن تكون أكثر فعالية قليلاً من بعض الأساليب المستندة إلى المنطق والتي يتم تنفيذها باستخدام نص برمجي بدلاً من ذلك.
لنطّلِع على كيفية توجيهنا من خلال Lighthouse لاستخدام بعض هذه الميزات بفعالية.
أول إجراء يُوصي به Lighthouse هو تجنُّب إجراء عدة رحلات ذهاب وإياب باهظة التكلفة إلى أي مصدر.
في ما يتعلّق بتطبيق Oodle، نستخدم بشكل كبير "Google Fonts". عند إسقاط جدول ملف stylesheet لخط Google Font في صفحتك، سيتم ربط ما يصل إلى نطاقَين فرعيَّين. وتشير أدوات Lighthouse إلى أنّه إذا تمكّنا من تهيئة هذا الاتصال، يمكننا توفير up to 300 milliseconds في وقت الاتصال الأولي.
من خلال الاستفادة من رابط rel preconnect، يمكننا إخفاء وقت استجابة الاتصال هذا بفعالية.
يمكن أن يكون لهذا الإجراء تأثير كبير، خاصةً في ما يتعلّق بخدمة Google Fonts التي يتم فيها استضافة ملف CSS الخاص بواجهة الخط على googleapis.com، ويتم استضافة موارد الخط على Gstatic. لذلك، طبّقنا هذا التحسين ونجحنا في تقليل الوقت ببضعة مئات من المللي ثانية.
تقترح أداة Lighthouse إجراء التحميل المُسبَق لطلبات المفاتيح.
إنّ <link rel=preload>
مفيد جدًا، فهو يُعلم المتصفّح بضرورة الحصول على مرجع كهئة
جزء من التنقّل الحالي، ويحاول أن يطلب من المتصفّح جلبه في أقرب وقت ممكن.
يُخبرنا Lighthouse الآن أنّه علينا تحميل موارد خطوط الويب الأساسية مسبقًا، لأنّنا نحمّل خطّي ويب.
يظهر التحميل المُسبَق في خط ويب على النحو التالي: عند تحديد rel=preload
، يتم إدخال as
مع
نوع الخط، ثم تحديد نوع الخط الذي تحاول تحميله، مثل woff2.
ويمكن أن يكون تأثير ذلك على صفحتك شديدًا.
في العادة، بدون استخدام ميزة "التحميل المُسبَق للروابط"، إذا كانت خطوط الويب مهمة لصفحتك، على المتصفّح أولاً جلب ملف HTML وتحليل ملف CSS، ثم بعد ذلك جلب خطوط الويب.
باستخدام رابط rel preload، يمكن للمتصفّح بدء جلب هذه الخطوط على الويب في وقت أبكر بكثير بعد تحليل رمز HTML. في تطبيقنا، تمكّنا من تقليل المدّة التي يستغرقها عرض النص باستخدام خطوط الويب بمقدار ثانية واحدة.
في الوقت الحالي، لم تعُد هذه العملية بهذه البساطة إذا كنت تريد محاولة تحميل الخطوط مسبقًا باستخدام Google Fonts، فهناك مشكلة واحدة.
إنّ عناوين URL لخطوط Google التي نحدّدها في تصاميم الخطوط في جداول الأنماط هي من الأمور التي يُعدّلها فريق الخطوط بانتظام إلى حدٍ ما. يمكن أن تنتهي صلاحية عناوين URL هذه أو يتم تعديلها بصفة منتظمة، لذا ننصحك باستضافة خطوط الويب بنفسك إذا كنت تريد التحكّم بشكل كامل في تجربة تحميل الخطوط. يمكن أن يكون ذلك رائعًا لأنّه يمنحك إمكانية الوصول إلى عناصر مثل ميزة "التحميل المُسبَق لرابط rel".
في حالتنا، تبيّن لنا أنّ الأداة مساعِد خطوط الويب من Google مفيدة جدًا في مساعدتنا على تنزيل بعض خطوط الويب هذه وإعدادها على الجهاز، لذا ننصحك بالاطّلاع على هذه الأداة.
سواء كنت تستخدم خطوط ويب كجزء من مواردك المهمة أو JavaScript، عليك محاولة مساعدة المتصفّح في عرض مواردك المهمة في أقرب وقت ممكن.
ميزة تجريبية: نصائح بشأن الأولوية
لدينا أخبار سارّة لمشاركتها معك اليوم. بالإضافة إلى ميزات مثل تعديلات الموارد، بالإضافة إلى التحميل المُسبَق، عملنا على ميزة تجريبية جديدة تمامًا للمتصفّح نُطلق عليها اسم تعديلات الأولوية.
هذه ميزة جديدة تتيح لك إخبار المتصفّح بمدى أهمية المورد. ويُظهر سمة جديدة - importance (الأهمية) - بالقيم low (منخفض) أو high (مرتفع) أو auto (تلقائي).
يتيح لنا ذلك خفض أولوية الموارد الأقل أهمية، مثل التنسيقات أو الصور أو طلبات جلب البيانات من واجهة برمجة التطبيقات غير المُهمّة، وذلك لتقليل التعارض. يمكننا أيضًا زيادة أولوية العناصر الأكثر أهمية، مثل صور المنتجات الرئيسية.
في ما يتعلّق بتطبيق Oodle، أدّى ذلك إلى تحديد مكان عملي واحد يمكننا تحسينه.
قبل إضافة ميزة "التحميل البطيء" إلى صورنا، كان المتصفّح يعرض لوحة عرض الدوّارة هذه التي تتضمّن جميع رسوماتك المضحكة، وكان يُحمّل جميع الصور في بداية لوحة العرض الدوّارة مع منح الأولوية العالية لها. ولكن الصور في منتصف carousel كانت هي الأكثر أهمية للمستخدم. لذلك، ما فعلناه هو ضبط أهمية هذه الصور في الخلفية على مستوى منخفض جدًا، وتلك في المقدّمة على مستوى مرتفع جدًا، ما أدّى إلى أثرٍ في غضون ثانيتَين على شبكة الجيل الثالث البطيئة، وسرعة استرجاعنا لهذه الصور وعرضها. كانت تجربة إيجابية.
نأمل أن نتيح هذه الميزة في الإصدار Canary خلال بضعة أسابيع، لذا ننصحك بمتابعتنا.
أن تتّبع استراتيجية لتحميل خطوط الويب
يشكّل أسلوب الخط عاملاً أساسيًا لجودة التصميم، وإذا كنت تستخدِم خطوط الويب، من الأفضل عدم حظر عرض النص، ومن المؤكد أنّك لا تريد عرض نص غير مرئي.
نُبرز ذلك في Lighthouse الآن من خلال عملية التدقيق تجنُّب النص غير المرئي أثناء تحميل خطوط الويب.
في حال تحميل خطوط الويب باستخدام كتلة خط، يعني ذلك أنّك تترك للمتصفّح تحديد الإجراء الذي يجب اتّخاذه إذا استغرق جلب خط الويب هذا وقتًا طويلاً. ستنتظر بعض المتصفّحات ما يصل إلى ثلاث ثوانٍ قبل الرجوع إلى خط نظام، وستستبدله أخيرًا بالخط بعد تنزيله.
نحاول تجنُّب هذا النص غير المرئي، لذا في هذه الحالة، لم يكن بإمكاننا رؤية رسومات الشعار المميّزة
لهذا الأسبوع إذا استغرق تحميل خط الويب وقتًا طويلاً. لحسن الحظ، تتوفّر ميزة جديدة تُعرف باسم
font-display
تتيح لك التحكّم بشكل أكبر في هذه العملية.
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-display: swap;
font-weight: 400;
src: local('Montserrat Regular'), local('Montserrat-Regular'),
/* Chrome 26+, Opera 23+, Firefox 39+ */
url('montserrat-v12-latin-regular.woff2') format('woff2'),
/* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
url('montserrat-v12-latin-regular.woff') format('woff');
}
تساعدك ميزة عرض الخطوط في تحديد كيفية عرض خطوط الويب أو الخطوط الاحتياطية استنادًا إلى المدة التي يستغرقها تبديلها.
في هذه الحالة، سنستخدم ميزة تبديل عرض الخط. تمنح عملية التبديل خطّ الرقعة فترة حظر مدتها صفر ثانية، وفترة تبديل لا نهائية. وهذا يعني أنّ المتصفّح سيرسم النص على الفور باستخدام خط احتياطي إذا استغرق تحميل الخط بعض الوقت. وسيتم تبديله بعد توفُّر الخط.
في ما يتعلّق بتطبيقنا، كان هذا الإجراء رائعًا لأنّه سمح لنا بعرض بعض النصوص ذات المعنى العميق في مرحلة مبكرة جدًا، والانتقال إلى خط الويب بعد أن أصبح جاهزًا.
بشكل عام، إذا كنت تستخدم خطوط الويب، كما تفعل نسبة كبيرة من المواقع الإلكترونية، عليك وضع استراتيجية تحميل خطوط ويب جيدة.
هناك الكثير من ميزات منصة الويب التي يمكنك استخدامها لتحسين تجربة تحميل الخطوط، ويمكنك أيضًا الاطّلاع على مستودع وصفات خطوط الويب الذي أنشأه "زاك ليذرمان"، لأنّه رائع حقًا.
تقليل النصوص البرمجية التي تمنع عرض الإعلانات
هناك أجزاء أخرى من تطبيقنا يمكننا طرحها في وقت أبكر من سلسلة التنزيل لتوفير بعض تجربة المستخدم الأساسية على الأقل في وقت أبكر قليلاً.
في شريط مخطط الوقت في Lighthouse، يمكنك ملاحظة أنّه خلال هذه الثواني القليلة الأولى التي يتم فيها تحميل كل الموارد، لا يمكن للمستخدم رؤية أي محتوى.
إنّ تنزيل أوراق الأنماط الخارجية ومعالجتها يمنع عملية التقديم من تحقيق أيّ تقدّم.
يمكننا محاولة تحسين مسار المعالجة الحرج من خلال عرض بعض الأنماط مبكرًا قليلاً.
إذا استخرجنا الأنماط المسؤولة عن العرض الأولي وأدرجناها في ملف HTML، يمكن للمتصفّح عرضها على الفور بدون انتظار وصول أوراق الأنماط الخارجية.
في حالتنا، استخدمنا وحدة NPM تُسمى Critical لتضمين المحتوى المهم في index.html أثناء خطوة الإنشاء.
على الرغم من أنّ هذه الوحدة قدّمت لنا معظم المساعدة، كان من الصعب قليلاً اتّباع هذه الخطوات بسلاسة على مسارات مختلفة.
إذا لم تكن حذِقًا أو كانت بنية موقعك الإلكتروني معقّدة جدًا، قد يكون من الصعب جدًا استخدام هذا النوع من الأنماط إذا لم تكن قد خططت ل بنية واجهة التطبيق من البداية.
لهذا السبب، من المهم جدًا مراعاة جوانب الأداء مبكرًا. إذا لم تضع تحسين الأداء في الاعتبار منذ البداية، من المرجّح أن تواجه مشاكل في وقت لاحق.
في النهاية، تكلّلت المخاطرة بالنجاح، وتمكّنا من تنفيذ ذلك وبدأ التطبيق بعرض المحتوى في وقتٍ أبكر بكثير، ما أدّى إلى تحسين وقت عرض أوّل محتوى مفيد على الصفحة بشكلٍ كبير.
النتيجة
هذه قائمة طويلة بتحسينات الأداء التي طبّقناها على موقعنا الإلكتروني. لنلقِ نظرة على النتيجة. في ما يلي كيفية تحميل تطبيقنا على جهاز جوّال متوسط على شبكة الجيل الثالث، قبل التحسين وبعده.
ارتفعت نتيجة أداء Lighthouse من 23 إلى 91. هذا تقدّم جيد من حيث السرعة. لقد أجرينا كل هذه التغييرات بعد مراجعة تقرير Lighthouse باستمرار ومتابعته. إذا أردت الاطّلاع على كيفية تنفيذنا جميع التحسينات من الناحية الفنية، يُرجى الاطّلاع على مستودعنا، خاصةً على طلبات التغيير التي تم إرسالها إليه.
الأداء التوقّعي: تجارب مستنِدة إلى البيانات
نعتقد أنّ تعلُّم الآلة يمثّل فرصة رائعة للمستقبل في العديد من المجالات. نأمل أن تؤدي إحدى الأفكار إلى إجراء المزيد من التجارب في المستقبل، وهي أنّ البيانات الحقيقية يمكن أن تُرشد تجربتَي المستخدمين اللتين ننشئهما.
في الوقت الحالي، نتّخذ الكثير من القرارات التعسّفية بشأن ما قد يريده المستخدم أو يحتاجه، وبالتالي، ما يستحقّ أن يتمّ جلبه مسبقًا أو تحميله مسبقًا أو تخزينه مؤقتًا مسبقًا. إذا كنا على صواب، يمكننا منح الأولوية لعدد صغير من الموارد، ولكن من الصعب جدًا توسيع نطاقها ليشمل الموقع الإلكتروني بأكمله.
تتوفّر لدينا بيانات لتحسين الأداء بشكل أفضل اليوم. باستخدام Google Analytics Reporting API، يمكننا الاطّلاع على النسب المئوية التالية للصفحات الأكثر زيارة ونسب الخروج لأي عنوان URL على موقعنا الإلكتروني، وبالتالي استخلاص النتائج بشأن الموارد التي يجب أولاً إعطائها الأولوية.
وإذا جمعنا ذلك مع نموذج احتمالية جيد، يمكننا تجنُّب إهدار بيانات المستخدمين من خلال التحميل المُسبق المفرط للمحتوى. يمكننا الاستفادة من بيانات "إحصاءات Google"، واستخدام تعلُّم الآلة والنماذج مثل سلاسل ماركوف أو الشبكة العصبية من أجل تنفيذ هذه النماذج.
لتسهيل إجراء هذه التجارب، يسرّنا الإعلان عن مبادرة جديدة أطلقنا عليها اسم Guess.js.
Guess.js هو مشروع يركّز على تجارب المستخدِمين المستندة إلى البيانات على الويب. نأمل أن يؤدي ذلك إلى الاستكشاف واستخدام البيانات لتحسين أداء الويب وغير ذلك. وهي كلها مفتوحة المصدر ومتاحة على GitHub اليوم. تم إنشاء هذه الميزة بالتعاون مع منتدى المحتوى المفتوح من قِبل "مينكو غيفتش" و"كايل ماثيوز" من Gatsby و"كاتي هِمبينيوس" وعدد من الأشخاص الآخرين.
يمكنك الاطّلاع على Guess.js وإعلامنا برأيك.
ملخّص
إنّ النتائج والمقاييس مفيدة في تحسين سرعة الويب، ولكنها ليست سوى الوسائل، وليست الأهداف نفسها.
لقد واجهنا جميعًا بطء في تحميل الصفحات أثناء التنقل، ولكن لدينا الآن فرصة لتقديم تجارب أكثر روعة لمستخدمينا يتم تحميلها بسرعة كبيرة.
تحسين الأداء هو رحلة. يمكن أن تؤدي الكثير من التغييرات الصغيرة إلى تحقيق مكاسب كبيرة. باستخدام أدوات التحسين المناسبة ومراقبة تقارير Lighthouse، يمكنك تقديم تجربة أفضل وأكثر شمولية للمستخدمين.
مع جزيل الشكر إلى: "وارد بييتر" و"مينكو غيفتش" و"كايل ماثيوز" و"كاتي هيمبينيوس" و"دوم فارولينو"، و"يوآف ويس" و"سوسي لو" و"يوسوكي أوتسونوميا" و"توم أنكرز" و"مرشد" و"صور Google المتحركة".