כלי פיתוח אתרים הם הדרך המהירה ביותר לפרוץ את תקרת הדירוגים כאשר התוכן של האתר שלכם "טוב מספיק" אך מוגבל על ידי מהירות. מדריך זה מראה בדיוק כיצד לאבחן את מדדי ה-Core Web Vitals, לתעדף תיקונים המשפיעים על LCP ו-INP, לבצע אופטימיזציה לתמונות וגופנים מבלי לפגוע בעיצוב, ולהגדיר תהליך עבודה לבדיקות חוזרות כדי שפוסטים חדשים לא יאטו את האתר שלכם בהדרגה לאורך זמן.
באילו כלי פיתוח אתרים ניתן להשתמש כדי למדוד ולאבחן את ה-Core Web Vitals?
באילו כלים כדאי להשתמש כדי למדוד ולאבחן את ה-Core Web Vitals? התחילו בהפרדה בין נתוני מעבדה (בדיקות הניתנות לשחזור בתנאים מבוקרים) לבין נתוני שטח (משתמשים אמיתיים במכשירים אמיתיים). כלי מעבדה אומרים לכם מה לתקן. נתוני שטח אומרים לכם אם התיקון אכן עזר.
עבור אבחון מעבדה, אני מסתמך על שלושה כלים מכיוון שכל אחד מהם חושף רובד אחר של האמת:
PageSpeed Insights הוא ה"קריאה הראשונה" המהירה ביותר, מכיוון שהוא משלב תוצאות מעבדה של Lighthouse עם נתוני שטח מ-Chrome User Experience Report (CrUX) כאשר הם זמינים. הוא מבוסס על דעה, אך הוא מצוין בהפניה לחשודים המיידיים: משאבי LCP גדולים מדי, CSS שחוסם רינדור, ומשימות ארוכות ב-main-thread. השתמשו בו למיון ראשוני ולצילומי מצב מהירים של לפני/אחרי. גוגל מתעדת את המדדים וספי המדידה בהפניה שלהם ל-.
Lighthouse הוא הכלי שאתם מריצים מקומית או ב-CI כדי לתפוס רגרסיות לפני שחרור גרסה. אם יש לכם תהליך צמיחה מונחה מוצר, זה חשוב כי דפי שיווק משתנים לעיתים קרובות כמו ממשק המשתמש של המוצר. היתרון הגדול ביותר: יכולת חזרה על הבדיקה. המלכודת הגדולה ביותר: צוותים מתייחסים לציון Lighthouse כ-KPI. אל תעשו זאת. התייחסו אליו כאל גלאי עשן.
WebPageTest הוא המקום אליו הולכים כאשר "LCP איטי" אינו מספיק כדי לפעול. ה-Waterfall, ה-filmstrip ותזמון ברמת הבקשה מראים לכם בדיוק מה חוסם את הרינדור, מה מתגלה מאוחר מדי, ומה מורד מוקדם מדי. כשסטארט-אפ אומר לי "כבר עשינו אופטימיזציה לתמונות", WebPageTest בדרך כלל מראה את הבעיה האמיתית: תמונת ה-hero אינה דחוסה, אינה נטענת מראש, ומעוכבת על ידי סקריפט של צד שלישי.
לאחר מכן אתם צריכים מדידת שטח. אם תשתמשו רק בכלי מעבדה, תבצעו אופטימיזציה לסביבת מעבדה שאינה תואמת את הקהל שלכם. עבור נתוני שטח, יש לכם שתי אפשרויות מעשיות:
CrUX (דרך PageSpeed Insights, לוח הבקרה של CrUX, או BigQuery) נותן לכם נתוני משתמשים אמיתיים מצטברים כאשר לאתר שלכם יש מספיק תנועה. זה נהדר עבור קווי מגמה, לא עבור ניפוי באגים בדף בודד.
ניטור משתמשים אמיתיים (RUM) נותן לכם נראות ברמת הדף וברמת הסגמנט באופן מיידי. אם אתם כבר משתמשים בערימת אנליטיקה, הוסיפו אוסף Web Vitals כדי שתוכלו לחתוך את ה-INP לפי סוג מכשיר, נתיב ומקור תנועה. הספרייה בקוד פתוח web-vitals היא נקודת התחלה פשוטה אם אתם רוצים להטמיע זאת בעצמכם.
משפט אחד ששווה לחזור עליו פנימית: כלי מעבדה מוצאים צווארי בקבוק, RUM מוכיח השפעה.
אם הצוות שלכם עדיין מחליט על מה לבנות, השתמשו בפלטפורמה ובערכת כלים שהופכת את עבודת הביצועים לקלה יותר, לא קשה יותר. הצגנו בחירות מעשיות ב-כלי פיתוח אתרים לאתרים ידידותיים ל-SEO מכיוון שבונה אתרים או תבנית לא נכונים יכולים לנעול אתכם בתוך תבניות איטיות.
אילו תיקונים משפיעים הכי הרבה על LCP ו-INP (ניצחונות מהירים תחילה)?
אילו תיקונים משפיעים הכי הרבה על LCP ו-INP? העבודה עם ה-ROI הגבוה ביותר נמצאת כמעט תמיד בראש הדף וב-main-thread.
LCP (Largest Contentful Paint) הוא בדרך כלל אחד משלושה דברים: תמונת ה-hero, בלוק כותרת גדול, או קונטיינר מעל קו הקיפול. הניצחונות המהירים ביותר מגיעים בדרך כלל מ:
1) תקנו את משאב ה-LCP עצמו. אם אלמנט ה-LCP הוא תמונה, הפכו אותה לקטנה יותר בבתים, הגישו אותה בפורמטים מודרניים (AVIF/WebP היכן שנתמך), וודאו שהיא מתגלה מוקדם. טענו מראש רק את תמונת ה-LCP האמיתית, לא קרוסלה של חמש תמונות "אולי". אם אלמנט ה-LCP הוא טקסט, אתם בדרך כלל חסומים על ידי CSS או גופנים.
2) צמצמו את זמן תגובת השרת ובצעו מטמון (Caching) באגרסיביות. זמן Time to First Byte איטי אומר לעיתים קרובות שהמקור שלכם עושה יותר מדי עבודה לכל בקשה. הציבו CDN לפני, בצעו מטמון ל-HTML היכן שניתן, וודאו שחוקי המטמון שלכם תואמים למציאות. עבור סטארט-אפים מונחי מוצר, דפוס נפוץ הוא: דפי שיווק יכולים להיות במטמון למשך דקות או שעות, דפי אפליקציה לא. הגדרות "no-cache בכל מקום" זהירות מדי הורסות בשקט את הביצועים.
3) בטלו CSS ו-JS שחוסמים רינדור. אם הדפדפן לא יכול לצייר עד שחבילת CSS גדולה יורדת ומעובדת, ה-LCP ייתקע. חילוץ CSS קריטי עוזר, אך הניצחון הפשוט יותר הוא לעיתים קרובות להפסיק לשלוח CSS לא בשימוש מתבנית או ספריית רכיבים. עבור סקריפטים, דחו את מה שלא צריך לרוץ לפני אינטראקציה, והיו חסרי רחמים לגבי תגיות צד שלישי. ראיתי דף תמחור מאבד 15-25 נקודות בביצועי Lighthouse כי ווידג'ט צ'אט הזריק סקריפט כבד לפני שהתוכן הראשי רונדר.
INP (Interaction to Next Paint) עוסק בתגובתיות. אתם משפרים את ה-INP על ידי הפחתת עבודה ב-main-thread במהלך אינטראקציות:
פרקו משימות ארוכות. אם יש לכם משימות של 200-500 מילי-שניות במהלך לחיצות, הקלדה או ניווט, פצלו אותן. לעיתים קרובות זהו זינוק בהידרציה של Framework או מטפל אנליטיקה כבד.
דחו עבודה לא חיונית עד למצב סרק. הפעילו פיקסלים שיווקיים לאחר שהדף אינטראקטיבי, לא במהלך הטעינה הראשונית. אם אתם צריכים לשמור אותם, טענו אותם עם הסכמה ולאחר קלט ראשון.
בצעו ביקורת על סקריפטים של צד שלישי עם הוכחות. WebPageTest ולוח הביצועים של Chrome DevTools יראו לכם בדיוק אילו סקריפטים אוכלים את ה-CPU. הסירו את אלו שלא תורמים.
הנה טבלת תעדוף מהירה שאנו משתמשים בה כאשר צוותים תקועים בוויכוח על מה לעשות קודם:
תסמין
סיבה סבירה ביותר
הכלי הטוב ביותר לאימות
תיקון שבדרך כלל מזיז את המדד
LCP > 2.5 שניות בדפי נחיתה מרכזיים
תמונת hero שהתגלתה מאוחר או CSS חוסם רינדור
WebPageTest waterfall
טעינה מראש של תמונת LCP אמיתית, דחיסה, הפחתת CSS חוסם
LCP משתנה מאוד לפי אזור
שיהוי מקור, אין מטמון קצה CDN
RUM + TTFB לפי גיאוגרפיה
CDN, מטמון HTML/סטטי, אופטימיזציה של ה-backend
INP גרוע בנייד
משימות JS ארוכות, הידרציה כבדה, סקריפטים של צד שלישי
DevTools Performance + RUM
פיצול קוד, דחיית סקריפטים, הפחתת CPU של צד שלישי
ציוני מעבדה טובים, ציוני שטח רעים
מכשירים אמיתיים איטיים יותר, שונות ברשת
CrUX/RUM
אופטימיזציה של בתים, הפחתת JS, תעדוף משאבים קריטיים
אם אתם מפרסמים תוכן לעיתים קרובות, רגרסיות בביצועים מגיעות לעיתים קרובות מ"עוד הטמעה אחת" או בלוק חדש שטוען סקריפטים נוספים. לכן אנו דוחפים צוותים למסד את הפרסום, לא להתייחס לכל פוסט כאל אירוע חד-פעמי. העלות העסקית של חוסר עקביות היא אמיתית, וכימתנו אותה ב-העלות האמיתית של אי-פרסום תוכן SEO בעקביות מכיוון שדפים איטיים וקצב לא עקבי מצטברים.
כיצד לבצע אופטימיזציה לתמונות וגופנים מבלי לשבור את העיצוב
כיצד מבצעים אופטימיזציה לתמונות וגופנים מבלי לשבור את העיצוב? עושים זאת על ידי הגדרת גדרות בטיחות ברמת המערכת (ברירות מחדל, חלופות ואילוצים) כך שמעצבים ומשווקים יוכלו לשחרר תוכן מבלי לחשוב על קילובייטים.
התחילו עם תמונות, מכיוון שהן בדרך כלל הבתים הגדולים ביותר בדף.
עבור תמונות מעל קו הקיפול, המטרה פשוטה: הגישו את הקובץ הקטן ביותר שעדיין נראה נכון בגודל המרונדר. זה אומר שאתם צריכים תמונות רספונסיביות (
srcset
), מימדים פנימיים נכונים כדי למנוע שינוי פריסה, ודחיסה שתואמת את סוג התוכן (תמונות לעומת צילומי מסך של ממשק). אם ה-CMS שלכם מאפשר העלאה של תמונות ברוחב 4000px עבור קונטיינר של 1200px, אתם תמשיכו לשלם מס LCP לנצח.
טעינה עצלה (Lazy loading) שימושית, אך אל תשתמשו בה עבור תמונת ה-hero. טעינה עצלה של אלמנט ה-LCP היא אחת הפציעות העצמיות הנפוצות ביותר שאנו רואים בביקורות.
אם אתם משתמשים במדיה חיצונית או בפוסטים עמוסי הטמעות, הגדירו מדיניות מפורשת עבור תוכן/מדיה/תמונות חיצוניות: מתי לארח בעצמכם, מתי להשתמש ב-CDN של תמונות, ומתי להחליף הטמעות בתמונות ממוזערות קלות שטעונות את ההטמעה בעת אינטראקציה. פוסט חברתי מוטמע בודד יכול להוסיף בקשות מרובות, סקריפטים ועומס CPU.
כעת גופנים. גופנים שוברים עיצוב כאשר צוותים מבצעים להם אופטימיזציה בצורה עיוורת. הגישה המעשית היא:
השתמשו ב-
font-display: swap
כך שהטקסט ירונדר מיד עם חלופה ויתחלף כשהגופן ייטען. כן, ייתכן שתראו הבהוב. החלופה היא טקסט בלתי נראה, שזה גרוע יותר למשתמשים ולעיתים קרובות גרוע יותר למדדים.
בצעו Subset לגופנים רק לגליפים שאתם צריכים, במיוחד אם אתם שולחים משקלים מרובים. סטארט-אפים רבים שולחים 5-8 קבצי גופנים כשהם משתמשים רק ב-2 משקלים בדפי שיווק.
טענו מראש רק את קבצי הגופנים הקריטיים המשמשים מעל קו הקיפול, וודאו שהטעינה מראש תואמת את הבקשה בפועל (אותו URL, אותו
crossorigin
במידת הצורך). טעינות מראש שגויות מבזבזות רוחב פס ולא עושות כלום.
אם אתם רוצים הפניה מוצקה למה הפרטים האלה חשובים, המדריך של גוגל ל-אופטימיזציית LCP הוא אחד המשאבים הבודדים שנשארים מבוססים על האופן שבו דפדפנים טוענים דפים בפועל.
CDN, מטמון וסקריפטים חוסמי רינדור: ההגדרה ששומרת על דפים מהירים
עבודת מהירות נכשלת כאשר היא נעשית כ"ספרינט ביצועים" חד-פעמי במקום כבסיס הגדרות. כלי פיתוח האתרים שלכם צריכים לעזור לכם לשמור על האתר מהיר לאחר עשרות איטרציות.
הגדרות CDN: בצעו מטמון לנכסים סטטיים (תמונות, CSS, JS) עם TTL ארוך ושמות קבצים ששוברים מטמון. עבור HTML, בצעו מטמון היכן שניתן. דפי שיווק בטוחים לעיתים קרובות למטמון בקצה עם TTL קצר ומחיקה בעת פרסום. אם אתם בוורדפרס, שופיפיי, Webflow או Wix, יש לכם כפתורים שונים, אך העיקרון זהה: הגישו צפיות חוזרות מהקצה.
מטמון: הפעילו דחיסת Brotli או gzip, וודאו שאתם לא מבטלים מטמון בטעות עם כותרות כמו
Cache-Control: no-store
בדפים ציבוריים. ראיתי צוותים מעתיקים כותרות אבטחת אפליקציה על כל הדומיין והורגים ללא ידיעה את הביצועים עבור כל דף נחיתה.
סקריפטים חוסמי רינדור: מנהלי תגיות הם שימושיים, אך הם גם מזבלה. בצעו ביקורת על תגיות מדי רבעון. אם סקריפט לא מייצר ערך מדיד לצינור המכירות, הסירו אותו. זהו אחד מתיקוני ה-SEO הנדירים שגם מפחיתים סיכון אבטחה.
אם הדפים שלכם "צריכים להיות מדורגים" אך לא, ביצועים הם לעיתים קרובות חלק מקבוצה גדולה יותר של אילוצים: קישור פנימי, חוסר התאמה לכוונת המשתמש, תבניות דקות או בעיות אינדוקס. אנו מחזיקים רשימת בדיקה אבחנתית ב-מדוע לאתר שלך יש תוכן נהדר אך הוא עדיין לא מדורג מכיוון שצוותים נוטים להתמקד יותר מדי במנוף אחד.
מה לבדוק מחדש לאחר פרסום תוכן חדש (כדי שהביצועים לא ידרדרו)
מה עליכם לבדוק מחדש לאחר פרסום תוכן חדש? התייחסו לפרסום כמו לשחרור גרסה. כל מאמר חדש יכול להציג תמונות כבדות יותר, הטמעות חדשות, סקריפטים נוספים ושינויי פריסה.
אני ממליץ על לולאת בדיקה חוזרת קלה שפוגעת בדפים ובתבניות שהכי סביר שיחוו רגרסיה: תבנית פוסט הבלוג, דפי קטגוריה, דף הבית ו-3 דפי הנחיתה המובילים שלכם. אם אתם מריצים אתר של דף אחד להשקות בשלב מוקדם, בדקו מחדש את הנתיב הזה באובססיביות כי כל סעיף חדש מוסיף משקל ו-JS.
הנה הסדר המדויק שעובד מבלי להפוך לעבודה במשרה מלאה:
הריצו Lighthouse על התבניות המרכזיות בפרופיל גלישה בסתר (או CI) כדי לתפוס רגרסיות ברורות ב-LCP, פרוקסי INP (זמן חסימה כולל במעבדה) ו-CLS.
הריצו WebPageTest על דף מייצג אחד (בדרך כלל הפוסט החדש ביותר) כדי לבדוק את ה-Waterfall עבור תמונות שהתגלו מאוחר, עיכובי סקריפט צד שלישי וכותרות מטמון.
בדקו את PageSpeed Insights עבור שינויים בנתוני שטח אם יש לכם מספיק תנועה, ועקבו אחר מגמות CrUX מדי שבוע.
אשרו עם RUM: השוו INP ו-LCP עבור סוג הדף החדש לעומת קו הבסיס של 7 הימים הקודמים.
אם אתם מפרסמים אוטומטית, תזמנו את הבדיקה החוזרת הזו. אוטומציה ללא ניטור היא הדרך שבה אתרים הופכים לאט לכבדים יותר עד שהדירוגים נעצרים. זה גם המקום שבו הגישה של VellumUp חשובה: כשאתם מחברים פרסום למערכת, אתם יכולים לאכוף גודל תמונות עקבי, להפחית עומס הטמעות מקרי, ולשמור על קצב מבלי להקריב מהירות. אם אתם רוצים להבין מה מערכת אוטומטית יכולה ללמוד ממבנה האתר הקיים שלכם, איתותי סריקת אתר ש-AI יכול לחלץ מה-URL שלכם היא נקודת התחלה טובה.
כלל עצמאי שאתם יכולים להדביק במסמכי הצוות שלכם: כל פרסום חייב לשמר LCP, INP ו-CLS בתבניות שמניבות הכנסות.
שאלות נפוצות
אילו כלים הם הטובים ביותר למדידת Core Web Vitals?
השתמשו ב-PageSpeed Insights לשילוב מהיר של נתוני מעבדה ושטח, ב-Lighthouse לבדיקות הניתנות לשחזור בפיתוח, וב-WebPageTest לניפוי באגים עמוק ב-Waterfall. הוסיפו RUM אם אתם רוצים Core Web Vitals ברמת הדף עבור משתמשים אמיתיים, לא ממוצעים.
מה עלי לתקן קודם עבור LCP?
התחילו עם אלמנט ה-LCP עצמו, בדרך כלל תמונת ה-hero או הקונטיינר מעל קו הקיפול. הפכו אותו לקטן יותר, גלו אותו מוקדם יותר (טענו מראש אם מתאים), והסירו CSS ו-JS חוסמי רינדור שמונעים את הציור הראשון.
מה זה INP ואיך אני משפר אותו?
INP מודד כמה מהר הדף מגיב לאינטראקציות משתמש במהלך הסשן. שפרו אותו על ידי הפחתת משימות JavaScript ארוכות, דחיית סקריפטים לא חיוניים וקיצוץ תגיות צד שלישי שצורכות זמן ב-main-thread.
האם CDN הופך אתר למהיר אוטומטית?
CDN עוזר, אך רק אם חוקי המטמון וכותרות הנכסים נכונים. אם ה-HTML לעולם לא עובר מטמון, לתמונות יש TTL קצר, או שאתם מבטלים מטמון עם כותרות, CDN לא יציל את ה-LCP.
הצעד הבא: נעילת תהליך עבודה של פרסום בטוח למהירות
בחרו דף נחיתה אחד עם תנועה גבוהה ופוסט בלוג אחד אחרון, הריצו PageSpeed Insights ו-WebPageTest, ורשמו את חוסם ה-LCP הגדול ביותר ואת הגורם המפריע הגדול ביותר ב-main-thread. תקנו את שני הפריטים האלו, ואז הריצו שוב את אותן בדיקות. ברגע שתראו את הניצחון, הפכו אותו לרשימת בדיקה לכל פרסום כדי שהביצועים יפסיקו להיות תרגיל כיבוי אש חוזר.
VellumUp11 דקות קריאה
