لماذا نحتاج تحسين الرموز البرمجية؟

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

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

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

الترميزات الرائجة

إذن ما هي أكثر الرموز المتكررة شيوعًا؟

1. تعليقات HTML في البرامج النصية

واحدة من الإجماليات المتكررة في الوقت الحاضر هي تضمين تعليقات HTML — <!-- --> — في كتل البرنامج النصي. لا يوجد الكثير ليقال هنا ، باستثناء أن المتصفحات التي تحتاج بالفعل إلى هذا الإجراء لمنع الأخطاء (مثل '95 Netscape 1.0 ) منقرضة إلى حد كبير. التعليقات في النصوص ليست سوى رموزًا غير ضرورية ويجب إزالتها.

2. أقسام <! [CDATA […]>

هناك إجراء آخر غير ضروري في الغالب للوقاية من الأخطاء وهو تضمين كتل CDATA في عناصر SCRIPT:

  <script type="text/javascript">
    //<![CDATA[
      ...
    //]]>
  </script>
  

إنه هدف نبيل لا يرقى إلى الواقع. على الرغم من أن كتل CDATA هي طريقة جيدة تمامًا لمنع معالج XML من التعرف على  <  و  &  كبداية للترميز ، إلا أن هذه هي الحالة فقط في مستندات XHTML الحقيقية - تلك التي يتم تقديمها مع نوع المحتوى "application / xhtml + xml".
لا يزال يتم تقديم غالبية الويب كـ "text / html" (حيث ، على سبيل المثال ، لا يفهمها IE XHTML حتى هذا التاريخ) ، وبالتالي يتم تحليله على أنه HTML بواسطة المتصفحات ، وليس بتنسيق XML.

ما لم تكن تعرض المستندات باسم "application / xhtml + xml" ، فلا يوجد سبب وجيه لتعليق أقسام CDATA. حتى إذا كنت تخطط لاستخدام xhtml في المستقبل ، فقد يكون من المنطقي إزالة الوزن غير الضروري من المستند ، وإضافته لاحقًا فقط عند الحاجة.

وبالطبع ، فإن الحل النهائي هنا هو تجنب البرامج النصية المضمنة تمامًا (للاستفادة من التخزين المؤقت للبرامج النصية الخارجية).

3. إستخدامات onclick و onmouseover ...الخ.

هناك بعض حالات الاستخدام الصالحة لسمات الحدث الجوهرية ، مثل لأسباب الأداء أو لاستهداف المتصفحات القديمة (على الرغم من أنني لست على دراية بأي بيئة من شأنها أن تفهم سمات الحدث -  onclick="..."  وليس التعيينات المستندة إلى الملكية - ( element.onclick = ...). بالإضافة إلى الأسباب المعروفة لتجنبها ، مثل فصل المخاوف وإعادة الاستخدام ، هناك مسألة تلوث ترميز. من خلال نقل منطق الحدث إلى برنامج نصي خارجي ، يمكننا الاستفادة من التخزين المؤقت لهذا البرنامج النصي . لا يلزم نقل منطق معالج الأحداث إلى العميل في كل مرة يتم فيها طلب المستند.

4. onclick = "javascript:…"

الخلط المثير للاهتمام لجافا سكريبت: ينتج عن البروتوكول الزائف ومعالجات الأحداث الجوهرية هذا المزيج الزائد (مع 106000 مرة (!)). والحقيقة هي أن المحتويات الكاملة لسمة معالج الأحداث تصبح نصًا لدالة. تعمل هذه الوظيفة بعد ذلك كمعالج للأحداث (عادة ، بعد زيادة نطاقها ليشمل بعض أو كل الأسلاف والعنصر نفسه). إضافة "javascript:" تصبح مجرد تسمية غير ضرورية ونادرًا ما تخدم أي غرض.

5. href = "javascript: void (0)"

6. style="…"

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

7. <script language=”Javascript” … >

سوء فهم آخر لعنصر SCRIPT هو أنه مع سمة charset. أحيانًا أرى مستندات تتضمن هذا النوع من الترميز:

   <script type="text/javascript" charset="UTF-8">
    ...
  </script>
  

الشيء هو أن سمة charset منطقية فقط على عناصر SCRIPT "الخارجية" - تلك التي لها سمة "src". يقول HTML 4.01 حتى:
لاحظ أن سمة charset تشير إلى ترميز الأحرف للنص البرمجي المحدد بواسطة سمة src ؛ لا تتعلق بمحتوى عنصر SCRIPT.
يُظهر الاختبار أن سلوك المتصفحات الفعلي يتطابق أيضًا مع المواصفات في هذا الصدد.
البحث عن هذا النمط يكشف عن 2000 حالة . ليس مفاجئًا ، نظرًا لأنه حتى التطبيقات الشائعة مثل Textmate تتضمن استخدامًا خاطئًا لـ charset .

تحسينات إضافية

لقد غطينا بعض الممارسات السيئة التي يجب تجنبها دائمًا تقريبًا. ولكن لا يزال هناك المزيد في المستقبل ، وأن "المزيد" يزيل الأجزاء الزائدة . غالبًا ما تكون التحسينات الموضحة أدناه موضع تساؤل ، حيث إنها تعرض وضوح الحجم للخطر . لذا فأنا أدرجها هنا ليس كتوصية ، ولكن فقط كخيار. العمل مع النظر بعناية.
يحدد HTML 4.01 سمة الوسائط على عناصر STYLE ، كوسيلة لاستهداف شاشة متوسطة معينة ، وطباعة ، وحمل يدوي ، وما إلى ذلك. إن إحدى القيم المحتملة لوسائل الإعلام هي "الكل" ، والذي يحدث أيضًا كمعيار فعلي بين المتصفحات الحديثة (وليس الحديثة جدًا). إذا وجدت نفسك تستخدم  media="all" ، يجب أن يكون من الآمن حذفه والسماح للمتصفح بتعيين القيمة بشكل ضمني.
ومن المثير للاهتمام أن HTML 4.01 ينص على أن القيمة الافتراضية للوسائط هي "screen". ومع ذلك ، لا يقوم أي من المتصفحات التي قمت باختبارها بتطبيقها وفقًا للمواصفات ، ويكون الإعداد الافتراضي هو "الكل" بدلاً من ذلك. ربما يكون هذا هو السبب في أن مسودة HTML 5 تحدد القيمة الافتراضية على أنها "all" - لمطابقة سلوك المتصفحات الفعلي.

2. <form method = "get"…>

غالبًا ما يتم تحديد قيمة افتراضية أخرى - GET - للسمة "method" الخاصة بعنصر FORM بشكل صريح . ليس هناك ضرر في إسقاطه ، باستثناء وضوح أقل. لاحظ أن مسودة HTML 5 تترك هذا السلوك دون تغيير .

3. <input type=”text” …>

افتراضيات "نوع" عنصر INPUT إلى "text" في كل من - مسودة HTML 4.01 و HTML 5 . يمكن أن يؤدي إسقاط هذه السمة إلى توفير كبير في الحجم على الصفحات التي تحتوي على الكثير من حقول النص.

4. <meta http-equiv=”Content-type” …>

لطالما كان تحديد ترميز أحرف المستند مصدرًا للارتباك الكبير. خلافا للاعتقاد الشائع ، عنصر META الذي يحدد نوع المحتوى ليس له أولوية أعلى على رأس HTTP "Content-type" الذي يتم تقديم المستند معه. عند تحديد كل من - رأس وعنصر META ، يكون للرأس الأسبقية.

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

5. <a id=”…” name=”…” …>

السبب الرئيسي وراء استخدام سمة "name" مع "id" هو التوافق مع المتصفحات القديمة (مثل Netscape 4). لم يتمكنوا من الربط بالمراسي بواسطة "id" ، لذلك كان يجب استخدام "name". إذا كان لديك عناصر مع اسم / معرف الاقتران ، ولا تهتم بالمتصفحات القديمة ، فلا تتردد في التخلص من هذا النمط القديم.

احترس من أي آثار جانبية. إذا كنت تشير إلى عناصر بالاسم في النصوص البرمجية (document.getElementsByName ، document.evaluate ، document.querySelectorAll ، وما إلى ذلك) ، فقد يؤدي استبدال الاسم بمعرف إلى كسر الأشياء. تذكر أيضًا أن document.anchors تُرجع فقط العناصر ذات سمات الاسم.

6. <!doctype html>

قبل أكثر من عام بقليل ، اعتزم داستن دياز استخدام نوع HTML 5 كطريقة لخفض حجم المستند. هذا ليس تحسينًا رئيسيًا ، ولكن إذا كنت لا تهتم بالتحقق من الصحة وتحتاج إلى ضغط كل بايت من الصفحة ، فإن استخدام <! doctype html> هو خيار قابل للتطبيق. كشفت الاختبارات أن هذا النموذج الرائع يثير وضع المعايير في مجموعة كبيرة ومتنوعة من المتصفحات.

تحسينات إضافية

إذا كنت لا تزال تتوق إلى المزيد ، فإليك بعض الأفكار الإضافية. بعض هذه (مثل حذف العلامات الاختيارية) تم تداولها لفترة من الوقت. البعض الآخر لم أسمع ذكره. على الرغم من أن هذه قد تبدو مزعجة للغاية ، لاحظ أنه لا أحد منهم يبطل مستندًا. هذا إذا كان المستند بتنسيق HTML ، وليس XHTML. ولكنك تعرض المستندات بتنسيق HTML على أي حال ، أليس كذلك؟ ؛)

1. إزالة تعليقات HTML
2. قم بإزالة / تصغير المسافات البيضاء
3. إزالة علامات الإغلاق الاختيارية ( <p>foo</p>→ <p>foo)
4. إزالة علامات الاقتباس حول قيم السمات ، عندما يُسمح بذلك ( <p class="foo">→ <p class=foo>)
5. إزالة القيم الاختيارية من السمات المنطقية ( <option selected="selected">→ <option selected>)
6. دمج الأنماط المضمنة والنصوص المضمنة وسمات الأحداث (إذا لم يكن من الممكن إزالتها)
7. دمج الفئات والمعرفات (يجب أن تكون متزامنة مع البرامج النصية وإعلانات النمط)
8. إزالة مخطط النظام من الروابط  (http://example.com → //example.com)

تحويل هذا المستند النظيف تمامًا:

   <html>
    <head>
      <title></title>
    </head>
    <body>
      <div>
        <ul>
          <li>foo</li><li>bar</li><li>baz</li>
          <!-- few more dozens of list elements ... -->
        </ul>
      </div>
    </body>
  </html>
  

في هذه الفوضى:

   <!--hcpage status="compressed"-->
<html>
  <head>
    <SCRIPT LANGUAGE="JavaScript" SRC="hc_decoder.js"></SCRIPT>
    <title></title>
  </head>
  <BODY>
    <NOSCRIPT>To display this page you need a browser with JavaScript support.</NOSCRIPT>
    <SCRIPT LANGUAGE="JavaScript">
      <!--
        hc_d0("Mv#d|\x3C:,&c@w4YFAtD1 [... and so on, another couple hundreds of characters ...]");
      //-->
    </SCRIPT>
  </BODY>
</html>

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

مضادات

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

1. إزالة Doctype

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

2. إستبدال STRONG بـ B و  EM بـ I

خيار ضار آخر في نفس ضاغط HTML هو استبدال العناصر بـ "بدائلها" الأقصر. المشكلة هنا هي أن B ليس في الحقيقة بديلاً عن STRONG. ولا I بديل عن EM. عناصر STRONG وEM لها معنى دلالة - التركيز، بينما B و I هي ببساطة عناصر نمط الخط ؛ إنها تؤثر على عرض النص ، ولكن ليس لها معنى دلالة.
على الرغم من أن المتصفحات تعرض هذه العناصر بشكل متماثل ، إلا أن قارئي الشاشة ومحركات البحث يفهمون الاختلاف كثيرًا.

3. إزالة عناصر  title, alt,attributes وعناصر LABEL.

من القواعد الأساسية الجيدة عدم التحسين أبدًا في مقابل إمكانية الوصول . قد تميل إلى إزالة تلك السمة "alt" الاختيارية على عناصر IMG ، أو "title" في المراسي ، ولكن حفظ عشرات البايتات لا يستحق فقدان إمكانية الوصول في كثير من الأحيان.

الاعتبارات المستقبلية
في حين أنه يمكن (ويجب) القيام بعملية السحق والتجريد أثناء الإنتاج ، فإن تحسين الترميز هي شيء لا يجب أن يحدث في المقام الأول . لا في الإنتاج ولا في التنمية. ليس إلا لسبب ما ، فهي ضرورية للغاية.
من غير المستغرب أن أفضل تحسين يمكن القيام به غالبًا ما يكون يدويًا: تغيير بنية المستند لتجنب تكرار الفئات على عناصر متعددة (وبدلاً من ذلك نقلها إلى العنصر الأصلي) ، أو التخلص من القطع غير المطلوبة على الفور ، وبدلاً من ذلك تحميلها ديناميكيًا. استبدال المرياد من <br>'s أو &nbsp;' s المستخدمة بشكل غير فعال لأغراض العرض ، أو أن التصميم القديم القائم على الطاولة هي أمثلة جيدة أخرى للتنظيف اليدوي.

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

---

المتصفحات المختبرة هي:
Firefox 1، 1.5، 2، 3، 3.5؛
أوبرا 7.54 ، 8.54 ، 9.27 ، 9.64 ، 10.10 ؛
Safari 2.0.4 ، 3.0.4 ، 4 ؛
Chrome 4 - على نظام التشغيل Mac OS X 10.6.2.
Internet Explorer 6 و 7 و 8 على Windows XP Pro SP2 و
Konqueror 4.3.2 على Ubuntu 9.10.