المواقع الإلكترونية التي تُحمَّل صفحاتها بسرعة ترضي مستخدميها، وهي مفيدة أيضًا لتحسين محركات البحث (SEO). فمحركات البحث مثل Google وBing تسعى إلى منح الترتيب الأعلى لأفضل المواقع، أي تلك التي تقدّم محتوى رائعًا وتجربة مستخدم أفضل في الوقت نفسه. وفهم أفضل الممارسات لتسريع المواقع قد يصنع الفرق بين تطبيق ممتاز وآخر ضعيف. سأشارككم اليوم كيف تحسّنون سرعة موقعكم وتحصلون على نتائج أفضل عند اختباره بأدوات مثل WebPageTest وGoogle Page Speed Insights وPingdom وGTmetrix، وهي أشهر المواقع لاختبار سرعة تحميل الصفحات.

1. فعّلوا ضغط GZip

GZip نوع من ضغط البيانات، أي أنه يأخذ كتلة من البيانات ويصغّر حجمها. ويمكن استعادة البيانات الأصلية بفك ضغط الملف.

ولأن بروتوكول HTTP يدعم ضغط البيانات المرسلة بـ gzip، فهو وثيق الصلة بتطبيقات الويب والمواقع الإلكترونية.

وهذا يعني أنه عند استخدامه ستنخفض تكلفة النطاق الترددي (bandwidth) لتقديم الموقع، لأن زوار الموقع سيحمّلون ملفات أصغر حجمًا.

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

وبطبيعة الحال، تُضغط بعض الملفات بفعالية أكبر من غيرها، فيختلف مقدار التوفير. فالملفات النصية مثل HTML تحقق أفضل النتائج، أما الصور فلا يضغطها gzip كثيرًا لأنها مضغوطة أصلًا. بل إن بعض الملفات (مثل الملفات المضغوطة بشدة كملفات .zip) قد يزداد حجمها عند ضغطها بـ gzip، لأنها لا تقبل مزيدًا من الضغط بينما يحتاج gzip إلى إضافة بياناته الوصفية (metadata) إلى الملف.

ولتفعيل ضغط Gzip، يمكننا تفعيله من برنامج خادم الويب مثل Apache وNginx وغيرهما.

فمثلًا، إذا أردتم تفعيل ضغط Gzip في Nginx، يمكنكم ضبط ملف nginx.conf باتباع هذا الدليل لتفعيل الضغط في Nginx. وإذا كنتم تطوّرون تطبيق ويب باستخدام Express.js، يمكنكم تفعيله باستخدام compression middleware.

2. استخدموا صيغة صور حديثة مثل WEBP

يقلّل استخدام صيغة صور حديثة مثل WEBP زمن تحميل الصفحة بشكل ملحوظ، لأنها أصغر حجمًا من الصيغ الشائعة مثل PNG وJPEG بنحو 25% - 34%. عادةً ما أُنشئ الصورة بصيغتين. فإذا استخدمت صورة PNG في مكان ما من صفحاتي، أحوّل الصورة نفسها إلى صيغة WEBP. ويمكن التحويل بسهولة باستخدام برامج مثل Adobe Photoshop أو GIMP. ثم أضمّن صورة WEBP مع صورة بديلة (fallback). فإذا كان المتصفح لا يدعم WEBP، فسيستخدم الصورة البديلة. وإليكم مثالًا على استخدام صورة WEBP مع صورة بديلة.

<picture>
    <source srcset="image.webp" type="image/webp">
    <source srcset="image.jpg" type="image/jpeg">
    <img src="image.jpg">
</picture>

3. اختاروا مقاسات الصور المناسبة

يقلّل استخدام مقاسات الصور المناسبة زمن تحميل الصفحة الإجمالي بشكل كبير. فيمكننا استخدام صور أكبر في نسخة الموقع المخصصة لأجهزة الكمبيوتر، وصور أصغر لنسخة الجوال. ونحن اليوم نصمّم المواقع ونطوّرها بحيث يتكيّف تخطيطها مع حجم شاشة المستخدم. وتُسمّى هذه التقنية "التصميم المتجاوب" (Responsive Web Design). لكن عندما يتعلق الأمر بتحسين السرعة، لا يكفي أن يكون لكل حجم شاشة تخطيط مختلف. بل ينبغي أيضًا عرض مقاسات صور مناسبة لحجم شاشة المستخدم. قد يبدو عرض شريط صور بعرض الشاشة كاملًا على جهاز مكتبي أو محمول مذهلًا، لكن عرضه على الجوال فكرة سيئة جدًا، لأنه يستغرق وقتًا أطول في التحميل ويستهلك باقة بيانات المستخدم. ولتجاوز هذه المشكلة، نحتاج إلى إنشاء الصورة بعدة مقاسات وعرضها بشكل صحيح باستخدام الخاصية srcset في وسم img.

<img src="cat.png"
  alt="A picture of a cat"
  srcset="cat-320.png 320w,
         cat-640.png 640w,
       cat-922.png 922w,
       cat-1200.png 1200w">

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

4. قلّلوا عدد الطلبات

تحتوي تطبيقات الويب التقليدية عادةً على كثير من وسوم script وstyle في صفحاتها. وقد تضم بعض الصفحات أكثر من 20 رابطًا لملفات CSS وJavascript والخطوط.

ومن المهم أن تعرفوا أن المتصفحات لا تحمّل كل الموارد دفعة واحدة. فلكل متصفح عدد افتراضي من الاتصالات الدائمة المتزامنة لكل خادم أو proxy. وإذا بلغ الحد الأقصى من الاتصالات، ينتظر المتصفح حتى تنتهي الاتصالات الحالية أولًا. فمثلًا، إذا كانت لديكم 20 ملف javascript في الصفحة، وكان متصفحكم يدعم 10 اتصالات دائمة متزامنة، فسينتظر حتى ينتهي تحميل ملف أو أكثر قبل أن يواصل تحميل بقية الملفات. وخلال ذلك تبقى بقية الصفحة فارغة ومحجوبة حتى ينتهي تحميل الموارد المطلوبة. ولحل هذه المشكلة عليكم أن:

1. تضمّنوا فقط الملفات التي تحتاجها الصفحة فعلًا. فإذا كانت الصفحة لا تحتاج إلى أداة التقويم مثلًا، فلا تضمّنوا ملف التقويم فيها.
2. تجمعوا ملفات javascript أو ملفات الأنماط في حزمة (bundle). والأفضل دمج كل السكربتات في ملف واحد. وإذا أصبح كبيرًا جدًا، فقد تفكرون في استخدام تقنية التحميل الكسول (lazy-load)، وهي تعتمد على إطار javascript الذي تستخدمونه.
3. إذا كانت صفحاتكم تعرض صورًا كثيرة، ففكروا في تقنية التحميل الكسول للصور. فهي تعرض مساحة فارغة للحفاظ على التخطيط، ولا تحمّل الصور فعليًا إلا حين يقترب المستخدم منها أثناء التمرير. وهناك مكتبات كثيرة للتحميل الكسول للصور على الإنترنت، مثل هذه المكتبة المكتوبة بـ vanilla javascript. وهناك تقنيات متنوعة للتحميل الكسول، وبعضها تدعمه المتصفحات الرئيسية افتراضيًا.

5. تخلّصوا من الموارد التي تعطّل العرض (render-blocking)

هناك مصطلح Above the fold، ويعني المحتوى الذي يراه المستخدمون أولًا دون التمرير إلى الأسفل. وينبغي أن يتمكن المستخدمون من رؤيته حتى قبل اكتمال تحميل الصفحة. المشكلة أن طلبات ملفات الأنماط وملفات javascript قد تمنع عرض هذا المحتوى، كما ذكرت في القسم السابق، لأن للمتصفحات حدًا أقصى من الاتصالات المتوازية. كما قد تعطّل عملية العرض نفسها. لذلك علينا وضع وسوم style وlink داخل الوسم <head>، ووضع كل ملفات javascript قبل الوسم </body>. وبهذا النهج يمكن عرض الصفحة جزئيًا قبل اكتمال تحميل كل الملفات.

<!DOCTYPE html>
<html>
    <head>
         <style>
            # some style goes here.
         </style>
         <link href="xxx.css" rel="stylesheet" type="text/css" />
         <link href="yyy.css" rel="stylesheet" type="text/css" />
         <link href="zzz.css" rel="stylesheet" type="text/css" />
    </head>
    <body>
        <!-- HTML content here -->
        <script src="xxx.js"></script>
        <script src="yyy.js"></script>
        <script src="zzz.js"></script>
    </body>
</html>

6. قلّلوا زمن الاستجابة الأولية للخادم

زمن الاستجابة الأولية للخادم هو الوقت بين بدء المتصفح في إرسال الطلب إلى الخادم وإعادة الخادم للاستجابة إلى المتصفح. ويعتمد هذا الزمن على طريقة معالجة خادم الويب للبيانات وطريقة عرضها. ولتقليل هذا الزمن، لدينا أساليب مختلفة في الواجهة الأمامية (frontend) والخلفية (backend).

1. في تطبيقات الواجهة الأمامية، قد نقرر بناء تطبيق من صفحة واحدة (single page application) يحمّله المستخدم مرة واحدة، ثم يُعرض ويعمل في متصفحه دون إعادة العرض مرات متعددة، ويمكن تحسين الطلبات اللاحقة لتكون أصغر. أما إذا بنينا الموقع بتقنية العرض من جهة الخادم (server-side rendering)، فينبغي أن نستفيد من تخزين الصفحات مؤقتًا (page caching). والـ page cache ملف يخزّن نتائج العرض. فحين يطلب المستخدمون عنوان URI معينًا لأول مرة سيكون هناك بعض التأخير، لكن إذا طلبوا العنوان نفسه بعد ذلك فستأتي الاستجابة فورًا من الـ page cache بدلًا من معالجة الصفحة وعرضها في كل مرة.
2. ولتقليل زمن استجابة واجهة API، فكروا في التخزين المؤقت للكائنات أو لقاعدة البيانات. وحددوا أي أجزاء تطبيقكم يمكن تخزينها مؤقتًا. فمثلًا، قد لا تتغير فئات البيانات وأنواعها كثيرًا، فيمكنكم تخزينها مؤقتًا لتقليل زمن الاستجابة.

الخلاصة

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