האם ווידג'טים נטיביים מאטים את האתר שלכם? מדידת השפעה על ביצועים

ווידג'טים נטיביים מ-Taboola, Outbrain, MGID ו-Revcontent אכן מוסיפים זמן טעינה מדיד, בעיקר דרך JavaScript של צד שלישי, סיבובי שרת פרסום נוספים, וטעינת נכסי תמונה מתחת לקיפול. כמה זה פוגע תלוי מאוד ביישום: ווידג'ט שנטען באופן אסינכרוני, מרונדר בצורה עצלה ומוצב מתחת לקיפול עולה הרבה פחות מתגית סקריפט סינכרונית שחוסמת את thread הראשי ליד החלק העליון של הדף.

מאין מגיעה בפועל עלות הביצועים#

ווידג'ט המלצת תוכן אינו בקשה בודדת. התקנת אחד בדרך כלל מפעילה:

• תגית הסקריפט של המו"ל עצמו, שנטענת באופן אסינכרוני ברוב היישומים המודרניים, אם כי אינטגרציות ישנות יותר לפעמים עדיין נטענות באופן סינכרוני וחוסמות רינדור
• פנייה לשרת הפרסום של הרשת כדי לאחזר את מערך ההמלצות עבור הדף והמשתמש הספציפיים
• סיבובי round trip נוספים של demand-side ו-header bidding אם הרנת מפעילה מכירות פומביות תכנותיות ולא מלאי שנמכר ישירות, מה שיכול לעבור דרך מספר שותפי header bidding
• נכסי תמונה או תמונה ממוזערת עבור כל פריט מומלץ, בדרך כלל 6 עד 12 למופע ווידג'ט
• פיקסלים למעקב שמופעלים בעת רינדור ולחיצה, עבור הרשת וכל מעקב מפרסם במורד הזרם

כל אחד מאלה מוסיף השהייה, והם מצטברים. ווידג'ט שנראה כמו "תגית סקריפט אחת" ב-CMS שלכם יכול להפעיל תריסר בקשות רשת או יותר ברגע שהוא באמת מרונדר.

מה זה עושה ל-Core Web Vitals ספציפית#

המדדים שסביר שיזוזו:

CLS הוא זה שמכשיל את רוב המו"לים, כי זה גם המדד שסימני חוויית הדף של Google שמים עליו משקל בצורה הנראית ביותר. אם הווידג'ט שלכם נטען ללא גודל מיכל שמור, הדף קופץ באופן נראה לעין ברגע שהוא מתמלא, וזה בדיוק מה ש-CLS מעניש.

מדוע אותו ווידג'ט מתפקד אחרת באתרים שונים#

שני מו"לים שמפעילים מה שטכנית היא אותה אינטגרציה של Taboola או Outbrain יכולים לראות תוצאות Core Web Vitals שונות באופן משמעותי, וההבדל כמעט תמיד נובע מהדף שמסביב, לא מקוד הווידג'ט עצמו. דף שכבר רזה, עם סקריפטים של צד שלישי מינימליים, תמונות מותאמות, תשתית אירוח מהירה, סופג ווידג'ט אסינכרוני אחד עם השפעה נראית קטנה מאוד, כי יש קיבולת עודפת בתקציב הטעינה של הדף. דף שכבר נושא על גבו כמה סקריפטים של צד שלישי אחרים (אנליטיקה, ווידג'טים לצ'אט, רשת פרסום שנייה, הטמעות חברתיות) עובר סף שבו הבקשות של הווידג'ט הנטיבי הופכות לאלה שהמשתמשים שמים לב אליהן בפועל, גם אם הן עשויות להוות חלק קטן ממשקל הדף הכולל. אם אתם מטפלים בתלונת ביצועים אחרי הוספת ווידג'ט, בצעו ביקורת על כל דבר אחר שפועל בדף קודם; הווידג'ט הוא לרוב החשוד האחרון שנוסף, הבולט ביותר, אבל לא בהכרח צוואר הבקבוק בפועל.

כיצד להתקין אחד מבלי להרוס את ציון המהירות שלכם#

ההבדל בין ווידג'ט שעולה לכם כלום מדיד לבין אחד שמאט את האתר שלכם באופן נראה לעין בדרך כלל נובע מבחירות יישום, לא מהרשת עצמה:

1. טענו את הסקריפט באופן אסינכרוני, לעולם לא עם תגית סינכרונית חוסמת ליד החלק העליון של הדף
2. שמרו מקום למיכל עם גובה קבוע או CSS של יחס רוחב-גובה לפני שהווידג'ט מתמלא, כדי למנוע שינוי פריסה (layout shift)
3. טענו בצורה עצלה מתחת לקיפול, כך שבקשות הווידג'ט לא יתחרו בתוכן הראשי שלכם על רוחב פס במהלך טעינת הדף הראשונית
4. הציבו אותו אחרי התוכן הראשי שלכם, לא רק לחוויית הקורא אלא כי זה דוחה באופן טבעי את הטעינה עד אחרי שהתוכן שקובע בפועל את ה-LCP שלכם מרונדר
5. הגבילו את עצמכם למופע ווידג'ט אחד לדף במידת האפשר; ערימה של מספר ווידג'טי המלצה מכפילה את מספר הבקשות עבור תשואה פוחתת והולכת
6. בדקו עם האטת מכשיר אמיתית, לא רק מחשב שולחני עם פס רחב; ביצועי 4G בנייד הם המקום שבו משקל הווידג'ט מופיע בצורה הכי כואבת

האם ההכנסה שווה את פשרת המהירות?#

זו ההחלטה בפועל, וזה תלוי במה מהירות דף שווה לאתר הספציפי שלכם. אם אתם פועלים בעיקר על תנועה אורגנית מחיפוש וחוויית דף משפיעה על הדירוגים שלכם באופן משמעותי, ווידג'ט שמיושם בצורה גרועה שמושך את ציוני Core Web Vitals שלכם למטה יכול לעלות לכם יותר בחשיפה בחיפוש ממה שהוא מרוויח בהכנסות מפרסום. אם התנועה שלכם מגיעה בעיקר ממקורות ישירים, חברתיים או מניוזלטרים שבהם דירוג חיפוש הוא גורם קטן יותר, עלות המהירות חשובה פחות ביחס לרוויח RPM.

בכל מקרה, התיקון הוא לעיתים רחוקות "אל תפעילו ווידג'טים נטיביים." זה כמעט תמיד "תקנו את היישום." ווידג'ט שמיושם היטב, אסינכרוני, שנטען בצורה עצלה, ומגודר כראוי מ-Taboola, Outbrain, MGID או Revcontent עולה שבריר ממה שווידג'ט שמיושם בצורה גרועה עולה, עבור אותה הכנסה.

כיצד OpenAdLibrary עוזר לכם להשוות לפני שאתם מתחייבים#

לפני הוספת ווידג'ט מרשת שלא השתמשתם בה, שווה לראות איך המלאי והפורמט שלה נראים בפועל באתרים אחרים, לא רק בהצעת המכירה. OpenAdLibrary מאפשר לכם לדפדף בקריאטיב חי מ-Taboola, Outbrain, MGID, Revcontent ורשתות אחרות כדי לראות את הפורמט, צפיפות התמונה ומכניקות הלחיצה שהייתם משלבים בפועל, מהווה בסיס קונקרטי יותר להחלטת יישום מאשר חשבון הדגמה בלבד.

כיצד למדוד בפועל את ההשפעה על האתר שלכם#

אל תסתמכו על הערכות השפעה כלליות, כולל הטווחים במאמר זה. מדדו את האתר שלכם ישירות:

1. קו בסיס קודם. הריצו את הדפים המרכזיים שלכם בכלי כמו PageSpeed Insights או WebPageTest לפני התקנת כל דבר, ורשמו את LCP, CLS ו-INP לצד משקל הדף הכולל ומספר הבקשות שלכם.
2. התקינו את הווידג'ט, ואז בדקו מחדש את אותם דפים באותם תנאים. השתמשו בפרופיל חיבור נייד מואט, לא רק מחשב שולחני ללא האטה, כי שם ההשפעה נוטה להופיע הכי הרבה.
3. בידדו את התרומה הספציפית של הווידג'ט, רוב כלי הבדיקה מאפשרים לסנן את מפל המים (waterfall) לפי מקור הבקשה, כך שתוכלו לראות בדיוק כמה מזמן הטעינה הכולל ומספר הבקשות הווידג'ט עצמו אחראי אליהם לעומת קו הבסיס של האתר שלכם.
4. בדקו מחדש אחרי תיקוני יישום (טעינה אסינכרונית, שמירת גובה מיכל, טעינה עצלה) במקום להניח שתיקון עבד. פרטי יישום קטנים, כמו האם גובה המיכל מוגדר עם ערך פיקסל קבוע לעומת תיבת יחס רוחב-גובה רספונסיבית, יכולים לייצר תוצאות CLS שונות באופן משמעותי אפילו עם אותו ווידג'ט בסיסי.
5. חזרו על הבדיקה מעת לעת, לא רק פעם אחת בהשקה. רשתות לפעמים משנות את התנהגות הסקריפט שלהן או את צפיפות הפרסום לאורך זמן ללא הודעה למו"ל, אז הגדרה שנמדדה נקייה לפני חצי שנה שווה לבדיקה מחדש.

טעויות יישום נפוצות#

מספר בעיות חוזרות אחראיות לרוב עלות הביצועים הניתנת למניעה:

• אין גובה מיכל שמור, כך שהדף קופץ באופן נראה לעין ברגע שהווידג'ט מתמלא, פוגע ישירות ב-CLS
• מיקום הווידג'ט מעל או בתוך התוכן הראשי במקום אחריו, מתחרה בתוכן האמיתי שלכם על רוחב פס ועדיפות בטעינה ראשונית
• ערימה של מספר מופעי ווידג'ט בדף אחד, מכפילה את מספר הבקשות עבור הכנסה נוספת מוגבלת
• שימוש בקטע קוד אינטגרציה סינכרוני ישן שהמו"ל העתיק לפני שנים ומעולם לא בדק מחדש, כשהרשת שיחררה מאז גרסה אסינכרונית
• אי בדיקה ספציפית בנייד, שם השילוב של חיבורים איטיים יותר וצפי מסך קטן יותר הופך את בעיות זמן הטעינה ושינוי הפריסה לנראות יותר ממה שהיו נראות במחשב שולחני עם פס רחב

רוב אלה הם תיקונים חד-פעמיים בקוד התבנית שלכם, לא נטל תחזוקה מתמשך, מה שהופך אותם לשווים ביצוע נכון פעם אחת במקום לחיות עם גרירה מדידה מתמשכת בכל טעינת דף.

השורה התחתונה#

ווידג'טים נטיביים אכן מוסיפים משקל מדיד, ו-CLS הוא בדרך כלל המדד שצריך לעקוב אחריו הכי מקרוב. העלות היא בעיקר פונקציה של איכות היישום (טעינה אסינכרונית, שמירת מקום למיכל, טעינה עצלה מתחת לקיפול) ולא תכונה מובנית של פורמט הפרסום. מדדו את המצב שלכם לפני ואחרי בפועל עם בדיקת מכשיר אמיתית במקום להניח את ההשפעה על סמך מוניטין, ותקנו בעיות יישום לפני שתסיקו שהפורמט עצמו לא שווה את זה.