تصغير الشفرة

الخلاصة — يعني تصغير الشفرة إزالة ما لا تحتاج إليه شفرتك كي تعمل — المسافات وفواصل الأسطر والتعليقات — من CSS وJavaScript وHTML. يظل الملف يعمل بالطريقة نفسها تمامًا، لكنه يصير أصغر فيُنزل أسرع قليلًا. إن طلب منك PageSpeed Insights يومًا «Minify CSS» أو «Minify JavaScript»، فهذا هو الإصلاح. وهو ليس الضغط.

ما تصغير الشفرة

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

تصغير الشفرة هو العملية الآلية التي تزيل هذا الحمل. يأخذ المصغّر ملف المصدر ويزيل منه:

• المسافات وعلامات الجدولة وفواصل الأسطر
• التعليقات
• ويمكنه في CSS وJavaScript أن يذهب أبعد، فيقصّر أسماء المتغيرات الطويلة ويطوي البنية الزائدة

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

أين ستصادفه

يصادف الجميع تقريبًا تصغير الشفرة بالطريقة نفسها: يشغّلون موقعهم عبر Google PageSpeed Insights أو Lighthouse، فيرون تحذيرًا يقول «Minify CSS» أو «Minify JavaScript» مع ملاحظة بإمكان توفير بضعة كيلوبايتات. وهذا التحذير هو ما يدفع معظم الناس إلى البحث عن معنى الأمر أصلًا.

الخطأ الوحيد الذي يقع فيه الناس

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

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

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

هل تحتاج أصلًا إلى فعل ذلك بنفسك؟

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

أتريد النسخة الكاملة — كيف يعمل لكل نوع ملف، وآلية تدقيق PageSpeed، وما تنفذه أدوات التجميع الحديثة نيابة عنك، والأدوات التي تسميها Google، وهل يمس SEO أصلًا؟ انتقل إلى علامة التبويب متقدم.

الخلاصة — يزيل تصغير الشفرة المحارف التي لا يحتاج إليها الملف ليعمل — المسافات البيضاء وفواصل الأسطر والتعليقات، وكذلك أسماء المعرّفات الطويلة والبنية الزائدة في CSS/JS — من مصدر CSS وJS وHTML من دون تغيير طريقة تحليل المتصفح له أو تنفيذه. تعرّفه وثائق Lighthouse من Google وتدققه باسمَي unminified-css و unminified-javascript. احسم أهم التباس أولًا: التصغير ≠ الضغط (Gzip/Brotli، وهو ترميز في طبقة النقل يطبق فوقه — صغّر أولًا ثم اضغط)، كما أنه ≠ الربط/التجميع (دمج الملفات لخفض طلبات HTTP) أو tree-shaking/إزالة الشفرة الميتة (إثبات تعذر الوصول إلى الشفرة). يمكن لمصغرات CSS/JS أن تكون شديدة، أما تصغير HTML فأضحل وأعلى مخاطرة. لا توجد نسبة توفير عامة؛ قِس ملفاتك. والملف الأصغر لا يثبت وحده تنفيذًا أقل أو تحسنًا في Core Web Vitals/البحث؛ إنه تحسين مساند، لا حل سحري، وليس عامل ترتيب مباشرًا. تصغر أدوات التجميع الحديثة (Webpack وVite وNext.js وesbuild) مخرجات الإنتاج افتراضيًا، لذلك يظهر التدقيق أساسًا للمواقع القديمة أو الشفرة المضمنة أو أصول الجهات الخارجية/الإضافات. ومن الأدوات المسماة: HTMLMinifier وCSSNano/csso وUglifyJS/Terser/Closure Compiler.

ما تصغير الشفرة فعلًا

تصغير الشفرة هو إزالة المحارف التي لا يحتاج إليها الملف كي يُحلل أو يُنفذ. وتصوغ وثائق Lighthouse من Google ذلك بوضوح في تدقيق JavaScript: “Minification is the process of removing whitespace and any code that is not necessary to create a smaller but perfectly valid code file.” (ترجمة) «تصغير الشفرة هو عملية إزالة المسافات البيضاء وأي شفرة غير لازمة لإنشاء ملف شفرة أصغر لكنه صالح تمامًا». وتعرض وثيقة PageSpeed Insights الأقدم الحالة العامة بالطريقة نفسها: فالتصغير “refers to the process of removing unnecessary or redundant data without affecting how the resource is processed by the browser.” (ترجمة) «يشير إلى عملية إزالة البيانات غير الضرورية أو الزائدة من دون التأثير في طريقة معالجة المتصفح للمورد».

العبارة الأساسية في كليهما هي من دون التأثير في طريقة معالجة المتصفح له. هذه هي الغاية: يفترض بالمخرج أن يحافظ على سلوك المدخل، لا أن يشبهه فحسب. فأنت تحذف الأجزاء التي وُجدت فقط لتسهيل القراءة البشرية — المسافات البادئة والأسطر الفارغة والتعليقات — وتقصّر في CSS وJS المعرّفات وتطوي البنية الزائدة التي لا يحتاج المحلل إلى كتابتها صراحة. لكن «مصمم للحفاظ على السلوك» و«حافظ فعلًا على السلوك في قاعدة شفرتك» ليسا الشيء نفسه تلقائيًا؛ إذ يجب على المصغّر الصحيح تحليل اللغة بدل حذف المحارف آليًا (انظر الحالات الطرفية أدناه). لذلك المهم في سير العمل هو اختبار أثر الإنتاج المصغر المبني فعلًا، لا افتراض أمان حذف البايتات بحكم التعريف.

المكسب هو البايتات: بايتات أقل للتنزيل، ونص أقل — في CSS/JS تحديدًا — كي يحوله المتصفح إلى رموز قبل بناء CSSOM أو تشغيل البرنامج النصي. ولهذا ينتمي التصغير إلى نقاش مسار العرض الحرج: فالعمل اللازم للوصول إلى أول رسم يتعلق جزئيًا بتقليل البايتات الحرجة على المسار، والتصغير إحدى الرافعات التي تحقق ذلك.

التصغير مقابل الضغط مقابل الربط

يجب ضبط هذا التفريق قبل أي شيء آخر، لأن المجال يخلط بين العمليات الثلاث باستمرار.

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

أما الضغط (Gzip وBrotli) فهو ترميز في طبقة النقل يُطبق على الاستجابة فوق ملف مصغر أصلًا. ويرسم دليل OnCrawl عن التصغير وSEO الحد جيدًا: فالضغط “involves rewriting a file’s binary code and encoding it using fewer bits,” (ترجمة) «يتضمن إعادة كتابة الشفرة الثنائية للملف وترميزها باستخدام بتات أقل»، وهي آلية مختلفة جذريًا عن إزالة المحارف في التصغير. العمليتان متكاملتان وتطبقان عادة بهذا الترتيب: صغّر ثم اضغط. (القصة الكاملة لـGzip/Brotli/Zstd في تعمق الضغط.)

يجمع الربط/التجميع عدة ملفات في ملف واحد لتقليل عدد طلبات HTTP. ومرة أخرى يقول OnCrawl إن الربط “joins two or more code functions… into a single command.” (ترجمة) «يضم دالتين برمجيتين أو أكثر في أمر واحد». فهذا يحل مشكلة عدد الطلبات، لا مشكلة البايتات لكل ملف. تنفذ أدوات التجميع الحديثة التصغير والربط معًا في خطوة واحدة، وهو سبب كبير لخلطهما، لكنهما يعالجان عنقي زجاجة مختلفين.

وثمة عمليتان أخريان يجدر فصلهما، لأن أداة بناء واحدة تنفذهما جميعًا كثيرًا وتُستخدم المصطلحات بتساهل: يثبت tree-shaking تعذر الوصول إلى جزء من الشفرة من أي نقطة دخول ويستبعده من الحزمة؛ أما إزالة الشفرة الميتة فهي مرحلة ذات صلة تزيل الشفرة التي يحدد البناء أنها لن تنفذ أبدًا (فرع if (false) مثلًا). ليست أي منهما تصغيرًا؛ فالتصغير يقصر بنية الشفرة التي ستُشحن، بينما تحدد العمليتان ما سيُشحن أصلًا. يعرض Terser مثلًا هذه ضوابط منفصلة فعلًا: compress (إعادة كتابة البنية)، وmangle (تقصير المعرّفات)، وunused (إزالة الشفرة التي تثبت الأداة عدم الإشارة إليها). وهي خيارات مستقلة لا إعداد واحد، لأن كلًا منها قد يكون آمنًا أو غير آمن بمعزل عن الآخر بحسب قاعدة شفرتك.

طريقة مفيدة لتذكرها: minify = بايتات أقل لكل ملف؛ bundle/concatenate = طلبات أقل؛ tree-shake/dead-code-eliminate = شفرة أقل تُشحن أصلًا؛ compress = بايتات أقل على الشبكة. إنها حلقات متكاملة في خط الأنابيب نفسه، ويعتمد ترتيبها وتركيبها الدقيقان على أداة البناء: هز الشجرة/إزالة الشفرة الميتة ← التصغير ← (اختياريًا) التجميع ← الضغط ← التخزين المؤقت.

كيف يعمل حسب نوع الملف

لا تُصغّر أنواع الملفات الثلاثة بالطريقة نفسها، مع أن معظم محتوى المنافسين يعاملها كما لو كانت كذلك.

CSS. تزيل المصغرات المسافات البيضاء والتعليقات والفاصلة المنقوطة الأخيرة في الكتلة؛ وتطوي الصيغة المطولة إلى مختصرة حين يكون ذلك آمنًا (margin: 0px 0px 0px 0px ← margin:0)، وتدمج المحددات المكررة، وتقصر قيم الألوان (#ffffff ← #fff). يمكن أن يكون تصغير CSS شديدًا لأن تحليل بنية ورقة الأنماط آمن نسبيًا، مع استثناء محدد: خصائص CSS المخصصة (--my-var:). وفق مواصفة CSS، تتأثر أسماؤها بحالة الأحرف، وقد يُحفظ سيل الرموز في القيمة — بما فيه المسافات داخله — ويصبح ذا معنى عند استبدال الخاصية عبر var(). وقد يغير المصغّر الذي يعامل قيمة خاصية مخصصة مثل مسافات CSS العادية ما يحل إليه الاستبدال فعليًا.

JavaScript. هنا يذهب التصغير إلى أبعد مدى. فإلى جانب إزالة المسافات والتعليقات، يعيد مصغّر JS تسمية المتغيرات المحلية ومعلمات الدوال إلى أحرف مفردة (getUserProfile ← a)، ويزيل الشفرة الميتة غير القابلة للوصول، ويطوي التعبيرات. تجعل آليتان هذا النوع أخطر الثلاثة: أولًا، تتأثر قواعد الإدراج التلقائي للفاصلة المنقوطة في JavaScript بنهايات الأسطر، لذلك يجب أن يحلل المصغّر الصحيح اللغة ويصدر بنية صالحة بدل حذف الفراغ آليًا؛ فالخطأ قد يغير وظيفة الشفرة بصمت. ثانيًا، قد يكسر تشويه المعرّفات/الخصائص (تقصير الأسماء) شفرة تعتمد على ظهور النطاق في eval/with، أو على Function.name أو اسم الصنف، أو الوصول الديناميكي/المقتبس إلى الخصائص، أو عقد مع شفرة خارج الحزمة (واجهة DOM مدمجة أو تكامل خارجي). ولهذا تعرض مصغرات مثل Terser ضوابط صريحة لـeval وkeep_fnames وkeep_classnames/تشويه الخصائص بدل تشويه كل شيء افتراضيًا. المزيد عن الاختبار في المخاطر أدناه.

HTML. تصغير HTML هو الأكثر تحفظًا عمدًا، ويقتصر عادة على إزالة التعليقات وطي المسافات الزائدة. فقد تغيّر إعادة كتابة HTML الأشد الترميز المعروض أو السلوك، لذلك تترك المصغرات معظم البنية على حالها. وهذا التحفظ مبرر: وفق معيار HTML، ليست المسافات قابلة للتخلص منها في كل موضع؛ إذ ينشئ المحلل عقد النص أو يتخلص منها على نحو مختلف بحسب موضع المسافة والعنصر، كما أن لعناصر «النص الخام» و«النص الخام القابل للإفلات» (مثل <script> و<style> و<textarea>) قواعد تحليل خاصة لا يعامل فيها المحتوى كتوصيف عادي. وهذه هي الدقة التي تفوت معظم الشروح: تصغير HTML أضحل وأقل عائدًا من CSS/JS لأنه يحتوي حملًا ميتًا أقل يمكن إزالته بأمان، ولأن أثر الخطأ أوسع. يحتاج مصغر HTML إلى التفكير في المخرج المعروض، لا مجرد حذف محارف تبدو زائدة.

كم يوفر فعلًا؟

لا يوجد رقم عام. فأي نسبة واحدة تراها لـ«التوفير النموذجي» تصف ملفات شخص آخر وفق تنسيقه وأدواته، لا ملفاتك. يعتمد الفرق على مقدار إسهاب المصدر أصلًا (ينكمش المصدر كثير التعليقات والمسافات أكثر من المصدر المقتضب)، والمصغر وخياراته، وما إذا كانت خطوة بناء سابقة قد أزالت بعضه، ثم — بمعزل عن ذلك — ما إذا كان الملف يقدم مضغوطًا؛ إذ يطوي Gzip/Brotli كثيرًا من المسافات المتكررة بنفسه، وهي عين البايتات التي يزيلها التصغير. والطريقة الموثوقة الوحيدة لمعرفة رقمك هي قياس ملفاتك: شغّل تدقيقي Minify CSS/JavaScript في PageSpeed Insights/Lighthouse على URL الإنتاج الفعلي، أو قارن أحجام الملفات قبل تشغيل مصغرك وبعده.

واحذر كذلك مما يثبته تقليل البايتات. قد يقلل الملف الأصغر زمن النقل، وفي CSS/JS الوقت الذي يقضيه المتصفح في تحويل النص إلى رموز قبل بناء CSSOM أو تشغيل البرنامج؛ تلك هي الفائدة الحقيقية المحدودة. لكنه لا يثبت وحده تنفيذ JavaScript أقل أو عملًا أقل للخيط الرئيسي أو محددات CSS أقل للمطابقة أو إزالة شفرة ميتة. فالتصغير يغير طريقة كتابة الشفرة لا ما تفعله وقت التشغيل؛ وهذه مهمة أخرى (انظر tree-shaking/إزالة الشفرة الميتة أعلاه). كما لا تتحول بايتات المصدر الأقل تلقائيًا إلى تحسن قابل للقياس في Core Web Vitals أو البحث؛ فهذا يعتمد على كون حجم النقل أو زمن التحليل عنق الزجاجة الفعلية. ولن يحرك تصغير ورقة أنماط صغيرة أصلًا LCP محسوسًا في صفحة مشكلتها الحقيقية صورة رئيسية ضخمة أو برامج خارجية حاجبة للعرض. التصغير تحسين مساند — حقيقي وجدير بالتنفيذ وسهل الأتمتة — لكنه نادرًا ما يصلح صفحة بطيئة وحده. قِس عنق الزجاجة الفعلي قبل إنفاق وقت كبير على مطاردة KiB.

تدقيق PageSpeed Insights / Lighthouse

هذا سبب مجيء معظم الناس. يشغّل Lighthouse تدقيقين معنيين: Minify CSS (unminified-css) وMinify JavaScript (unminified-javascript)، ويعرضهما ضمن Opportunities. تصف وثائق Google الآلية بالطريقة نفسها لكليهما: “The Opportunities section of your Lighthouse report lists all unminified CSS files, along with the potential savings in kibibytes (KiB) when these files are minified.” (ترجمة) «يسرد قسم الفرص في تقرير Lighthouse جميع ملفات CSS غير المصغرة، مع التوفير المحتمل بالكبيبايت (KiB) عند تصغيرها». وبالنسبة إلى JavaScript تذكر Google الفائدة المزدوجة: “Minifying JavaScript files can reduce payload sizes and script parse time.” (ترجمة) «يمكن أن يقلل تصغير ملفات JavaScript أحجام الحمولة وزمن تحليل البرنامج النصي».

تذكر أمرين عند قراءة التقرير:

• رقم KiB تقدير للتوفير المحتمل، لا مكسب مضمون في سرعة الصفحة. يخبرك كم قد يصغر الملف، لا كم ستبدو الصفحة أسرع.
• يعمل التدقيق لكل ملف، وبات المخالفون غالبًا ملفات لا تتحكم فيها مباشرة — ودجات خارجية وبرامج إعلانية وأصول إضافات CMS — لا شفرتك المجمعة (انظر القسم التالي).

هل تحتاج إلى فعل ذلك يدويًا؟

لا في معظم الحزم الحديثة. تصغر عمليات بناء الإنتاج في Webpack (يتضمن الإصدار 4+ إضافة Terser افتراضيًا) وVite وNext.js وesbuild المخرجات تلقائيًا. وتسمي وثيقة Google الخاصة بـJS الأدوات مباشرة: “Terser is a popular JavaScript compression tool,” (ترجمة) «Terser أداة شائعة لضغط JavaScript»، و*“webpack v4 includes a plugin for this library by default to create minified build files.”* (ترجمة) «يتضمن webpack v4 إضافة لهذه المكتبة افتراضيًا لإنشاء ملفات بناء مصغرة». إذا شحنت بناء إنتاج من أي منها فشفرتك مصغرة بالفعل، وأنت «متوافق» بلا جهد.

فمتى يستمر ظهور التدقيق؟ غالبًا في:

• المواقع القديمة/غير المجمعة التي تقدم وسوم <style> و<script> مكتوبة يدويًا بلا خطوة بناء.
• البرامج النصية الخارجية — التحليلات وودجات الدردشة ووسوم الإعلانات — التي تحملها لكن لا تبنيها ولا يمكنك تصغيرها بنفسك.
• قوالب CMS وإضافاته التي تشحن أصولًا غير مصغرة.
• كتل <style>/<script> المضمنة التي لم تمسها أداة التجميع.

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

كيف تصغر الشفرة (والأدوات التي تسميها Google)

بالنسبة إلى الشفرة اليدوية أو القديمة، تسمي وثائق PageSpeed Insights أدوات محددة بحسب نوع الملف:

• HTML — HTMLMinifier.
• CSS — CSSNano وcsso.
• JavaScript — UglifyJS وClosure Compiler من Google. (تضيف وثيقة Lighthouse الأحدث Terser بوصفه الخيار الافتراضي الشائع.)

وتذكر وثيقة CSS من Google أيضًا أن أي مشروع أكبر من مشروع ضئيل ينجز التصغير عادة “is usually accomplished with a build tool like Gulp or Webpack” (ترجمة) «يُنجز عادة بأداة بناء مثل Gulp أو Webpack»، لا بنسخ ولصق يدوي في مصغر عبر الإنترنت. ويوجد خيار من جهة الخادم: يمكن لـPageSpeed Module الخاص بـApache/Nginx تصغير الاستجابات تلقائيًا بلا خطوة بناء منفصلة، كما تعرض شبكات CDN كثيرة مفتاح تصغير تلقائيًا مماثلًا.

التنفيذ الخاص بالمنصات

• WordPress. هنا أوجه الناس غالبًا، لأن معظم مالكي WordPress لا يشغلون خطوة بناء. تتولى إضافة أداء المهمة: تتضمن إعدادات File Optimization في WP Rocket مفتاحَي «Minify CSS files» و«Minify JavaScript files»، وAutoptimize بديل مجاني قوي إن لم تستخدم WP Rocket. أوصي بكليهما في دليل WordPress SEO.
• Drupal — فعّل «Aggregate JavaScript files» في إعداد أداء الإدارة.
• Joomla — تتولى الإضافات الربط/التصغير.
• Magento — توصي Google باستخدام Terser وتعطيل المصغر المدمج حين يتعارضان.
• React / Next.js — يصغر بناء الإنتاج تلقائيًا، فلا تحتاج عادة إلى إعداد شيء.

المخاطر والاختبار

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

إلى جانب الاختبار الوظيفي، ثمة آثار تشغيلية يغفلها الفرق لأن التصغير يبدو تجميليًا:

• خرائط المصدر. يعيد التصغير كتابة أرقام الأسطر والأعمدة والمعرّفات، لذلك تحتاج أدوات تتبع الأخطاء وتصحيحها إلى خريطة مصدر مطابقة (يدعم Terser مثلًا خرائط إدخال متسلسلة وخرائط إخراج مولدة)، وإلا غدت آثار مكدس الإنتاج غير مقروءة. أبقِ توليد الخريطة والبناء المصغر متزامنين، واحتفظ بطريقة ثابتة لرد أخطاء إصدار مصغر إلى المصدر الذي أنشأه.
• تعليقات الترخيص/القانون. قد تزيل إزالة التعليقات ترويسات ترخيص ملزمًا تعاقديًا بالحفاظ عليها. توفر المصغرات عادة خيارًا لحفظ التعليقات أو مقدمة الترخيص (مثل معالجة format.comments/preamble في Terser). تحقق من افتراض أداتك وإصدارها بدل افتراض بقاء التعليقات.
• تجزئات CSP وتكامل الموارد الفرعية. إذا استخدم موقعك مصدر تجزئة في Content Security Policy أو SRI في وسم script/style، تُحسب التجزئة أو البصمة على البايتات المقدمة بالضبط. تغيير المخرج المصغر يغير البايتات ومن ثم التجزئة؛ فأعد توليد تجزئة CSP أو بصمة SRI وانشرها ذريًا مع الأصل الجديد، وإلا فشل المورد بصمت تحت سياسة صارمة.
• تكافؤ أثر الإنتاج. اختبر الأثر الذي يُقدم فعلًا في الإنتاج، لا مخرج بنائك المحلي فقط؛ إذ قد تنتج طريقة عرض إطار العمل وتحويلات CDN والإضافات والحقن الخارجي وحالة الذاكرة المؤقتة أصلًا مختلفًا.
• التراجع. تكافؤ البايتات ليس دليلًا على تكافؤ السلوك. قبل شحن تغيير التصغير، أتح طريقة سريعة لمقارنة السلوك الوظيفي والمرئي ووحدة التحكم والشبكة والمراقبة بالبناء غير المصغر، ومسار تراجع سريعًا إن حدث انحدار بعد النشر.

هل يؤثر التصغير في SEO؟

ليس مباشرة. لا تسمي أي وثيقة رسمية من Google التصغير إشارة ترتيب. فهو مدخل إلى حجم الملف، وهذا مدخل إلى سرعة الصفحة وCore Web Vitals، وهما في أفضل الأحوال اعتبار ترتيب ثانويًا شبيهًا بكسر التعادل. وعندما سُئل John Mueller عما إذا كان تصغير HTML وCSS يساعد SEO، قال — وفق تغطية Search Engine Roundtable — إن تقليص الملفات قد يستحق النظر، مع توضيح أن الأثر يعتمد على مدى تضخم الصفحات أصلًا. إنه ممارسة للسرعة وتجربة المستخدم، لا رافعة ترتيب. وهذا هو التأطير الصحيح: نفّذه لنظافة الأداء، لا لأن Google تكافئ HTML المصغر.

وهذه أيضًا نصيحتي المستمرة في جانب الأداء. ففي دليل LCP، ضمن قسم عن جعل الملفات أصغر لتحسين Largest Contentful Paint، قلت بوضوح: “You should minify any CSS you have.” (ترجمة) «ينبغي أن تصغّر أي CSS لديك». وأقرنه بإزالة CSS غير المستخدم وتصغير JavaScript؛ فالتصغير حركة واحدة في جزء خفض حجم الملف من إصلاح LCP، إلى جانب الضغط وإزالة الشفرة الميتة.

موضعه في حزمة الأداء

فكر في التصغير كحلقة في سلسلة، لا السلسلة كلها:

التصغير ← التجميع/الربط (اختياريًا) ← الضغط (Gzip/Brotli) ← التخزين المؤقت (Cache-Control/CDN).

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

موضوعات ذات صلة — إلى أين بعد ذلك

تقع هذه الصفحة تحت محور مسار العرض الحرج، إلى جانب أقرب أشقائها، الضغط. اقرأهما معًا، لأن التصغير والضغط نصفا «جعل النص أصغر» ويُخلط بينهما باستمرار. ومن هناك يغطي محور أداء الويب الأوسع المقاييس التي يغذيها التصغير — Core Web Vitals وLargest Contentful Paint وFirst Contentful Paint — والعمل على الموارد الحاجبة للعرض الذي يهم عادة أكثر من التصغير وحده.

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

• التصغير = إزالة المحارف التي لا يحتاج إليها الملف ليعمل — المسافات البيضاء وفواصل الأسطر والتعليقات، وكذلك المعرّفات الطويلة والبنية الزائدة في CSS/JS — من مصدر CSS وJS وHTML، “without affecting how the resource is processed by the browser.” (ترجمة) «من دون التأثير في طريقة معالجة المتصفح للمورد». تدققه Google باسمَي unminified-css وunminified-javascript.
• ليس ضغطًا ولا ربطًا ولا tree-shaking/إزالة شفرة ميتة. الضغط (Gzip/Brotli) ترميز في طبقة النقل يطبق فوق الملفات المصغرة (صغّر أولًا ثم اضغط). يدمج الربط/التجميع الملفات لخفض طلبات HTTP. ويحدد tree-shaking/إزالة الشفرة الميتة ما سيُشحن أصلًا؛ أما التصغير فيقصر بنية ما سيُشحن. أربع رافعات متكاملة لا مترادفات.
• لكل نوع ملف، مع حالات طرفية: يمكن تصغير CSS وJS بشدة (إعادة تسمية المتغيرات وإسقاط الشفرة الميتة)، لكن سيل رموز خصائص CSS المخصصة والإدراج التلقائي للفاصلة المنقوطة وتشويه المعرّفات/الخصائص في JS تتطلب مصغرًا يحلل اللغة فعلًا، لا يحذف المحارف آليًا. تصغير HTML أضحل وأعلى مخاطرة (تعليقات ومسافات غالبًا)، لأن معالجة المسافات وعناصر النص الخام حساسة للمحلل وقد تكسر إعادة كتابة الترميز الصفحة.
• لا توجد نسبة توفير عامة؛ فهي تعتمد على ملفاتك، لذا قِسها. لا يثبت الملف الأصغر وحده تنفيذًا أقل أو تحسنًا في Core Web Vitals/البحث؛ فهذا يعتمد على كون النقل أو التحليل عنق الزجاجة الفعلية. إنه تحسين مساند لا حل سحري.
• أمان النشر: يغير تبديل البايتات المصغرة خرائط المصدر، وقد يسقط تعليقات الترخيص، ويبطل تجزئات CSP وبصمات SRI. أعد توليدها ونشرها ذريًا، واختبر أثر الإنتاج الفعلي، واحتفظ بمسار تراجع.
• ليس عامل ترتيب مباشرًا. لا تسميه أي وثيقة من Google كذلك؛ وقد وصف Mueller تصغير HTML/CSS بأنه جدير بالتنفيذ للسرعة/تجربة المستخدم بحسب تضخم الصفحات، أي مدخلًا إلى تجربة الصفحة لا رافعة ترتيب.
• تصغر أدوات التجميع الحديثة افتراضيًا (Webpack v4+/Terser وVite وNext.js وesbuild)، لذلك يظهر التدقيق أساسًا للمواقع القديمة أو الشفرة المضمنة أو أصول الجهات الخارجية/الإضافات.
• أدوات مسماة: HTMLMinifier لـHTML؛ وCSSNano/csso لـCSS؛ وUglifyJS/Terser/Closure Compiler لـJS. وفي WordPress: WP Rocket وAutoptimize.
• المخاطرة: قد يكسر تصغير JS الشديد الوظائف؛ اختبر في بيئة مرحلية أولًا.

الوثائق الرسمية

وثائق المصادر الأولية عن تصغير الشفرة.

Google

• تصغير CSS (unminified-css) — تدقيق Lighthouse: لماذا تكون ملفات CSS أكبر من اللازم كثيرًا، وكيف تعرض Opportunities التوفير المحتمل بوحدة KiB، وإرشادات خاصة بالمنصات. (يعيد web.dev/articles/minify-css من Google التوجيه 301 إلى هذا URL الأساسي.)
• تصغير JavaScript (unminified-javascript) — تدقيق JS: تعريف التصغير، وفوائد حجم الحمولة/زمن التحليل، وTerser وإضافة webpack الافتراضية.
• تصغير الموارد (HTML وCSS وJavaScript) — وثيقة PageSpeed Insights القديمة، وأفضل مصدر رسمي يسمي تصغير HTML إلى جانب CSS/JS ويسمي الأدوات (HTMLMinifier وCSSNano/csso وUglifyJS/Closure Compiler).
• تقليل حجم الواجهة الأمامية — التصغير ضمن سير أوسع لخفض الحجم يتمحور حول Webpack (التجميع وtree-shaking والتصغير معًا).
• تحسين ترميز أصول النص وحجم نقلها — يضع إزالة التعليقات في إطار مكمل للضغط على مستوى الشفرة.

Bing / Microsoft

• لم يُعثر على وثائق من Bing/Microsoft تتناول تصغير CSS/JS/HTML تحديدًا. لدى Bing Webmaster Tools إرشادات وتشخيصات عامة لسرعة الموقع، لكن لا شيء يسمي التصغير كما تفعل وثائق Lighthouse من Google؛ وهذا متسق مع ندرة نشر Bing إرشادات تنفيذ مفصلة لأداء الواجهة الأمامية.

اقتباسات من المصدر

تصريحات مثبتة في وثائق Google نفسها إلى جانب صوت من المجال. يقفز كل رابط إلى المقطع المقتبس في صفحة المصدر.

Google — ما التصغير

• “Minification is the process of removing whitespace and any code that is not necessary to create a smaller but perfectly valid code file.” (ترجمة) «تصغير الشفرة هو عملية إزالة المسافات البيضاء وأي شفرة غير لازمة لإنشاء ملف شفرة أصغر لكنه صالح تمامًا». — وثائق Google Lighthouse (Minify JavaScript). انتقل إلى الاقتباس
• “Minification refers to the process of removing unnecessary or redundant data without affecting how the resource is processed by the browser.” (ترجمة) «يشير تصغير الشفرة إلى عملية إزالة البيانات غير الضرورية أو الزائدة من دون التأثير في طريقة معالجة المتصفح للمورد». — وثائق Google PageSpeed Insights (Minify Resources). انتقل إلى الاقتباس

Google — لماذا يهم وكيف يُقاس

• “Minifying JavaScript files can reduce payload sizes and script parse time.” (ترجمة) «يمكن أن يقلل تصغير ملفات JavaScript أحجام الحمولة وزمن تحليل البرنامج النصي». انتقل إلى الاقتباس
• “The Opportunities section of your Lighthouse report lists all unminified CSS files, along with the potential savings in kibibytes (KiB) when these files are minified.” (ترجمة) «يسرد قسم الفرص في تقرير Lighthouse جميع ملفات CSS غير المصغرة، مع التوفير المحتمل بالكبيبايت (KiB) عند تصغيرها». — وثائق Google Lighthouse (Minify CSS). انتقل إلى الاقتباس
• “Minifying CSS files can improve your page load performance. CSS files are often larger than they need to be.” (ترجمة) «يمكن أن يحسن تصغير ملفات CSS أداء تحميل الصفحة. فكثيرًا ما تكون ملفات CSS أكبر مما يلزم». انتقل إلى الاقتباس

Google — الأدوات

• “Terser is a popular JavaScript compression tool.” (ترجمة) «Terser أداة شائعة لضغط JavaScript». وكذلك: “webpack v4 includes a plugin for this library by default to create minified build files.” (ترجمة) «يتضمن webpack v4 إضافة لهذه المكتبة افتراضيًا لإنشاء ملفات بناء مصغرة». انتقل إلى الاقتباس

المجال — OnCrawl (الشركة)، عن التفريق

• عن الضغط: “involves rewriting a file’s binary code and encoding it using fewer bits” (ترجمة) «يتضمن إعادة كتابة الشفرة الثنائية للملف وترميزها باستخدام بتات أقل» — وهي آلية مختلفة عن إزالة المحارف في التصغير. وعن الربط: إنه “joins two or more code functions… into a single command,” (ترجمة) «يضم دالتين برمجيتين أو أكثر في أمر واحد»، ما يعالج عدد الطلبات لا حجم الملف. اقرأ الدليل

Patrick Stox (أنا) — التصغير رافعة لـLCP

• “You should minify any CSS you have.” (ترجمة) «ينبغي أن تصغّر أي CSS لديك» — من دليل Ahrefs عن LCP، ضمن قسم عن جعل الملفات أصغر. اقرأ الدليل

تدقيق تصغير الشفرة — قائمة تحقق

مرور للتأكد من تصغير أصولك النصية من دون كسر شيء:

• شغّل URL عبر PageSpeed Insights / Lighthouse وافحص تدقيقَي «Minify CSS» و**«Minify JavaScript»** ضمن Opportunities.
• تأكد أن بناء الإنتاج يصغّر (Webpack/Terser وVite وNext.js وesbuild)؛ فإن شحنت بناء تطوير إلى الإنتاج فذلك هو الخلل الحقيقي.
• حدد أي الملفات المعلّمة تملكه وأيها خارجي (ودجات وإعلانات وتحليلات) أو أصول إضافات CMS لا تبنيها.
• في WordPress بلا خطوة بناء، فعّل التصغير عبر WP Rocket (File Optimization) أو Autoptimize، واختبر في بيئة مرحلية أولًا.
• افحص كتل <style> / <script> المضمنة التي ربما تجاوزتها أداة التجميع.
• تأكد أن التصغير يطبق قبل الضغط: صغّر ثم استخدم Gzip/Brotli.
• بعد التفعيل، انقر عبر الميزات التفاعلية (النماذج والقوائم والمنزلقات والدفع) للتأكد أن تصغير JS الشديد لم يكسر شيئًا.
• لا تفرط في التركيز على رقم KiB؛ قارنه بـروافع أكبر (الصور والموارد الحاجبة للعرض وزمن استجابة الخادم) قبل إنفاق وقت كبير هنا.
• أعد تشغيل PageSpeed للتأكد من زوال التدقيق (أو أن الباقي أصول خارجية لا تتحكم فيها).

النماذج الذهنية

1. ثلاث رافعات، وثلاث مهام مختلفة. التصغير = بايتات أقل لكل ملف. التجميع/الربط = طلبات أقل. الضغط = بايتات أقل على الشبكة. تتراكم بهذا الترتيب (التصغير ← التجميع ← الضغط ← التخزين المؤقت)، والخلط بينها يهدر الجهد. حين يقول شخص «اضغط CSS»، اسأله أي رافعة يقصد فعلًا.

2. مطابق وظيفيًا، لكنه أصغر. وعد التصغير كله أن سلوك المخرج يساوي سلوك المدخل — “without affecting how the resource is processed by the browser.” (ترجمة) «من دون التأثير في طريقة معالجة المتصفح للمورد». إن غيّر التحويل السلوك، فليس ذلك تصغيرًا يعمل بل تصغيرًا يكسر. وهذا الإطار يخبرك متى تحذر (JS الشديد) ومتى تطمئن (مسافات HTML).

3. الشدة تتدرج مع الأمان. يمكن تصغير CSS/JS بقوة لأن أدوات البناء تحلل بنيتهما بأمان؛ ويُصغر HTML بلطف لأن إعادة كتابة الترميز قد تكسر الصفحة. طابق توقعاتك (وتحملك للمخاطرة) بنوع الملف.

4. دور مساند لا بطولة. نسب حجم الملف ليست نسب Core Web Vitals. التصغير رخيص وجدير بالأتمتة، لكن مكسب LCP في موقع حقيقي يكمن عادة في الصور والموارد الحاجبة للعرض. نفذه ثم انتقل إلى الروافع الأكبر.

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

ورقة غش لتصغير الشفرة

التصغير مقابل الضغط مقابل التجميع

الترتيب: التصغير ← التجميع (اختياريًا) ← الضغط ← التخزين المؤقت.

ما يحدث لكل نوع ملف

الأدوات التي تسميها Google

حقائق سريعة

• تدقيقا Lighthouse: unminified-css وunminified-javascript، ضمن Opportunities (يعرضان توفير KiB المحتمل).
• لا توجد نسبة توفير عامة؛ فهي تختلف بحسب إسهاب المصدر والمصغر/خياراته وخطوات البناء السابقة. وأثر CWV عادة متواضع ولا يضمنه تقليل البايتات وحده.
• ليس عامل ترتيب مباشرًا. يغذي سرعة الصفحة/Core Web Vitals فحسب.
• تصغر أدوات التجميع الحديثة (Webpack v4+/Terser وVite وNext.js وesbuild) مخرجات الإنتاج افتراضيًا.
• اختبر تصغير JS الشديد في بيئة مرحلية قبل إطلاقه.

أدوات التصغير والتشخيص

التشخيص (هل توجد مشكلة أصلًا؟)

• PageSpeed Insights / Lighthouse — تدقيقا «Minify CSS» و*«Minify JavaScript»* ضمن Opportunities؛ نقطة البداية القياسية ومصدر وصول معظم الناس.
• GTmetrix / WebPageTest — يظهران فرص التصغير نفسها في تقريريهما؛ مفيدان لرأي ثانٍ وسياق مخطط الشلال.

مصغرات أدوات البناء (الوضع الحديث الافتراضي)

• Terser — مصغر JS الشائع؛ الافتراضي في عمليات بناء إنتاج webpack v4+.
• esbuild — أداة تجميع/تصغير فائقة السرعة لـJS وCSS.
• Vite / Next.js / وضع إنتاج Webpack — تصغر المخرج تلقائيًا، ولا تحتاج عادة إلى إعداد شيء.
• CSSNano وcsso — مصغرا CSS اللذان تسميهما Google.

يدوي/مستقل (قديم أو لمرة واحدة)

• HTMLMinifier — لـHTML وفق وثائق Google.
• UglifyJS وGoogle Closure Compiler — مصغرا JS اللذان تسميهما Google.
• المصغرات عبر الإنترنت — مناسبة لملف ثابت صغير لمرة واحدة، لا لسير عمل موقع حقيقي.

تصغير تلقائي على الخادم/CDN (بلا خطوة بناء)

• PageSpeed Module لـApache/Nginx — يصغر الاستجابات تلقائيًا من جهة الخادم.
• مفاتيح التصغير التلقائي في CDN — تعرض شبكات CDN كثيرة إعداد تشغيل/إيقاف.

WordPress (لا تحتاج خطوة بناء)

• WP Rocket — «Minify CSS files» و«Minify JavaScript files» في File Optimization.
• Autoptimize — بديل مجاني يجمع CSS/JS/HTML ويصغرها.

أخطاء وخرافات شائعة

«التصغير عامل ترتيب لدى Google». لا تسمي أي وثيقة رسمية من Google التصغير إشارة ترتيب. فهو يقلل حجم الملف، ما قد يساعد سرعة الصفحة قليلًا، وهي تغذي Core Web Vitals؛ أي رافعة غير مباشرة وثانوية في أحسن الأحوال. وقد صاغ Mueller تصغير HTML/CSS بوصفه جديرًا بالتنفيذ للسرعة، لا حركة SEO مباشرة.

«التصغير والضغط الشيء نفسه». هما آليتان مختلفتان في طبقتين مختلفتين. يزيل التصغير محارف المصدر الزائدة؛ ويعيد الضغط (Gzip/Brotli) ترميز البايتات للنقل. تطبق كليهما، والتصغير أولًا؛ فهما متكاملان لا متبادلان.

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

«سيحسن التصغير Core Web Vitals لدي بدرجة كبيرة». هذا مبالغ فيه عادة. توفير الحجم حقيقي لكن لا توجد نسبة عامة؛ فهو يعتمد على ملفاتك. ولا يثبت خفض البايتات وحده تنفيذًا أقل أو فرقًا قابلًا للقياس في Core Web Vitals؛ فذلك يعتمد على كون حجم النقل أو زمن التحليل عنق الزجاجة فعلًا. ويصغر أثر السرعة عادة أمام تحسين الصور أو إصلاح الموارد الحاجبة للعرض. يستحق التنفيذ، لكنه نادرًا علاج مستقل.

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

«يُصغر HTML مثل CSS/JS: احذف كل شيء غير ضروري». تصغير HTML متحفظ عمدًا (التعليقات والمسافات الزائدة)، لأن إعادة الكتابة الشديدة قد تكسر الترميز المعروض. لا تتوقع توفير CSS/JS ولا تستخدم مصغر HTML شديدًا على افتراض أنه آمن.

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

ما زال Lighthouse يبلغ عن شفرة غير مصغرة

العَرَض: بناء الإنتاج مصغر، لكن التدقيق لا يزال يسرد توفيرًا في CSS أو JavaScript.

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

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

ميزة JavaScript تنكسر في الإنتاج فقط

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

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

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

حجم النقل لا يتغير إلا قليلًا

العَرَض: تصغر ملفات المصدر بعد التصغير، لكن حجم النقل عبر الشبكة يتغير قليلًا.

السبب المرجح: يضغط Brotli أو Gzip المسافات المتكررة جيدًا أصلًا، لذلك يكون فرق طبقة النقل أصغر من فرق الملف الخام.

الإصلاح والتأكيد: قارن الحجمين المفكوك والمنقول. أبقِ التصغير نظافة بناء رخيصة، لكن انتقل إلى اختناقات أكبر إن لم يتحسن مخطط الشلال وCore Web Vitals فعليًا.

يتلقى الزوار أصول تطوير غير مصغرة

العَرَض: يكشف اسم الملف المنشور أو تعليقاته أو مصدره المقروء بناء تطوير.

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

الإصلاح والتأكيد: افحص URL الطلب الحي والاستجابة، وتحقق من أمر بناء الإنتاج والبيان، وافرغ مفتاح الذاكرة المؤقتة المتأثر، ثم تأكد أن استجابة جديدة تقدم الأصل المولد.

السلوك نفسه بمحارف مصدر أقل

CSS مقروء قبل التصغير:

/* Primary call to action */
.button {
  color: #ffffff;
  margin: 0px 10px 0px 10px;
}

CSS مصغر بعده:

.button{color:#fff;margin:0 10px}

اختفى التعليق والمحارف الزائدة، لكن التصريح يعني الشيء نفسه للمتصفح.

JavaScript مقروء قبل التصغير:

function doublePrice(price) {
  const multiplier = 2;
  return price * multiplier;
}

JavaScript مصغر بعده:

function doublePrice(e){return 2*e}

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

التصغير والضغط ينتميان معًا

قبل: يرسل الخادم ملف app.js المقروء من دون ترميز محتوى.

بعد: يصدر البناء app.js مصغرًا، ويرسل الخادم ذلك الأصل بترميز Brotli أو Gzip. تقلل الخطوة الأولى المصدر، وتقلل الثانية البايتات على الشبكة. ولا تستبدل إحداهما الأخرى.

قارن المخرج الخام بالمصغر

يمكن لـTerser إنشاء أثر JavaScript مصغر من دون الكتابة فوق المصدر المقروء:

npx terser src/app.js --compress --mangle --output dist/app.min.js
wc -c src/app.js dist/app.min.js

شغّل مجموعة اختبارات الإنتاج على الحزمة المولدة قبل النشر. يثبت عدد البايتات أن الأثر تغير؛ وتثبت الاختبارات الوظيفية أن السلوك لم يتغير.

احصر الأحجام المنقولة والمفكوكة في DevTools

الصق هذا في Console بعد تحميل بارد للصفحة. يعرض بايتات JavaScript وCSS كما تلقاها المتصفح وفكها:

performance.getEntriesByType('resource')
  .filter(r => ['script', 'link'].includes(r.initiatorType))
  .map(r => ({
    resource: new URL(r.name).pathname,
    transferred: r.transferSize,
    decoded: r.decodedBodySize,
  }))
  .sort((a, b) => b.decoded - a.decoded);

يعكس الفرق بين decoded وtransferred ضغط النقل؛ أما التصغير فيغير الأصل المفكوك نفسه.

التقط أصول التطوير في المخرج المنشور

يعثر فحص شجرة المصدر هذا على مراجع خرائط مصدر JavaScript وعلامات تطوير شائعة تستحق المراجعة قبل الشحن:

grep -RInE 'sourceMappingURL|process\.env\.NODE_ENV.{0,20}development' dist

التطابق خيط للتحقيق، لا دليلًا تلقائيًا على فشل التصغير.

تكافؤ أصول الإنتاج

الاختبار: ابنِ النسختين المقروءة والمصغرة في بيئة مرحلية، ثم شغّل اختبارات الوحدات والتكامل وتدفقات المستخدم الحرجة نفسها على المخرج المصغر.

النتيجة المتوقعة: تتطابق الاختبارات والسلوك المرئي، بينما يكون ملف CSS أو JavaScript المولد أصغر.

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

نافذة المراقبة: شغّله مع كل بناء إنتاج ونفذ اختبار دخان فور النشر.

محفز التراجع: تراجع إن انحدر تفاعل حرج أو مسار عرض أو معدل أخطاء في البناء المصغر.

فحص المورد المنشور

الاختبار: افتح تدقيق Lighthouse الحي للتصغير وافحص استجابات CSS/JS الدقيقة المسماة في قائمة موارده المتأثرة.

النتيجة المتوقعة: تغيب أصول الإنتاج التي تملكها عن قائمة الموارد غير المصغرة؛ ولكل عنصر باقٍ مالك خارجي أو قديم محدد.

تفسير الفشل: تجاوز مسار مصدر البناء، أو أصدرت إضافة ملفًا غير معالج، أو ما زال HTML/التخزين المؤقت القديم يشير إلى أصل تطوير.

نافذة المراقبة: افحص بعد كل تغيير في خط الأصول أو النشر.

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

فحص حزمة النقل

الاختبار: قارن الحجم المفكوك والمنقول للاستجابة الحية المصغرة وافحص ترميز محتواها.

النتيجة المتوقعة: يعكس الجسم المفكوك الأثر المصغر، ويستخدم النقل Brotli أو Gzip حيث يدعمهما الخادم والعميل.

تفسير الفشل: التصغير أو الضغط مفقود من طبقته الخاصة؛ ولا يثبت أحدهما الآخر.

نافذة المراقبة: تحقق فور تغيير إعداد CDN أو الخادم أو البناء.

محفز التراجع: تراجع إن قدم الإعداد أصولًا غير صالحة أو سبب انحدارًا متكررًا في حجم النقل أو الوظائف.

موارد تستحق وقتك

كتاباتي ذات الصلة

• ما Largest Contentful Paint ‏(LCP) وكيف تحسنه — أوضح إرشاداتي للتصغير هنا، في قسم «اجعل الملفات أصغر»: صغّر CSS وJS وأزل غير المستخدم.
• WordPress SEO: عشرون نصيحة وممارسة فضلى — الجانب العملي في CMS: مفتاحا File Optimization في WP Rocket وAutoptimize بديلًا مجانيًا، والتحذير من عدم اختبار البيئة المرحلية.
• Google PageSpeed Insights لمختصي SEO والمطورين — موضع ظهور «minify code» ضمن ما يحلله PSI، والتقرير الذي يأتي منه معظم القراء.
• دليل المبتدئ إلى Technical SEO — موضع سرعة الصفحة والتصغير في الصورة الأكبر.

محاضراتي

• كيف يعمل البحث (SlideShare) — الزحف والعرض والفهرسة والترتيب، ومنها موضع أداء الواجهة الأمامية. (ينطبق إخلاء المسؤولية الدائم لدي: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة… ولن يكون كاملًا أو دقيقًا 100 %».)

رسمي

• تصغير CSS وتصغير JavaScript (Google Lighthouse) — التدقيقان وإرشاداتهما الخاصة بالمنصات.
• تصغير الموارد (HTML وCSS وJavaScript) (Google PageSpeed Insights) — الوثيقة القديمة التي تسمي تصغير HTML وأدوات محددة.

من أنحاء المجال

• التصغير وSEO: دليل موجز (OnCrawl) — أقرب مقال قائم عن «التصغير لـSEO»؛ قوي في التفريق بين التصغير والضغط والربط.
• كيفية تصغير CSS لتحسين أداء الموقع (Cloudflare) — تعريفات واضحة والدقة الخاصة بكل نوع ملف (تصغير HTML أضحل من CSS/JS).
• تصغير JavaScript وCSS (GTmetrix) — استكشاف الأعطال الناشئة عن التدقيق ومجموعة أدوات (Closure Compiler وJSMin وYUI Compressor).
• كيفية تصغير JavaScript — الأدوات والأساليب الموصى بها (Kinsta) — شرح يركز على JS لشكل الشفرة المصغرة وأدواتها.
• تقول Google إن ضغط HTML وCSS يستحق النظر (Search Engine Roundtable) — تغطية ملاحظة John Mueller بأن تصغير HTML/CSS قد يستحق النظر لحجم الملف، في إطار السرعة/تجربة المستخدم لا رافعة ترتيب.
• r/TechSEO — مجتمع تصحيح الأداء وCore Web Vitals.

اختبر نفسك: تصغير الشفرة

خمسة أسئلة سريعة عما يفعله التصغير وما لا يفعله. اختر إجابة لكل منها ثم تحقق.

سجل التغييرات