أساسيات الويب الأساسية لاختبار A / B: هل يؤدي برنامج اختبار A / B إلى إبطاء موقعك؟

أسقطت Google للتو تحديث Core Web Vitals ونحتاج إلى الانتباه إليه.

لماذا نهتم؟

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

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

ليس رائعًا ، أليس كذلك؟

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

هل ستعمل أداة اختبار A / B الخاصة بي على إبطاء موقعي وتؤثر على نقاطي الأساسية في الويب؟

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

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

الاخبار الجيدة؟

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

ما الفرق بين "أساسيات الويب الأساسية" و "تجربة صفحة Google"؟

تبدو معقدة ولديها أسماء رائعة ، لكنها تنقسم أساسًا لتتبع اللحظات الرئيسية في تجربة الصفحة للمستخدم:

• ما مدى سرعة تحميل صفحتك؟
• ما مدى سرعة رؤية المستخدم للعناصر الرئيسية في الصفحة وفهم ما تدور حوله؟
• متى يمكنهم التفاعل مع الصفحة؟
• ما المدة التي يستغرقها هذا التفاعل من النقر فوق الزر إلى الإجراء الذي يحدث؟
• كيف تبدو الصفحة وهل هي سهلة الاستخدام؟

لماذا نهتم؟

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

لماذا تهتم Google بتجربة المستخدم؟

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

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

(المحتوى الرائع والعرض والأكل والروابط الخلفية ستحرك الإبرة دائمًا بشكل أكبر.)

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

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

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

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

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

كيف تقيس حيوية الويب الأساسية الحالية ونتائج تجربة الصفحة

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

بدلاً من ذلك ، توجه إلى أداة PageSpeed ​​Insights من Google وتحقق من موقعك هناك.

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

هدفك هو الحصول على درجة 90 أو أعلى للجوال وسطح المكتب.

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

الآن ، هناك سبب يجعل هذه الصفحة تستغرق وقتًا طويلاً للتحميل على الهاتف المحمول. إنها حوالي 11000 كلمة ، بها 30 صورة أو نحو ذلك و 3 مقاطع فيديو.

عبر GIPHY

هذه صفحة كبيرة!

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

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

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

الشيء المثير للاهتمام هو أن تطبيق Convert Experiences يعمل فقط على إبطاء صفحتي بمقدار 107 مللي ثانية في الخلفية ، بينما يتسبب تطبيق Vimeo في تأخير يبلغ 1،567 مللي ثانية.

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

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

كيف توصل أداة PageSpeed ​​Insights إلى هذه النتائج؟

تستخدم أداة PageSpeed ​​Insights أداة اختبار Lighthouse من Google للحصول على فكرة عن كيفية أداء صفحتك.

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

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

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

هل هذا يعني أن العناصر الأخرى أصبحت فجأة أقل أهمية؟

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

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

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

تأخذ أداة Lighthouse هذه الأوزان ثم تطبقها على صفحتك الحالية باستخدام شيء يسمى بيانات Lab and Field لقياس أداء صفحتك.

ما هي المعامل والبيانات الميدانية؟

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

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

تستند البيانات الميدانية لدرجة المستخدم إلى النسبة المئوية الخامسة والسبعين لتجربة المستخدمين في تلك الصفحة.

لماذا هذا مهم؟ لأن تجربة كل مستخدم يمكن أن تختلف حسب أجهزته وسرعة الإنترنت.

إذا كان 26٪ من جمهورك يتصفحون هاتف iPhone 5 باتصال بطيء ، فقد تنخفض درجاتك إلى 74٪ وستظهر أن صفحتك "بحاجة إلى تحسين".

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

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

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

ما هي مقاييس تجربة الصفحة من Google ، المقاييس الأساسية الثلاثة لأهمية الويب ، وكيف يمكننا تحسينها؟

هناك 4 مقاييس أساسية لتجربة الصفحة و 3 مقاييس أخرى في مجموعة فرعية معينة تسمى Core Web Vitals (محور تحديث Google الأخير).

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

هذه ليست سوى العناصر الأساسية بالرغم من ذلك. هناك 6 مقاييس أخرى لتجربة الصفحة تستخدمها Lighthouse عندما تقيس أداء تجربة الصفحة باستخدام بيانات المعمل.

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

للمساعدة في تبسيط كل هذا ، قامت Google بتقسيم هذه العناصر إلى 3 عناصر أساسية للويب:

• أكبر رسم مضمون
• أول تأخير في الإدخال ، و
• التحول في التخطيط التراكمي

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

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

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

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

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

حاليًا ، يتم تقييم LCP بنسبة 25٪ من درجة CWV الخاصة بك.

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

يجب أن يكون هدفك هو تحميل LCP الخاص بك في أقل من 2.5 ثانية.

المشكلات الرئيسية التي تقلل درجة / سرعة LCP الخاصة بك هي:

• أوقات استجابة الخادم البطيئة
• يحظر عرض JavaScript و CSS ، مما يتسبب في تأخيرات في العناصر
• أوقات تحميل الموارد البطيئة
• عرض بطيء من جانب العميل
• تحسين الصورة ضعيف / غير صحيح.

كيفية تحسين درجة LCP الخاصة بك

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

هنا يمكنك رؤية نقاط LCP لصفحة المبيعات الخاصة بي قبل إجراء أي من التعديلات الموصى بها.

يستغرق حاليًا تحميل عنصر LCP على الصفحة 3.4 ثانية ، على الرغم من أنه مجرد عنوان نصي ، ويستغرق تحميل صفحتي 14.7 ثانية قبل أن تصبح تفاعلية.

إذا مررنا لأسفل عبر أداة PageSpeed ​​Insights ونظرنا إلى الفرص ، فهناك مجموعة من الأشياء التي يمكنني القيام بها لتحسين سرعة الصفحة الإجمالية وإيقاف بعض الأشياء التي تعمل على إبطاء LCP.

دعنا نذهب من خلال كل منهم.

أ. التحميل المسبق لعنصر LCP

أول شيء عليك القيام به هو التحقق من ماهية عنصر LCP الفعلي لصفحتك الحالية ، حيث يمكن أن يختلف بين الصفحات.

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

في هذه الصفحة بالذات ، يكون عنصر LCP الخاص بي هو العنوان الرئيسي الخاص بي.

يمكنني تحسين سرعة تحميل النص الخاص بي عن طريق فرز أشياء أخرى على صفحتي مثل الضغط والتخزين المؤقت ، ولكن ماذا لو كان عنصر LCP الخاص بي عبارة عن صورة؟

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

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

هذا شيء ضخم.

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

(هذه مشكلة كبيرة إذا كنت تقوم باختبار A / B لعنصر LCP الخاص بك أيضًا!)

اذا كيف بإمكاننا تصليحه؟

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

النص الذي تريد إضافته هو البرنامج النصي rel = ”preload” وسيظهر بالشكل التالي:

في هذا المثال ، أخبر هذه الصفحة بالتحديد لتحميل صورة TRAFFIC-SMALL-HEADER مسبقًا (وهي عنصر صورة LCP لتلك الصفحة). أقوم أيضًا بتحديد خيارات أبعاد متعددة حتى تتمكن من تحميل صورة سريعة الاستجابة للجوال وسطح المكتب.

سيساعد هذا التغيير وحده في حل أي صور بطيئة التحميل تؤثر على درجة LCP الخاصة بك.

ستسمح لك بعض سمات WordPress أو Shopify بإضافة رمز مخصص إلى رأس تلك الصفحة المعينة ، بينما تسمح بعض المكونات الإضافية بذلك. إذا تعذر ذلك ، يمكنك أيضًا تحرير ملف header.php لصفحتك وإضافة الكود مباشرةً.

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

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

ب. استخدم استضافة عالية الأداء / مخصصة

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

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

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

هنا يمكنك أن ترى أن وقت استجابة الخادم الأولي لموقعي كان 2.67 ثانية.

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

ج. تمكين التخزين المؤقت وزيادة طول ذاكرة التخزين المؤقت (إذا لزم الأمر)

يسمح لك التخزين المؤقت بالحفظ في طلبات الخادم عن طريق تخزين نسخة محفوظة من محتوى موقعك للمستخدمين بحيث يتم تحميلها بسرعة عند تكرار الزيارات.

بهذه الطريقة ، إذا عادوا وأرادوا مشاهدة المحتوى مرة أخرى ، فسيتم تحميله بسرعة مذهلة.

د. تأجيل JS غير الحرجة + إزالة JS غير المستخدمة

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

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

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

يمكنك تحديد JS أو التطبيقات أو المكونات الإضافية التي تريد تأجيلها أو إزالتها داخل WPRocket. (فقط تأكد من تعيين تحويل البرنامج النصي ليتم تحميله كأولوية وعدم تأجيله).

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

ملاحظة جانبية:

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

ه. ضع في اعتبارك تصغير الكود

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

سيسمح لك الكثير من المكونات الإضافية بالقيام بذلك.

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

F. تحسين الصور من أجل التحميل البطيء والاستجابة (ليس فقط صورة LCP)

الشيء الذي يمكن أن يبطئ من أداء الصفحة هو حجم الصورة وحجم الصور التي لديك.

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

(تذكر فقط تحميل صورة LCP مسبقًا!)

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

ز. استخدم ضغط الصور والتحجيم سريع الاستجابة

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

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

يتكامل WPRocket أيضًا مع مكون إضافي يسمى Imagify لضغط الصور سريعة الاستجابة وتقديمها (عن طريق إضافة خيارات متعددة لأحجام الشاشة المختلفة).

ح. إنشاء اتصالات الطرف الثالث في أسرع وقت ممكن

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

أتذكر كيف كانت مقاطع الفيديو الخاصة بي تبطئ صفحتي من قبل؟

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

أنا. استخدم CDN لتقليل وقت التحميل

تساعد شبكة CDN أو Content Delivery Network في تسريع سرعة تحميل موقعك بشكل أكبر ، عن طريق حفظ الإصدارات المخزنة مؤقتًا من موقعك على خوادم أقرب إلى موقع المستخدم.

يمكنك القيام بذلك بشيء مثل Cloudflare مجانًا.

ي. استخدم ضغط Gzip أو Brotli لتحسين حجم الملف

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

إذن ما هو تأثير إجراء كل هذه التغييرات؟

لقد قمت بتحسين سرعة تحميل موقعي ، حيث خفضتها من 13.5 ثانية إلى 3.3 ثانية على الهاتف المحمول. سرعة LCP الخاصة بي الآن 2.1 ثانية.

هذا يوفر 10.2 ثانية!

ليس سيئا ، أليس كذلك؟

لا تزال هناك بعض الأشياء التي يجب إصلاحها ، ولكن يجب تحسينها أثناء عملنا على عنصرين أساسيين آخرين للويب.

2. تأخر الإدخال الأول (FID)

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

الأسباب الأكثر شيوعًا لضعف FID هي:

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

يُحسب تأخير الإدخال الأول بنسبة 30٪ من درجة CWV الخاصة بك وهدفك هو تقليل هذه الاستجابة إلى 100 مللي ثانية أو أقل.

كيفية تحسين نتيجة تأخير الإدخال الأول

لا يمكننا قياس FID بدون مستخدم مباشر ، لذلك بدلاً من ذلك ، نحاول تحسين إجمالي وقت الحظر (TBT) لأن كلاهما متصل.

لذلك دعونا نلقي نظرة على نتائج صفحتنا ...

عندما قمت بقياس صفحتي لأول مرة ، كان TBT الخاص بي 1.5 ثانية (أو 1560 مللي ثانية).

منذ أن قمت بتحسين عناصر LCP ، فقد انخفض إلى 0.2 ثانية (210 مللي ثانية) ، و 3.5 ثانية حتى تفاعل كامل.

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

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

أ. تحميل المحتوى والروابط مسبقًا

إليك ميزة رائعة داخل WProcket. من خلال التحميل المسبق لصور LCP ، نطلب من الصفحة بدء تحميل صورة LCP في أسرع وقت ممكن.

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

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

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

الشيء الرئيسي الذي يمكننا القيام به لتحسين FID هو إزالة التعليمات البرمجية bloat من موقعنا.

انطلق وقم بتحميل صفحتك في GTMetrix.

واو ، هذه النتيجة تبدو مذهلة ، أليس كذلك؟

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

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

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

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

افتحها في الشلال ، ثم انسخ والصق عناوين URL للخطوط في WProcket. (كان يجب أن أضيفهم في وقت سابق لكن نسيت عفوًا!)

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

ب. إزالة البرنامج المساعد Bloat

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

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

يمكنك أيضا:

• قم بتحديث المكونات الإضافية لمعرفة ما إذا كانت تعمل بشكل أسرع.
• أو ابحث عن المكونات الإضافية البديلة التي تقوم بنفس الشيء للحصول على كود أقل.

ج. إزالة رمز السمة Bloat

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

يمكنك استبدال المظهر الحالي الخاص بك بآخر أخف يلبي احتياجاتك ورؤية قفزات هائلة في سرعة الصفحة ووقت التحميل.

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

د. إزالة Page Bloat

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

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

إذن ماذا كانت نتيجتي بعد تغيير هذا؟

لم أقم بإزالة مُنشئ الصفحات الخاص بي حتى الآن ، ولكن النتيجة لا تزال تنخفض إلى 130 مللي ثانية فقط إجمالي وقت الحظر ويتم تحميل الصفحة في 1.9 ثانية.

هل تريد تحسين سرعة صفحتك بشكل أكبر؟

هناك مكون إضافي رائع آخر يمكنك استخدامه يسمى Asset Cleanup (وهو ما يستخدمه فريقنا في Convert).

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

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

باستخدام Asset Cleanup ، يمكنك الانتقال إلى تلك الصفحة ثم التمرير لأسفل وإخبار المكون الإضافي بعدم التحميل على تلك الصفحة المحددة.

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

هل سبق لك أن حاولت النقر فوق شيء ما على موقع ما ثم يتحرك ويظهر إعلان أو لافتة بدلاً من ذلك؟

محبط ، أليس كذلك؟

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

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

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

هدفك هو الحصول على درجة CLS من 0.1 أو أقل.

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

• صور بدون أبعاد
• الإعلانات والتضمينات وإطارات iframe بدون أبعاد
• المحتوى الذي يتم حقنه ديناميكيًا مثل الإعلانات في الشريط الجانبي أو العنوان الذي يدفع المحتوى
• تتسبب خطوط الويب في إحداث FOIT / FOUT من خلال التغيير من خط عام إلى خط مخصص والتأثير على تباعد التخطيط
• الإجراءات تنتظر استجابة الشبكة قبل تحديث DOM.

والخبر السار هو أننا قمنا بالفعل بحل الكثير من هذا عن طريق إصلاح المشكلات مع LCP و FID.

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

إذا قمت بالتمرير لأسفل في أداة PageSpeed ​​Insights والنقر فوق "تجنب التحولات الكبيرة في التخطيط" ، يمكنك معرفة عناصر صفحتك التي تتسبب حاليًا في حدوث مشكلات في CLS.

في المثال الخاص بي ، هو ببساطة تغيير العنوان إلى تخطيط متجاوب للجوال ولا يؤثر على CLS كثيرًا.

قد يكون موقعك مختلفًا ، لذا ألق نظرة لمعرفة أسباب المشكلات وحلها.

والآن بعد أن غطينا كل مجال من مجالات "أساسيات الويب الأساسية" وكيفية تحسينها ، دعنا نلقي نظرة على كيفية تأثير اختبارك على درجاتك.

كيف تؤثر حيوية الويب الأساسية على اختبار UX و A / B (وكيفية اجتياز تقييم أساسيات الويب الأساسية أثناء استخدام البرنامج النصي للتحويل)

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

كيف لا تؤثر سلبًا على أكبر نقاط طلاء ذات محتوى عند اختبار A / B

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

ماذا لو كنت تختبر عنصر LCP مثل خلفية جديدة أو صورة رئيسية أو عنوان رئيسي؟

المشكلة التي قد تواجهك هنا ليست في أداة تحويل التجارب ، ولكن بالأحرى تتعلق بالممارسات السيئة لتحسينات LCP.

Like we mentioned earlier, most people make the mistake of lazy loading all images, including the LCP image, which affects the LCP score.

Convert Experiences uses both 'synchronous load' and 'body hide' methods to run tests. Simply put, the tool recognizes the element to be tested and then hides it as soon as it starts to load so the user never sees it, before changing it in under 50 milliseconds.

If you've lazy-loaded that LCP element though, the Convert Experiences app is going to have to wait for that element to load before it can do its job.

You can fix this by preloading the specific LCP elements on your control and test pages like we suggested above. This will get them to start loading immediately on page load, allow them to be recognized and hidden by the Convert app, and be replaced asap before the user notices.

Not only will this reduce flicker, but it will also give a good LCP score as the main LCP element (even when tested) will load fast.

And if the LCP element is not what you're testing? You should be pre-loading it anyway to improve that LCP score.

How to Improve First Input Delay when A/B Testing

The Convert code is incredibly fast, but your FID score still relies on all the other elements of your page.

Make sure to hit all the main requirements for speed that we talked about before so that there is no delay in the Convert code running. (Otherwise, the element you are testing will be hidden until it loads and then changes.)

• You can remove code bloat from other JS and defer them from running.
• You can also 'exclude' the Convert script from being deferred so that it loads up before any other JS so that it can make those test changes asap, while not hurting FID.

If you don't prioritize the Convert code and instead defer it by accident, it may not affect your FID score that much, but it might cause your test element to delay loading, while the script waits to run.

How To Decrease Cumulative Layout Shift Issues When A/B Testing

The potential issues with Cumulative Layout Shift and testing come down to how you run a layout test.

Ideally, you don't want to test massive layout changes with just the Convert Experiences editor. Instead, you want to test similar elements for variations ie swapping out a hero image for another image or swapping text for variations, etc. This means that the page layout stays the same, but a key element is swapped out for a variation.

But what if you want to test a minor layout shift, such as swapping the hero image and text location?

I recommend using Convert Experiences for small layout shifts to set up the test and then see how much it affects your CLS score before you push it live.

A real-world example:

Let's say that I set up that same flipped layout test as above. First, I would build the test inside the Convert Experiences app.

Then I can test this page variant in the page speed tool to get an idea of how it affects CLS.

Make sure you have the variant page open, and then click on the pen icon next to the variant in the Convert Experiences app, then select 'Open Force Variation URL':

This will load a pop up.

Make sure you have the variation page highlighted and then click to copy the URL.

You can input that URL into the PageSpeed Insights tool and measure the CLS and other CWV vitals for that variant.

Full disclosure:

In this particular example, I have not fixed any of the code bloat issues on this other page yet, but here you can see the original control page results based on just the LCP improvements.

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

ولكن ، بدافع الاهتمام ، دعنا نقارن نتيجة CLS على صفحة التحكم بنتائج المتغير:

كما ترى ، فإن استخدام CLS في صفحة المتغير جيد لأن النتيجة لا تزال ضمن الإرشادات.

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

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

ولكن ماذا لو كنت تريد اختبار تحولات كبيرة في التخطيط ، مثل إعادة التصميم الكلي أو إزالة عناصر الصفحة أو إضافتها؟

عبر GIPHY

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

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

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

الخلاصة + الوجبات الجاهزة الرئيسية

لذلك هناك لديك. دليلنا الكامل إلى Google Page Experience ، وتحديث 3 Core Web Vitals ، وكيف يمكن أن يؤثر الاختبار على تلك العناصر الحيوية ، وكيفية تحسين درجاتك.

هل تريد تعديله أكثر؟

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

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

تذكر:

• يعد تطبيق Convert Experiences سريعًا بشكل لا يصدق ، ولكن يمكن أن يعمل بشكل أفضل إذا اتبعت أفضل الممارسات لاختبار Core Web Vitals & A / B.
• نادرًا ما تقدم Google معلومات عن إشارات ترتيب معينة ، لذا فإن تجربة الصفحة وأساسيات الويب الأساسية مهمة وقد تستمر في أن تصبح أكثر أهمية في المستقبل. (لقد قاموا بالفعل بزيادة حدود سرعة الموقع منذ الإصدارات السابقة.)
• وفقًا لـ Google ، فإن Core Web Vitals هو العامل الفاصل عندما تتساوى جميع الأشياء الأخرى ، لذا فإن الأمر يستحق القيام به عند التنافس في نهاية المطاف. إذا كان المحتوى أو العرض متساويًا في الجودة ، وكان ترتيب الصفحة للصفحات المنافسة متشابهًا ، فإن تجربة المستخدم ستحدد ترتيب صفحات البحث.
• تهتم "أساسيات الويب الأساسية" بتجربة المستخدم الفعلية على الصفحة ، لذلك يعد هذا أمرًا مهمًا لـ CRO. يجدر تطبيق أفضل الممارسات حيث يمكن أن يؤثر ذلك على سرعة تحميل الصفحة ومعدل الارتداد ونسبة النقر إلى الظهور ومعدل التحويل والمزيد ، لا سيما على أجهزة الجوال.
• قد تبدأ "أساسيات الويب الأساسية" في التأثير على تجربة الصفحة المقصودة لحركة المرور المدفوعة وكيفية ظهورك في مزادات الإعلانات / تكلفة تشغيل الإعلانات. قد يؤثر تحسين هذا على تكاليف الإعلان وتسليمه.
• تحتاج إلى توفر العناصر الأساسية لتلبية متطلبات تجربة الصفحة. التحميل السريع ، CDN ، التخزين المؤقت ، HTTPS ، قبل النظر إلى العناصر الأخرى لتحسينها.
• يمكن أن يؤثر حجم التعليمات البرمجية وترتيب التحميل على كل من تأخير الإدخال الأول وأكبر رسم محتوى. تحتاج إلى معرفة كيفية إعداد العناصر أو تقييدها أو تحميلها مسبقًا أو تأجيل JSS و CSS لتحميل صفحتك بشكل فعال.
• عند اختبار المحتوى الموجود في الجزء المرئي من الصفحة (في منطقة العرض على أي جهاز) ، كن على دراية بعنصر LCP والحاجة إلى تحميله مسبقًا لتقليل مشكلات LCP - خاصةً إذا كان هذا هو تركيز الاختبار الخاص بك.
• يعمل تطبيق Convert Experiences بسرعة كبيرة بحيث لا يؤثر سلبًا على Core Web Vitals ، على افتراض أنك تقوم بإجراء اختبارات A / B حيث لا تتغير تغييرات التخطيط الكبيرة. (تبديل العناصر بعناصر متشابهة ، نص للنص ، صور للصور ، أشكال الأزرار ، إلخ). خلاف ذلك ، قد يؤثر هذا على CLS. (يمكنك دائمًا اختبار أي أشكال مختلفة لتغيير التخطيط قبل نشره في البث المباشر.)
• عند إجراء تغييرات أكبر في التخطيط ، يُنصح بتقسيم عنوان URL (كما تفعل مع الاختبار الديناميكي على أي حال) حيث سيؤثر ذلك على CLS. فقط تأكد من تحديث الصيغة الفائزة إلى عنوان URL الأصلي وإعادة توجيه 301 لأي ​​روابط قد تكون لدى الأشكال المختلفة (موقف نادر).