تحسين CSS وجافاسكريبت

قبل أي تحسين، زِن ما هو موجود فعلا

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

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

curl -s https://example.com/ \
  | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | sort -u \
  | while read u; do printf '%8s  %s\n' \
      "$(curl -s -o /dev/null -H 'Accept-Encoding: gzip' -w '%{size_download}' "$u")" "$u"; done

وفي هذا الأمر فخ وقعنا فيه بأنفسنا: إن حوى عنوان في HTML علامة & كُتب على هيئة & فيبلّغ ذلك السطر صفر بايت. والصفر يعني أنه لم يُقَس، لا أنه خفيف. أصلح ذلك السطر يدويا أو تجاهله.

وكان ناتج هذا الأمر على إحدى صفحاتنا، من الأثقل إلى الأخف: ١٧١.١ كيلوبايت لملف تحليلات غوغل، و٢٩.٩ كيلوبايت لمكتبة jQuery، و٥.٩ كيلوبايت لسكربتنا الرئيسي، و١.٩ كيلوبايت لحاسبة أسعار، وأقل من كيلوبايت لسكربت كابتشا. أما سكربت كابتشا كلاودفلير فعلى نطاقهم هم وعاد من سطر الأوامر بصفر، فتركناه خارج الحساب ونقول هنا صراحة إننا لا نعرف حجمه.

والآن اجمع. فما كتبناه ٧.٨ كيلوبايت وما لم نكتبه ٢٠١.٥ كيلوبايت. أي إن ٩٦.٣ بالمئة من وزن جافاسكريبت الذي ترسله تلك الصفحة كود لغيرنا. ولا قدر من التصغير يزحزح هذه النسبة.

كم يوفر التصغير؟ اقرأ الرقم بعد الضغط

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

قسنا ورقة الأنماط الرئيسية لهذا الموقع بطريقتين، مرة خاما ومرة مضغوطة بأداة gzip كما تُرسل فعلا. الأصل ١٢٩.٠ كيلوبايت ويُضغط إلى ٣٢.٣ كيلوبايت. والنسخة المصغّرة ٧٩.١ كيلوبايت وتُضغط إلى ١٦.٣ كيلوبايت.

والآن ضع التوفيرين جنبا إلى جنب. على الورق أزال التصغير ٤٩.٩ كيلوبايت، أي قرابة ٣٩ بالمئة، وهذا هو الرقم الذي يعرضه تقرير أداتك. وعلى السلك أزال العمل نفسه ١٦.٠ كيلوبايت. والرقمان صحيحان ولا يؤثر في السرعة إلا الثاني.

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

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

defer أم async؛ أيهما وأين

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

مع defer يبدأ المتصفح تنزيل الملف فورا لكنه يؤجل تنفيذه إلى أن تُبنى الصفحة، وعدة سكربتات بهذه الصفة تُنفَّذ بالترتيب الذي وردت به في الصفحة. ومع async يبدأ التنزيل فورا أيضا لكن التنفيذ يقع لحظة جهوز الملف أيا كان موضع العمل، ولا ضمان للترتيب البتة.

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

والآن ما تقوله الدروس أقل وهو أهم عمليا: موضع السكربت في المستند. فإن كانت كل السكربتات في ذيل الجسد، فحتى السكربت بلا صفة لا يحجب إلا القليل، لأن الصفحة قد بُنيت حينها. وعلى الصفحة الأولى لهذا الموقع يقع أول سكربت عند ٩٦.٦ بالمئة من المستند، ولا سكربت خارجيا في head البتة. وثلاثة سكربتات هناك ما زالت بلا صفة ولم نصلحها، لأن الإضافة التي تدرجها تقرر عنا.

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

CSS الحرج والتضمين؛ مكسب له ثمن

كل ورقة أنماط خارجية مورد يحجب الرسم: فالمتصفح لا يرسم شيئا حتى يحصل عليها. والجواب الشائع هو CSS الحرج، أي كتابة الجزء اللازم للمنظر الأول داخل الصفحة نفسها وترك الباقي يصل لاحقا. وقد ذهبنا خطوة أبعد فنضمّن ورقة الأنماط كلها؛ فعلى الصفحة الأولى لهذا الموقع لا وجود لوسم link rel=stylesheet البتة، وكل القواعد في أربع كتل أنماط داخل الرأس.

ولهذا القرار مكسب وندفع ثمنه، ولأن أحدا لا يكاد يكتب الثمن فإليك ثمننا. أخذنا HTML نفسه واستبدلنا بكتلة الأنماط الرئيسية رابطا خارجيا وضغطنا النسختين. فالنسخة المرسلة فعلا ٤١.٨ كيلوبايت والنسخة بورقة خارجية ٢٦.٠ كيلوبايت. أي إن التضمين يضيف ١٥.٨ كيلوبايت إلى كل استجابة HTML، لكل زيارة، في كل مرة.

ونقطة التعادل حساب بسيط. فالزائر الذي يرى صفحة واحدة ويمضي لا يدفع زيادة، لأنه كان سيجلب ذلك CSS في الحالين. أما من يرى خمس صفحات فيجلب ١٥.٨ كيلوبايت نفسها أربع مرات أخرى، بينما كانت الورقة الخارجية تُجلب مرة وتأتي من كاش المتصفح بعدها. فهذا الاختيار يتوقف على شكل حركتك لا على قاعدة عامة: فالموقع الذي تأتي زياراته غالبا من البحث وتنتهي عند صفحة واحدة يربح بالتضمين.

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

وتحذير بشأن أدوات CSS الحرج: يجب النظر في مخرجاتها. فهذه الأدوات تقرر أي القواعد يحتاجها المنظر الأول، وتخطئ على الصفحات التي يختلف تخطيطها عن غيرها. والنتيجة صفحة تومض بلا تنسيق لحظة، وهذا أسوأ من ورقة أنماط حاجبة.

الكود الذي لم تكتبه

هنا يتخذ الدرس موقفا، ويتخذه ضدنا نحن: فكل ما وصفته الأقسام الأربعة أعلاه يُطبَّق على الكود الذي كتبته أنت، وعلى الموقع المتوسط يكون الكود الذي كتبته أنت هو الأقلية.

على صفحتنا تلك نفسها، jQuery ٢٩.٩ كيلوبايت. ولا نستعمل منه سطرا ولا كتبنا منه سطرا؛ فالإضافة الأمنية التي تضع الكابتشا تحتاجه ووردبريس يرسله. وملف التحليلات ١٧١.١ كيلوبايت وهو أيضا لغوغل، وإنما يُستضاف على خادمنا. ومجموع هذين مع سكربت الكابتشا ٢٠١.٥ كيلوبايت، مقابل ٧.٨ كيلوبايت من كودنا.

والآن المقصد: لا يُحَل أي منهما بالتحسين. فمكتبة jQuery مصغّرة أصلا وتنضغط. وكذلك ملف التحليلات. وكلاهما يخرج من طريق الرسم بوسم async أو defer، ويظل كلاهما يأخذ العدد نفسه من البايتات من اتصال الزائر والقدر نفسه من معالج هاتفه. والقرار الوحيد الذي يغير هذه الأرقام هو أتريد تلك الميزة أصلا أم لا.

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

فترتيب عملك إذن هكذا. خذ القائمة أولا. ثم اسأل عن كل سطر: أي ميزة يقدم، وهل تلزم تلك الميزة على هذه الصفحة. وأخّر ما بقي، وصغّر ما بقي بعد ذلك. واعكس الترتيب تقضِ ساعات على بضعة كيلوبايتات ولا ترى الرقم ١٧١ أبدا. وإن كان سؤالك التالي كم يلزم موقعك من جافاسكريبت أصلا، فجوابه في درس تعلم جافاسكريبت للمبتدئين.