إعادة هيكلة CSS: تحسين الحجم والأداء (الجزء 3)

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

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

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

تحسين حجم ملف ورقة الأنماط

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

التحسين والتصغير

لقد كان تحسين CSS وتصغيره موجودًا منذ سنوات وأصبح عنصرًا أساسيًا في تحسين الواجهة الأمامية. أدوات مثل cssnano و clean-css هي من بين أدواتي المفضلة عندما يتعلق الأمر بتحسين CSS وتصغيره. أنها توفر مجموعة متنوعة من خيارات التخصيص لمزيد من التحكم في كيفية تحسين التعليمات البرمجية والمتصفحات المدعومة.

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

 /* Before - original and unoptimized code */ .container { padding: 24px 16px 24px 16px; background: #222222; } /* After - optimized code with formatting */ .container { padding: 24px 16px; background: #222; }

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

 /* Before - optimized code with formatting */ .container { padding: 24px 16px; background: #222; } /* After - optimized and minified code */ .container{padding:24px 16px;background:#222}

حتى في هذا المثال الأساسي ، تمكنا من تقليل الحجم الإجمالي للملف من 76 بايت إلى 55 بايت ، مما أدى إلى تقليل حجم الملف بنسبة 23٪. اعتمادًا على قاعدة التعليمات البرمجية وأدوات التحسين والتكوين ، يمكن أن يكون تحسين CSS وتصغيره أكثر فعالية.

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

تحسين استعلامات الوسائط

عندما نكتب استعلامات وسائط في CSS ، خاصةً عند استخدام ملفات متعددة (PostCSS أو Sass) ، فإننا عادةً لا ندمج الكود ضمن استعلام وسائط واحد لمشروع بأكمله. لتحسين قابلية الصيانة والنمطية وهيكل الكود ، نكتب عادةً نفس تعبيرات استعلام الوسائط لمكونات CSS المتعددة.

دعنا نفكر في المثال التالي لقاعدة كود CSS غير المحسّنة.

 .page { display: grid; grid-gap: 16px; } @media (min-width: 768px) { .page { grid-template-columns: 268px auto; grid-gap: 24px; } } /* ... */ .products-grid { display: grid; grid-template-columns: repeat(2, 1fr); grid-gap: 16px; } @media (min-width: 768px) { .products-grid { grid-template-columns: repeat(3, 1fr); grid-gap: 20px; } }

كما ترى ، لديناmedia متكرر @media (min-width: 768px) لكل مكون لتحسين سهولة القراءة والصيانة. دعنا نجري التحسين والتصغير في مثال الكود هذا ونرى ما نحصل عليه.

 .page{display:grid;grid-gap:16px}@media (min-width: 768px){.page{grid-template-columns:268px auto;grid-gap:24px}}.products-grid{display:grid;grid-template-columns:repeat(2,1fr);grid-gap:16px}@media (min-width: 768px){.products-grid{grid-template-columns:repeat(3,1fr);grid-gap:20px}}

قد يكون هذا صعبًا بعض الشيء في القراءة ، ولكن كل ما يجب أن نلاحظه هو استعلام الوسائط المتكررmedia @media (min-width: 768px) . لقد توصلنا بالفعل إلى أننا نريد تقليل عدد الأحرف في ورقة الأنماط ويمكننا تداخل محددات متعددة ضمن استعلام وسائط واحد ، فلماذا لم يقم المصغر بإزالة التعبير المكرر؟ هناك سبب بسيط لذلك.

ترتيب القواعد مهم في CSS ، لذلك لدمج استعلامات الوسائط المكررة ، يجب نقل كتل التعليمات البرمجية. سيؤدي هذا إلى تغيير أوامر القواعد مما قد يتسبب في آثار جانبية غير مرغوب فيها في الأنماط.

ومع ذلك ، فإن الجمع بين استعلامات الوسائط يمكن أن يجعل حجم الملف أصغر ، اعتمادًا على قاعدة التعليمات البرمجية والهيكل. تسمح لنا الأدوات والحزم مثل postcss-sort-media-queries بإزالة استعلامات الوسائط المكررة وتقليل حجم الملف بشكل أكبر.

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

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

إزالة CSS غير المستخدمة

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

تنتقل أدوات مثل purgecss إلى جميع الملفات في المشروع وتستخدم جميع الفئات المذكورة في الملفات كمحددات ، فقط للخطأ في جانب الحذر وعدم حذف المحددات عن طريق الخطأ للعناصر الديناميكية المحقونة في JavaScript ، من بين حالات أخرى محتملة. ومع ذلك ، تقدم purgecss خيارات تكوين مرنة كحلول لهذه المشكلات والمخاطر المحتملة.

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

التخلص من CSS لحظر العرض

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

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

أصبح Largest Contentful Paint (LCP) مقياسًا مهمًا في الأشهر القليلة الماضية. لا يعد LCP مهمًا للأداء فحسب ، بل يعد مهمًا أيضًا لتحسين محركات البحث - المواقع التي تحقق نتائج LCP أفضل سيكون لها ترتيب أفضل لنتائج البحث. تعد إزالة موارد حظر العرض مثل CSS إحدى طرق تحسين درجة LCP.

ومع ذلك ، إذا قمنا بتأجيل تحميل ورقة الأنماط ومعالجتها ، فقد ينتج عن ذلك Flash Of Unstyled Content (FOUC) - سيتم عرض المحتوى للمستخدم على الفور وسيتم تحميل الأنماط وتطبيقها بعد لحظات قليلة. قد يبدو رمز التبديل هذا مزعجًا وقد يؤدي إلى إرباك بعض المستخدمين.

CSS الحرجة

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

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

 <head> <style type="text/css"><!-- Minified Critical CSS markup --></style> </head>

هناك العديد من الأدوات الآلية وحزم NPM المتاحة ، اعتمادًا على الإعداد الخاص بك ، والتي يمكنها استخراج CSS الهامة وإنشاء أوراق أنماط مؤجلة.

إرجاء أوراق الأنماط

كيف بالضبط نجعل CSS غير محظور؟ نحن نعلم أنه لا يجب الإشارة إليه في عنصر head HTML عند تنزيل صفحة HTML لأول مرة. أوضح ديميان رينزولي هذه الطريقة في مقالته.

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

 <!-- Deferred stylesheet --> <link rel="preload" as="style" href="path/to/stylesheet.css" onload="this.onload=null;this.rel='stylesheet'"> <!-- Fallback --> <noscript> <link rel="stylesheet" href="path/to/stylesheet.css"> </noscript>

باستخدام link rel="preload" as="style" يتأكد من أن ملف ورقة الأنماط مطلوب بشكل غير متزامن ، بينما يتأكد معالج JavaScript أثناء onload من تحميل الملف ومعالجته بواسطة المتصفح بعد انتهاء تحميل مستند HTML. هناك حاجة إلى بعض عمليات التنظيف ، لذلك نحن بحاجة إلى ضبط onload على null لتجنب تشغيل هذه الوظيفة عدة مرات والتسبب في عمليات إعادة تصيير غير ضرورية.

هذا هو بالضبط كيف تتعامل Smashing Magazine مع أوراق الأنماط الخاصة بها. يحتوي كل قالب (الصفحة الرئيسية ، وفئات المقالات ، وصفحات المقالات ، وما إلى ذلك) على CSS هام خاص بالقالب مضمن داخل علامة style HTML في عنصر head ، وورقة أنماط main.css مؤجلة تحتوي على جميع الأنماط غير الهامة.

ومع ذلك ، بدلاً من تبديل المعلمة rel ، يمكننا هنا رؤية استعلام الوسائط يتم تبديله من وسائط print ذات الأولوية المنخفضة المؤجلة تلقائيًا إلى سمة all ذات الأولوية العالية عند انتهاء تحميل الصفحة. هذا هو نهج بديل وقابل للتطبيق على قدم المساواة لتأجيل تحميل أوراق الأنماط غير الهامة.

 <link href="/css/main.css" media="print" onload="this.media='all'" rel="stylesheet">

تقسيم أوراق الأنماط وتحميلها شرطيًا باستخدام استعلامات الوسائط

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

 <link href="print.css" rel="stylesheet" media="print"> <link href="mobile.css" rel="stylesheet" media="all"> <link href="tablet.css" rel="stylesheet" media="screen and (min-width: 768px)"> <link href="desktop.css" rel="stylesheet" media="screen and (min-width: 1366px)">

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

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

إرجاء ملفات الخطوط وأوراق الأنماط

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

يعد تحميل أوراق أنماط الخطوط وملفات الخطوط موضوعًا معقدًا وسيستغرق الغوص فيه مقالة جديدة بالكامل لشرح جميع الأساليب القابلة للتطبيق. لحسن الحظ ، حدد Zach Leatherman العديد من الاستراتيجيات القابلة للتطبيق في هذا الدليل الشامل الرائع ولخص إيجابيات وسلبيات كل نهج. إذا كنت تستخدم Google Fonts ، فقد حدد Harry Roberts استراتيجية لتحميل أسرع لخطوط Google.

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

حدد باري بولارد بعض الاستراتيجيات التي يمكن أن تساعدنا في التعامل مع FOUT وتحدث عن ميزة CSS لضبط الحجم القادمة والتي ستوفر طريقة أسهل وأكثر أصالة للتعامل مع FOUT.

تحسينات من جانب الخادم

ضغط HTTP

بالإضافة إلى التصغير وتحسين حجم الملف ، يمكن استخدام الأصول الثابتة مثل HTML وملفات CSS وملفات JavaScript وما إلى ذلك. يمكن استخدام خوارزميات ضغط HTTP مثل Gzip و Brotli لتقليل حجم الملف الذي تم تنزيله بشكل إضافي.

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

أوراق الأنماط التخزين المؤقت

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

يمكن التحكم في التخزين المؤقت عبر رأس HTTP Cache-Control على مستوى الخادم (على سبيل المثال ، باستخدام ملف .htaccess على خادم Apache).

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

 Cache-Control: public, max-age=604800

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

 Cache-Control: public, max-age=604800, immutable

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

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

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

• إلحاق سلسلة استعلام باسم الملف.
  على سبيل المثال styles.css?v=1.0.1. ومع ذلك ، يمكن لبعض شبكات CDN أن تتجاهل أو تجرد سلسلة الاستعلام تمامًا من اسم الملف مما يؤدي إلى توقف الملف في ذاكرة التخزين المؤقت للمستخدم وعدم التحديث مطلقًا.
• تغيير اسم الملف أو إلحاق تجزئة.
  على سبيل المثال styles.a1bc2.css أو styles.v1.0.1.css. يعد هذا أكثر موثوقية وفعالية من إلحاق سلسلة استعلام باسم الملف.

CDN أو الاستضافة الذاتية؟

شبكة توصيل المحتوى (CDN) عبارة عن مجموعة من الخوادم الموزعة جغرافيًا والتي تُستخدم بشكل شائع للتسليم الموثوق والسريع للأصول الثابتة مثل الصور ومقاطع الفيديو وملفات HTML وملفات CSS وملفات JavaScript وما إلى ذلك.

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

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

ومع ذلك ، أوصي بالاستضافة الذاتية لأوراق الأنماط (يتم تضمين أوراق أنماط الخطوط ، إن أمكن) افتراضيًا والانتقال إلى CDN فقط إذا كانت هناك أسباب قابلة للتطبيق أو مزايا أخرى للقيام بذلك.

تدقيق حجم وأداء ملف CSS

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

دعونا نجري تدقيقًا للأداء على موقع ويب مذكور في المقالة الأولى من هذه السلسلة - الموقع الذي يحتوي على 2 ميجابايت من CSS المصغر.

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

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

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

خاتمة

لا تكتمل عملية إعادة البناء عندما يتم تحسين صحة الكود وجودته وعندما يتم إصلاح نقاط الضعف والمشكلات في قاعدة التعليمات البرمجية. يجب أن ينتج عن قاعدة الكود المعاد تصميمها نفس الأداء أو تحسينه مقارنةً بقاعدة الكود القديمة.

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

يمكننا استخدام العديد من أدوات تدقيق الأداء مثل WebPageTest للحصول على نظرة عامة مفصلة عن أوقات التحميل والأداء وموارد حظر العرض وعوامل أخرى حتى نتمكن من معالجة هذه المشكلات مبكرًا وبفعالية.

مراجع

• “Render Blocking CSS،” Ilya Grigorik
• "تأجيل CSS غير الحرجة ،" دميان رينزولي
• "دليل شامل لاستراتيجيات تحميل الخط" ، زاك ليثرمان
• "طريقة جديدة لتقليل تأثير تحميل الخط: واصفات خطوط CSS" ، باري بولارد
• "المضيف الذاتي لأصولك الثابتة ،" هاري روبرتس
• "تحسين تحميل WebFont والعرض" ، إيليا غريغوريك