مشكلات الويب الحيوية الأساسية الشائعة في WordPress وكيفية إصلاحها

نشرت: 2023-09-06

هل تواجه صعوبة في اجتياز مؤشرات أداء الويب الأساسية؟

وفقا لجوجل:

55.4% من جميع مواقع الويب التي تحتوي على بيانات CrUX تعجز عن تلبية الحد الأدنى الجيد لجميع المقاييس الثلاثة – LCP وFID وCLS.

ومع ذلك، فإن اجتياز تقييم CWV ليس بأي حال من الأحوال مهمة مستحيلة.

في الواقع، إنها عملية من ثلاث خطوات:

  • تشغيل اختبارات الأداء
  • تحديد مشكلات مؤشرات الويب الأساسية
  • تحسينها

وبنهاية قراءة هذه المقالة، سوف تكون مجهزًا بكل المعرفة اللازمة لتنفيذ كل خطوة بنجاح.

لذا واصل القراءة!

ملخص سريع لمؤشرات أداء الويب الأساسية

ربما عثرت على بيان Google هذا:

"يعد تحسين جودة تجربة المستخدم أمرًا أساسيًا للنجاح طويل المدى لأي موقع على الويب."


ولكن كما يقول المثل الشهير – لا يمكنك تحسين ما لا يمكنك قياسه.

أو على الأقل كان هذا هو الوضع فيما يتعلق بقياس تجربة المستخدم قبل CWV.

في عام 2020، قدمت Google Core Web Vitals لتزويد مالكي مواقع الويب بمجموعة محددة من المعايير التي تؤثر بشكل مباشر على تجربة المستخدم وتدل عليها. تم الإعلان عنها كجزء من مبادرة Google الأوسع للتأكيد على المقاييس التي تركز على المستخدم في تقييم صحة الويب بشكل عام.

في جوهرها (المقصود من التورية)، تعد CWV مجموعة من مقاييس الأداء التي تلقي الضوء على جودة تجربة المستخدم على صفحة الويب. وهي تشمل ثلاثة عناصر رئيسية:

  • أداء التحميل (LCP)
  • التفاعل (FID)
  • الاستقرار البصري (CLS)

يقيس LCP، أو أكبر رسم محتوى، أداء تحميل الصفحة. فهو يقيس الوقت الذي يستغرقه تحميل المحتوى الرئيسي للصفحة. يعتبر LCP الأمثل أقل من 2.5 ثانية.

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

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

حدود مؤشرات أداء الويب الأساسية

هناك أيضًا مقياس رابع سيحل محل FID في مارس 2024 – التفاعل مع الطلاء التالي (INP).

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

السبب وراء استبدال INP بـ FID هو أنالأول يقدم طريقة أكثر شمولاً لتقييم استجابة الصفحة ، وقياس جميع التفاعلات.في المقابل، فإن FID يمثل فقط الأول. درجة INP الجيدة هي أقل من 200 مللي ثانية.

على الرغم من أن INP لا يؤثر بشكل مباشر على تقييم مؤشرات أداء الويب الأساسية (في الوقت الحالي)، فقد بدأت Google بالفعل في الإبلاغ عن مشكلات INP من خلال Search Console.

مشكلة INP في Google Search Console

تعرف على أفضل التقنيات لتحسين درجة INP الخاصة بك من Google نفسها. قم بالتسجيل في ندوتنا الحصرية على الويب →

اجتياز مؤشرات أداء الويب الأساسية: النسبة المئوية الخامسة والسبعون

عند مناقشة مقاييس مؤشرات أداء الويب الأساسية، غالبًا ما يشير Google إلى النسبة المئوية الخامسة والسبعين.

وهذا يعني أن الموقع يجب أن يستهدف مقاييس الأداء التي تلبي أو تتجاوز الحدود الموصى بها لما لا يقل عن 75% من زيارات صفحته.

إنها طريقة للتأكد من أن غالبية تفاعلات المستخدم مع الموقع مرضية بدلاً من التركيز فقط على القيم المتوسطة أو المتوسطة.

النسبة المئوية 75

أدوات لتحديد مشكلات مؤشرات الويب الأساسية

تتطلب الخطوتان الأوليتان في رحلة تحسين Core Web Vitals إجراء بعض الاختبارات وتحديد الأسباب المحتملة.

هناك العديد من الأدوات الشائعة التي يمكنك الاستفادة منها على طول الطريق:

1. رؤى PageSpeed

توفر PageSpeed ​​Insights من Google بيانات CWV الخاصة بالصفحة وعلى مستوى الأصل خلال الـ 28 يومًا الماضية. كما أنه يقدم نصائح قابلة للتنفيذ لتعزيز الأداء.

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

وفي الجزء السفلي، لديك أدوات الفرص والتشخيصات، والتي تزودك بقائمة من المشكلات والمقاييس ذات الصلة التي تؤثر عليها.

نظرة عامة على تقرير PSI


2. وحدة تحكم بحث جوجل

يتضمن تقرير مؤشرات أداء الويب الأساسية في Search Console بيانات الأداء لعناوين URL الفردية. وهذا يجعله خيارًا رائعًا لتحديد صفحات معينة تحتاج إلى تحسين. على عكس PageSpeed ​​Insights، تتضمن تقارير Search Console بيانات الأداء السابقة.

وبالتالي، يمكنك تتبع مدى تأثير التحسينات التي أجريتها وما إذا كنت تتحرك في الاتجاه الصحيح أم لا.

تقرير مؤشرات أداء الويب الأساسية في Search Console


تقرير تجربة مستخدم Chrome (CrUX)

تجمع CrUX بيانات تجربة المستخدم الواقعية من عدد لا يحصى من مواقع الويب، وتقدم رؤى أساسية حول Core Web Vitals بناءً على تفاعلات المستخدم الحقيقية.

يمكنك الاستفادة من مجموعة بيانات CrUX بطريقتين رئيسيتين:

  • واجهة برمجة تطبيقات Chrome UX Report - مثالية لأولئك الذين لديهم دراية بجافا سكريبت وJSON؛
  • BigQuery - مناسب لأولئك الذين لديهم مشروع Google Cloud ومعرفة بـ SQL.

على الرغم من أن هذه الطرق تتطلب جهدًا أكبر من فحص PageSpeed ​​Insights أو GSC السريع، إلا أنها توفر خيارات متعددة لتحليل البيانات والتصور. على سبيل المثال، يتيح BigQuery تقسيم البيانات وتكاملها مع مجموعات البيانات الأخرى.

شاهد نتائج CWV قبل وبعد باستخدام NitroPack. اختبر موقع الويب الخاص بك مجانًا →

معظم مشكلات الويب الحيوية الأساسية الشائعة في WordPress

أكبر مشكلات الطلاء المحتوى (LCP).

كما تعلم بالفعل، يقيس LCP المدة المطلوبة لعنصر المحتوى الأساسي، مثل صورة أو كتلة نصية، ليصبح مرئيًا على صفحة الويب.

يمكن لأي تأخير في استرداد مستند HTML الأولي من الخادم أن يدفع مقياس LCP إلى النطاق غير المناسب.

وهؤلاء هم المذنبون الرئيسيون:

1. بطء أوقات استجابة الخادم بسبب ميزانية الاستضافة

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

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

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

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

الوقت للبايت الأول

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


2. يتم تقديم JavaScript وCSS لحظر العرض بواسطة سمات ومكونات إضافية معينة

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

تقديم تأثير حظر الموارد

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

لذلك، عندما يتعلق الأمر بموقع WordPress الخاص بك، فالأقل هو الأفضل.

بمعنى آخر، يعد تحقيق التوازن الصحيح بين وظائف الموقع وسرعته أمرًا محوريًا لتحقيق أهداف الويب الأساسية الخضراء.


3. الصور غير المحسنة

وفقا لتقويم الويب:

"72% من صفحات الجوال و82% من صفحات سطح المكتب تحتوي على صور باعتبارها LCP الخاصة بها."

أعلى عناصر LCP

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

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

مشكلات التحول التراكمي للتخطيط (CLS).

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

فيما يلي الأشياء التي تتسبب في ارتفاع محتوى صفحتك لأعلى ولأسفل:

1. تم إدراج الصور بدون أبعاد محددة

إحدى التفاصيل التي غالبًا ما يتم تجاهلها في تطوير الويب هي مواصفات أبعاد الصورة.

لا يقتصر تحديد سماتالعرض والارتفاعللصور على الدقة الجمالية فحسب؛ إنه إجراء عملي للحفاظ على استقرار التخطيط.

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

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

2. مواضع الإعلانات بدون مساحة محجوزة

هل تقوم بدمج عناصر ديناميكية مثل الإعلانات أو مقاطع الفيديو أو أي محتوى مضمن آخر؟

يجب أن تعلم أن هذا التكامل يأتي مع مجموعة من التحديات.

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

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

مثال CLS

3. تسليم الخط غير الأمثل

في السعي لتحقيق اتساق العلامة التجارية والتصميم الجذاب، أصبحت الخطوط المخصصة عنصرًا أساسيًا في تصميم الويب.

لكنهم يقدمون تحديات، وهي FOIT (فلاش النص غير المرئي) وFOUT (فلاش النص غير المزخرف).

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

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

مثال FOUT

مشكلات تأخير الإدخال الأول (FID).

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

وهذه هي الموارد التي تمنع الموضوع الرئيسي بشكل شائع:

1. تنفيذ جافا سكريبت الثقيل

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

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

2. سوء تحديد أولويات الموارد

ليست كل الموارد المحملة على موقع الويب لها أهمية متساوية بالنسبة للعرض الأولي أو تفاعلات المستخدم.

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

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

3. تشغيل كمية زائدة من البرامج النصية لجهات خارجية

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

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

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

التفاعل مع مشكلات الطلاء التالي (INP).

وبالنظر إلى أن INP سيحل محل FID العام المقبل، فليس من المستغرب أن الأشياء التي تؤثر سلبًا على مقياس الاستجابة الحالي ستؤثر أيضًا على المقياس القادم.

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

ولكن هناك شيء آخر:

1. وجود حجم DOM كبير

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

شجرة دوم

على الرغم من أن DOM أساسي لوظيفة صفحة الويب، إلا أن حجمه يمكن أن يؤدي إلى مشكلات في الاستجابة للأسباب التالية:

كلما زاد حجم DOM، زاد الطلب على المتصفح لعرض الصفحة بسرعة وفعالية.

بعبارات أبسط:

للحصول على استجابة سريعة لإجراءات المستخدم، من الضروري تبسيط DOM الخاص بك إلى العناصر الأساسية فقط.

قد تفكر في تعريف كلمة "ضروري". وفقًا لمعايير Lighthouse، يعتبر حجم DOM مرهقًا إذا تجاوز1400 عقدة.

انضم إلى 45% من مواقع الويب التي تجتاز مؤشرات الويب الأساسية الخاصة بها. قم بتثبيت NitroPack اليوم →

كيفية إصلاح مشكلات مؤشرات الويب الأساسية في WordPress (قائمة التحقق)

تحسين LCP

LCP هو المقياس الذي يعاني منه أصحاب مواقع الويب أكثر من غيرهم. ولهذا السبب هناك العديد من التحسينات التي تحتاج إلى تطبيقها:

  • ترقية الاستضافة الخاصة بك : فكر في الابتعاد عن الاستضافة المشتركة.على الرغم من فعاليته من حيث التكلفة، إلا أنه يمكن أن يكون أبطأ من الخيارات الأكثر تكلفة - حلول الاستضافة المخصصة أو السحابية. تميل خيارات الاستضافة المتميزة إلى تقديم أوقات استجابة أسرع.
  • استخدمشبكة توصيل المحتوى (CDN): تقوم شبكات CDN بتخزين الإصدارات المخزنة مؤقتًا من موقعك على خوادم متعددة موجودة على مستوى العالم. ويضمن ذلك حصول المستخدمين على البيانات من أقرب خادم، مما يقلل الوقت المستغرق لجلب البيانات.
  • تحسين قواعد البيانات : يتضمن ذلك إزالة البيانات القديمة وتحسين الاستعلامات واستخدام الفهارس بشكل فعال. بالنسبة لمواقع الويب التي تحتوي على WordPress، يمكن للمكونات الإضافية مثل WP-Optimize المساعدة في صيانة قاعدة البيانات.
  • اختر تنسيق الصورة الصحيح : حدد التنسيق الأكثر كفاءة لصورك. في حين أن JPEG مثالي للصور الفوتوغرافية، فإن PNG أفضل للصور ذات الشفافية. يمكن للتنسيقات الحديثة مثل WebP أن تقدم مرئيات عالية الجودة بأحجام ملفات أصغر.
  • تطبيق الضغط : استخدم الضغط مع فقدان البيانات لتقليل أحجام الملفات دون حدوث تدهور بصري كبير. استخدم الضغط بدون فقدان للحفاظ على كل تفاصيل الصور التي تكون الجودة فيها ذات أهمية قصوى.
  • تغيير حجم الصور: تسليم صور مخصصة للجهاز وإطار العرض. تجنب استخدام الصور الكبيرة التي يتم تغيير حجمها بعد ذلك باستخدام CSS أو داخل المتصفح. قم بإنشاء أحجام صور مختلفة لدرجات دقة الشاشة المختلفة وعرضها باستخدام السمة "srcset". أو جرّب مكونًا إضافيًا مثل NitroPack، الذي يعمل على تغيير حجم صورك تلقائيًا.
  • تصغير ملفات JS وCSS : قم بتقليل حجم البرامج النصية وأوراق الأنماط عن طريق إزالة الأحرف والمسافات البيضاء والتعليمات البرمجية غير الضرورية. يمكن لأدوات مثل Terser (لـ JS) وCSSNano (لـ CSS) المساعدة في هذا الأمر.
  • استخدام التأجيل أو غير المتزامن: استخدم سمة التأجيل للبرامج النصية غير المطلوبة لعرض الصفحة الأولي. يضمن ذلك تنفيذ ملفات JS بالترتيب بعد تحليل HTML. استخدم السمة غير المتزامنة للبرامج النصية التي لا تعتمد على البرامج النصية الأخرى وليست ضرورية للعرض الأولي. يسمح هذا للمتصفح بمواصلة تحليل الصفحة أثناء تنزيل البرنامج النصي.
  • InlineCritical CSS: حدد الحد الأدنى الضروري من CSS لعرض الصفحة الأولي وقم بتضمينه مباشرة داخل HTML. وهذا يضمن أن الأنماط الأساسية للمحتوى الموجود في الجزء المرئي من الصفحة متاحة على الفور.

تحسين FID

لضمان استجابة سلسة وسريعة للصفحة، قم بتنفيذ التحسينات التالية:

  • استخدم عمال الويب : قم بإلغاء تحميل الحسابات المعقدة إلى عمال الويب. يقومون بتشغيل JavaScript في الخلفية على سلسلة رسائل منفصلة، ​​مما يضمن بقاء سلسلة المحادثات الرئيسية سريعة الاستجابة.
  • إعطاء الأولوية لـ Critical JS : إعطاء الأولوية لتحميل وتنفيذ كود JS الأكثر أهمية أولاً. استخدم rel="preload" لإعلام المتصفح بالبرامج النصية ذات الأولوية العالية.
  • تقليل CSS غير المستخدم : على الرغم من أن JavaScript عادةً ما تكون هي الشرير الرئيسي، إلا أن CSS تحظر أيضًا الموضوع الرئيسي. من خلال تقليل CSS غير المستخدمة، يمكنك تقليل إجمالي عدد البايتات التي يجب تنزيلها. والأهم من ذلك، التأكد من أن المتصفحات يمكنها البدء في عرض الصفحة بشكل أسرع نظرًا لأن لديها عمليات أقل للقيام بها.
  • تقسيم المهام الطويلة: قم بتقسيم المهام الطويلة إلى أجزاء أصغر غير متزامنة باستخدام تقنيات مثل requestIdleCallback(). وهذا يضمن أن يظل الموضوع الرئيسي متاحًا لمدخلات المستخدم في كثير من الأحيان.
  • تحسين مستمعي الأحداث: إذا كان لديك العديد من مستمعي الأحداث على عناصر متعددة، ففكر في تفويض الحدث. تقوم هذه الطريقة بربط مستمع حدث واحد بأصل مشترك، مما يقلل عدد المستمعين ويحسن الأداء.

تقليل CLS

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

  • تحديد أبعاد الصور والإعلانات والتضمينات: قم دائمًا بتضمين سمات العرض والارتفاع لصورك. يساعد هذا المتصفح على تخصيص المساحة الصحيحة للصورة قبل تحميلها.
  • استخدم عرض الخط: اختياري: استخدام عرض الخط: اختياري مع الرابط rel=load المسبق لأهم الخطوط لديك يعتبر أفضل استراتيجية شاملة للخط لـ CLS جيدة. لن تتسبب القيمة الاختيارية في إعادة التخطيط عندما يكون خط الويب جاهزًا. وفي الوقت نفسه، من المرجح أن يتطابق الخط الذي تم تحميله مسبقًا مع الطلاء الأول، مما يضمن عدم حدوث أي تغييرات في التخطيط.
  • حجز مساحة للمحتوى الديناميكي : قم دائمًا بتخصيص مساحة مناسبة مسبقًا للمحتوى الذي تم تحميله ديناميكيًا، مثل الإعلانات أو إطارات iframe. سيمنع هذا المحتوى من دفع العناصر الأخرى عند التحميل.

تمرير INP

جميع تقنيات التحسين المذكورة في قسم FID ستعمل حتمًا على تحسين درجة INP الخاصة بك. وفوق كل ذلك عليك تنفيذ ما يلي:

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

يتم إحتوائه

قد يكون الاطلاع على القائمة الطويلة من التحسينات أمرًا مرهقًا للغاية لدرجة أنه قد يجعل المرء يفكر:

هل أحتاج حقًا إلى اجتياز تقييم "مؤشرات أداء الويب الأساسية"؟ هل هم مؤثرون إلى هذا الحد؟

والحقيقة هي أن الأمر لا يتعلق بالمقاييس نفسها.

نعم، يعد إجراء اختبار PSI ورؤية كل شيء باللون الأخضر أمرًا رائعًا دائمًا. ونعم، إنها جزء من عوامل التصنيف في Google، لذلك قد ترى تعزيزًا في موضع SERP الخاص بك.

لكن القيمة الفعلية تأتي من حقيقة أن تمرير CWV الخاص بك يترجم مباشرةً إلى توفير تجربة مستخدم من الدرجة الأولى.

وهذا يؤدي إلى نتائج واقعية مثل:

  • زيادة معدلات التحويل
  • تقليل معدلات الارتداد
  • امتلاك موقع ويب يحب المستخدمون زيارته

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

ولكننا نتفق أيضًا على أنه ليس من السهل التعامل مع جميع التحسينات.

لهذا السبب قمنا بإنشاء NitroPack.

NitroPack هو حل خفيف الوزن لأداء الويب يعمل على تشغيلأكثر من 180.000 موقع ويب على مستوى العالم ، مما يسمح لهم بتحقيق مؤشرات أداء الويب الأساسية ونتائج الأداء وتجربة المستخدم الممتازة.

بفضل ما يزيد عن 35 من ميزات تحسين سرعة الصفحة المضمنة ، تعد NitroPack الشركة الرائدة في تحسين مؤشرات أداء الويب الأساسية:

تقرير تكنولوجيا مؤشرات أداء الويب الأساسية

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

اختبر NitroPack مجانًا →