تسبب Google Analytics في فشل مؤشرات الويب الأساسية: الخطوات التالية

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

تعتبر مؤشرات أداء الويب الأساسية من Google بمثابة معيار رسمي لمدى متعة موقع الويب الخاص بك للمستخدمين في العالم الحقيقي، وهي عبارة عن مجموعة من ثلاثة مقاييس للأداء:

• يقيس أكبر طلاء محتوى (LCP) وقت التحميل الأولي
• يقيس التفاعل مع Next Paint (INP) الاستجابة
• يقيس إزاحة التخطيط التراكمي (CLS) استقرار التخطيط

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

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

دعونا التحقيق!

كيف يعمل برنامج Google Analytics؟

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

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

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

حتى الان جيدة جدا.

الآن دعونا نلقي نظرة على ما يحدث تحت الغطاء.

التأثير على الأداء (نظرة فاحصة)

عند الفحص الدقيق لذاكرة التخزين المؤقت المعطلة وعدم وجود تحسينات نشطة للأداء، نرى أنه تم تحميل gtag.js كطلب HTTP واحد بحجم صغير يبلغ 111 كيلو بايت، إلى جانب Microsoft Clarity gtag بحجم 769 بايت.

وفيما يتعلق بالتحميل الأولي للصفحة، تعرض شفرة تتبع Google Analytics سلوكًا متوقعًا ولا تساهم في طلبات HTTP المفرطة، أو جافا سكريبت غير المستخدمة، أو سلسلة الرسائل الرئيسية المحظورة.

ومن أين ينبع سوء الفهم إذن؟

هل يؤثر Google Analytics حقًا على مؤشرات الويب الأساسية؟

لا تؤدي إضافة تتبع Google Analytics إلى موقع الويب الخاص بك وحده إلى المخاطرة بالفشل في تقييم Core Web Vitals (أو Lagest Contentful Paint على وجه التحديد). وذلك ببساطة لأن المقتطف الموجود في رأس صفحات الويب خفيف الوزن للغاية ولا يمنع أيًا من العمليات الحيوية في عرض محتوى الصفحة.

إذًا، لماذا يقوم مالكو المواقع بربط Core Web Vitals الفاشلة بـ Google Analytics؟

الفرق بين البيانات المخبرية والبيانات الميدانية

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

دعونا نزيل الارتباك.

بعد تقديم مؤشرات أداء الويب الأساسية، عمل فريق Google بجد على تحويل الاهتمام إلى ما نسميه "البيانات الميدانية" - والتي يتم عرضها الآن في أعلى تقريرك كتقييم لمؤشرات أداء الويب الأساسية.

يتم إنشاؤه باستخدام بيانات من مستخدمين حقيقيين يتفاعلون مع موقع الويب الخاص بك من مجموعة بيانات CrUX (المعروفة أيضًا باسم تقرير تجربة مستخدم Chrome).

تقييم مؤشرات أداء الويب الأساسية استنادًا إلى البيانات الميدانية لموقع amazon.com

قبل أن تصبح مؤشرات أداء الويب الأساسية من Google هي المعيار لتجربة المستخدم الرائعة، كنا نعتمد على نقاط الأداء (التي يتم قياسها من 0 إلى 100) — والتي يتم عرضها الآن بعد تقييم CWV.

تعتمد نقاط الأداء على بيانات المختبر لموقع amazon.com

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

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

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

الحكم النهائي

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

ماذا عن Google Tag Manager وGoogle AdSense؟

في الواقع، نادرًا ما يذهب مالكو المواقع إلى حد إعداد التحليلات وتنفيذها يوميًا.

يعد Google Tag Manager وGoogle AdSense من الأدوات الشائعة للشركات عبر الإنترنت التي ترغب في تتبع أحداث معينة وعرض الإعلانات على مواقعها على الويب للحصول على إيرادات إضافية من حركة المرور الواردة.

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

باستخدام مثالنا السابق مع kiteworks.com ، نرى أنه عند التفاعل مع الصفحة الرئيسية، يتم تشغيل سلسلة من علامات الأحداث الإضافية (gtm.js) من Tag Manager.

وهذا يعني وجود عدد كبير جدًا من علامات gtm.js الإضافية، وبالتالي العدد الزائد من طلبات HTTP.

نظرًا لأنه يتم تحميل كود Google Analytics أولاً قبل أي شيء آخر، وعندما يحتوي موقع الويب الخاص بك على الكثير من علامات الأحداث، يمكنك أن تتوقع أن يستدعي مقتطف GA جميع ملفات gtm.js الأخرى، مما يؤدي إلى تأخيرات في التحميل وتفاقم النتائج في المقاييس، مثل:

• أكبر طلاء المحتوى
• إجمالي وقت الحظر
• أول طلاء محتوى (FCP)

في تقرير PSI الخاص بك، سيتم وضع علامة على هذه السلسلة من خلال التحذير "Reduce Unused JavaScript":

وإذا كان برنامج إدارة العلامات من Google الخاص بك يبدو مثل هذا عن بعد، فقد حان الوقت للتخلص من الفوضى وإعادة التنظيم:

إصلاح مشكلة "تقليل JavaScript غير المستخدمة" الناتجة عن برنامج Google Tag Manager

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

على الرغم من تشابه هذه السمات، إلا أن لها اختلافات مهمة:

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

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

من خلال تحسين عدد أحداث Google Tag Manager أولاً وتأجيلها بعد ذلك، يمكنك التأكد من أن التحميل الأولي لا يعاني من تأخيرات غير ضرورية.

قم بتقليل JavaScript غير المستخدمة وتحسين جميع موارد موقعك باستخدام NitroPack →

المخاطر والمقايضات مع Google AdSense

عندما يخصص مالكو المواقع وحدات إعلانية بتنسيقات مختلفة على صفحة ويب، يوفر Google AdSense مقتطفات شفرة (HTML/JavaScript) لكل وحدة إعلانية يتم لصقها في HTML لصفحات موقع الويب الخاصة بهم حيث يجب أن تظهر الإعلانات.

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

لسوء الحظ، بسبب خصائصها التي تمنع العرض، يمكن أن تؤثر إعلانات AdSense على أداء الموقع (وتحديدًا عناصر الويب الحيوية مثل LCP وCLS).

باستخدام NitroPack، يمكن لأصحاب المواقع اختيار "تحسين الإعلانات" مما سيؤدي إلى تأخير JS حتى تفاعل المستخدم. ولكن نظرًا لأن AdSense يعمل بناءً على مرات الظهور، فقد يؤدي ذلك إلى بعض الخسائر في إيرادات الإعلانات.

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

1) الأداء الأمثل لتجربة تصفح أفضل

أو

2) توليد أكبر قدر ممكن من إيرادات الإعلانات ولكن في النهاية فقدان حركة المرور بسبب سلوك الموقع غير المستقر.

التعليمات

هل الاستضافة الذاتية لبرنامج Google Analytics تستحق العناء؟

في حين أن بعض مالكي المواقع يفكرون في استضافة Google Analytics ذاتيًا لتتبع مؤشرات أداء الويب الأساسية، إلا أن هناك حاجة قليلة للقيام بذلك. بدلاً من إضافة التعقيد والتكلفة والقيود المحتملة مقارنة بالاعتماد على البنية التحتية لـ Google، ركز على تحسين أحداث Google Tag Manager لتلبية معايير Web Vitals الأساسية.