אופטימיזציה של תמונות (Image Optimization): הדחיסה שחוסכת שניות מזמן הטעינה של האתר

״הלקוח כבר נכנס לעמוד, אז למה הוא יוצא לפני שהוא משאיר פרטים?״ זו שאלה טיפוסית שאפשר לשמוע בטלפון או לקרוא בוואטסאפ. העמוד נפתח, הכותרת מופיעה ואולי גם הכפתור כבר נמצא על המסך — אבל התמונה הראשית עדיין אפורה, מטושטשת או פשוט לא שם. מבחינת המשתמש, האתר לא באמת מוכן. הוא לא מודד את ההמתנה; הוא מרגיש שמשהו תקוע ומחליט אם להישאר.

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

כשאני בוחן עמוד כזה, אני לא מכריז מראש שהתמונות אשמות. אני בודק לאיזו תמונה המשתמש מחכה, באילו ממדים היא נשלחת, מתי הדפדפן מגלה אותה ואיזו גרסה מקבל הטלפון. לפעמים תמונה ברוחב 1,500 פיקסלים נשלחת לאזור שמציג כ־500 פיקסלים. במקרה אחר הקובץ כבר קל, אבל ההורדה שלו מתחילה מאוחר מדי. אלה שתי בעיות שונות, ולכן גם הטיפול בהן שונה.

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

לפעמים התמונה היפה היא גם הנכס היקר ביותר בעמוד

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

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

נתוני Web Almanac של HTTP Archive משנת 2025 מצאו שתמונה שימשה כרכיב ה־LCP בכ־85.3% מהדפים שנמדדו במחשב ובכ־76% מהדפים במובייל. אלה נתונים רחבי היקף שנאספו מאתרים רבים, לא תחזית לגבי האתר שלכם. ובכל זאת, הם מסבירים למה תמונות נמצאות גבוה ברשימת הבדיקות כאשר התוכן המרכזי מופיע באיחור.

האם כל תמונה כבדה פוגעת ישירות בדירוג? לא. אין בסיס רשמי לטענה ששימוש ב־WebP, ב־AVIF או במשקל קובץ מסוים הוא גורם דירוג עצמאי. Core Web Vitals משמשים את מערכות הדירוג של Google, אבל אין ציון יחיד שמחליט לבדו מי יופיע ראשון. גם עמידה מלאה במדדים אינה מבטיחה מיקום.

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

אופטימיזציה של תמונות לא מתחילה בכפתור הדחיסה

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

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

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

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

לפני שמכווצים, צריך להבין איפה ה־LCP נתקע

LCP, או Largest Contentful Paint, מודד את הזמן עד שרכיב התוכן הגדול והמרכזי באזור הנראה מוצג למשתמש. תמונת Hero, צילום מוצר גדול או באנר ראשי הם מועמדים שכיחים. היעד לחוויה שנחשבת טובה הוא 2.5 שניות או פחות באחוזון ה־75, בנפרד למובייל ולמחשב.

אבל המספר הכולל הוא רק תחילת האבחון. הוא אומר שהיה עיכוב, לא מה גרם לו. כדי להבין היכן הזמן מתבזבז, מפרקים את ה־LCP לארבעה חלקים:

• TTFB: הזמן עד שהדפדפן מקבל את הבייט הראשון של מסמך ה־HTML.
• עיכוב בגילוי המשאב: הזמן עד שהדפדפן מתחיל לבקש את תמונת ה־LCP.
• משך ההורדה: הזמן שנדרש להעברת קובץ התמונה.
• עיכוב ברינדור: הזמן שבין סיום ההורדה לבין הצגת התמונה בפועל.

מה הדחיסה מתקנת מתוך הרשימה הזאת? בעיקר את משך ההורדה. קובץ קטן יותר עובר מהר יותר. זה חשוב, אבל זה לא פותר הכול. אם תמונת ה־Hero מסתתרת בתוך CSS, נוצרת רק לאחר הרצת JavaScript או מסומנת לטעינה עצלה, הדפדפן עלול לבקש אותה באיחור גם אחרי שהמשקל שלה ירד.

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

לכן אני מפרק את המדד לפני שאני ממליץ על המרה או על תוסף נוסף. ב־Chrome DevTools וב־Lighthouse אפשר לראות פירוט של ה־LCP, את סדר גילוי הבקשות, את משך הורדת התמונות ואת התלות בין המשאבים. הכלים לא מחליטים מה נכון לעיצוב או לעסק, אבל הם מראים באיזה שלב הזמן באמת נשרף.

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

לפעמים הממדים חוסכים יותר מהפורמט החדש

נניח שהתמונה מוצגת בעמוד ברוחב של כ־500 פיקסלים, אבל האתר שולח קובץ ברוחב 1,500 פיקסלים. הדפדפן יקטין אותה על המסך, אך המשתמש עדיין יוריד את הקובץ הגדול. זה כמו להזמין משאית כדי להעביר שקית אחת: החבילה הגיעה, אבל שילמתם על הרבה יותר ממה שהיה נחוץ.

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

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

ב־HTML משתמשים בדרך כלל ב־srcset כדי לפרט את גרסאות הקובץ, וב־sizes כדי להסביר כמה מקום התמונה צפויה לתפוס בפריסה. אם sizes אינו מתאר את העיצוב האמיתי, הדפדפן עלול לבחור קובץ גדול מדי או קטן מדי. עצם הופעת התכונות בקוד אינה מוכיחה שההגדרה נכונה.

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

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

JPEG, PNG, WebP או AVIF — איך מחליטים?

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

על הנייר, המרת כל הספרייה ל־AVIF נשמעת כמו פתרון פשוט. בפועל צריך להביא בחשבון את זמן הקידוד, את אופן השמירה על פרטים עדינים ואת כל המקומות הנוספים שבהם נעשה שימוש בתמונות. גם WebP אינו תמיד קטן יותר מ־JPEG. יש קבצים שבהם JPEG שקודד היטב יהיה קל יותר או ייראה טוב יותר במשקל דומה.

צריך להיזהר גם מקידוד חוזר. קובץ שכבר נדחס עשוי לעבור שוב בתוסף, אחר כך ב־CDN ולבסוף בתהליך בנייה. בכל תחנה הוא עלול לאבד עוד קצת איכות בלי לייצר חיסכון שמצדיק זאת. אני מעדיף לשמור את קובץ המקור ולהגדיר גורם אחד שאחראי ליצירת הגרסאות. כך אפשר להבין מי עשה מה — וחשוב לא פחות, לחזור לאחור.

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

דחיסה טובה אינה מרוץ אל הקובץ הקטן ביותר

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

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

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

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

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

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

תמונת Hero ותמונה בתחתית העמוד לא צריכות לקבל אותו יחס

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

הבעיה מתחילה כשמפעילים את הכלל הזה בלי הבחנה. בדרך כלל, תמונת ה־LCP אינה אמורה להיות מסומנת כ־loading="lazy", משום שהדפדפן מתבקש לדחות דווקא את הנכס שהמשתמש מחכה לראות.

האם שינוי ל־loading="eager" פותר הכול? לא בהכרח. הוא מונע את הדחייה של הטעינה העצלה, אך אינו מעניק לתמונה עדיפות מיוחדת. במקרים המתאימים אפשר להשתמש ב־fetchpriority="high" כדי לרמוז לדפדפן שזהו משאב חשוב במיוחד.

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

ככל האפשר, הדפדפן צריך לגלות את תמונת ה־LCP ישירות במסמך ה־HTML. תמונת רקע שמתגלה רק לאחר טעינת CSS, או רכיב שנוצר באמצעות JavaScript, עלולים להוסיף עיכוב עוד לפני שההורדה מתחילה. לעיתים טעינה מוקדמת באמצעות preload יכולה לעזור, אבל היא חייבת להתאים לקובץ שיוצג בפועל, לרבות srcset ו־sizes. טעינה מוקדמת של הגרסה הלא נכונה רק מוסיפה בקשה מיותרת.

אתר שנטען מהר, אבל קופץ, עדיין לא עבר טיפול מלא

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

כדי למנוע את התזוזה, מגדירים את המאפיינים width ו־height גם בתמונות רספונסיביות. הדפדפן משתמש בערכים האלה כדי לחשב את יחס הממדים ולשמור מקום לפני שהתמונה נטענת. CSS כמו max-width:100% ו־height:auto עדיין מאפשר לתמונה להתכווץ בהתאם למסך.

מכאן עוברים לנגישות. טקסט חלופי אינו מקום לדחוס אליו מילות מפתח, אלא דרך להעביר את מטרת התמונה למי שאינו יכול לראות אותה. תמונה דקורטיבית צריכה בדרך כלל alt="", כדי שטכנולוגיות מסייעות יוכלו לדלג עליה. תמונה פונקציונלית צריכה לתאר את הפעולה, לא רק את הצורה שלה.

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

שמות קבצים תיאוריים, טקסט חלופי נכון, כיתוב והקשר טקסטואלי עוזרים גם למנועי חיפוש להבין את הנכס, ולכן הם רלוונטיים גם לעבודתו של מומחה קידום אתרים. ההנחיות העדכניות של Bing, לרבות בהקשר של Bing ו־Copilot, מדגישות שהתמונה צריכה לחזק את הטקסט ולא להיות המקור היחיד למידע. זו עבודה נכונה מבחינת נגישות ויכולת גילוי, לא טריק דירוג.

לוורדפרס יש בסיס טוב, אבל עדיין צריך להתאים אותו לאתר

WordPress תומכת ב־srcset וב־sizes מאז גרסה 4.4. מגרסה 5.9 נוספו שיפורים שנועדו להימנע מטעינה עצלה של תמונות שסביר שיופיעו בחלק העליון של הדף, ובגרסה 6.3 נוספה האפשרות להחיל אוטומטית fetchpriority="high" על תמונה שהמערכת מעריכה כמועמדת להיות רכיב ה־LCP.

מה זה אומר בפועל? שוורדפרס כבר עושה חלק מהעבודה, אבל היא לא תמיד מכירה את כוונת העיצוב שלכם. בתהליכי בניית אתרי תדמית, תבנית או בונה עמודים יכולים להפוך את תמונת ה־Hero לרקע CSS, לבחור גדלים לא מתאימים או לייצר ערך sizes שאינו תואם לרוחב האמיתי של הרכיב.

ב־WordPress 6.5 נוספה תמיכה בהעלאה, בעריכה ובשמירה של AVIF, בתנאי שספריות עיבוד התמונה בשרת תומכות בפורמט. את תמיכת השרת אפשר לבדוק באזור בריאות האתר, תחת מידע על הטיפול במדיה. זו הבחנה חשובה: העובדה שוורדפרס מכירה את הפורמט אינה מבטיחה שהשרת מסוגל לבצע כל פעולת עיבוד.

מסמכי הפיתוח של WordPress 7.1 שפורסמו ב־2026 מתארים עיבוד תמונות בצד המשתמש באמצעות WebAssembly, יצירת גדלים נוספים והרחבת הטיפול ב־AVIF. זהו מידע שתלוי בגרסה, בדפדפן ובמצב ההטמעה. לפני המלצה מעשית צריך לבדוק מחדש איזו גרסה מותקנת באתר ואילו יכולות זמינות בה בפועל.

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

הטעויות שמקטינות קבצים אבל משאירות את הבעיה

• להמיר ספרייה שלמה בלי ניסוי: פורמט מתקדם אינו מבטיח שכל תמונה תהיה קלה יותר או תיראה טוב יותר.
• להפעיל כמה שכבות דחיסה במקביל: תוסף, CDN ותהליך בנייה עלולים לקודד את אותו קובץ שוב ושוב.
• לסמן תמונות רבות בעדיפות גבוהה: עדיפות היא משאב מוגבל, לא מדבקת שיפור.
• למחוק את מאפייני הרוחב והגובה: כך הדפדפן מתקשה לשמור מקום יציב לפני הטעינה.
• לרדוף אחרי ציון מעבדה יחיד: הרצה אחת מושפעת מתנאי הבדיקה ואינה מחליפה נתוני משתמשים אמיתיים.
• לדחוס מילות מפתח ל־alt: הטקסט החלופי נועד להעביר מטרה ומשמעות, לא לשמש רשימת ביטויים.
• לטפל רק בעמוד הבית: תבניות מוצר, קטגוריה, מאמר ודפי נחיתה עשויות להגיש תמונות בדרכים שונות.
• למחוק את המקור לאחר ההמרה: בלי קובץ מקור איכותי יהיה קשה ליצור בעתיד גדלים, פורמטים או רמות דחיסה חדשות.

יש גם טעות שקטה יותר: להכריז על הצלחה רק מפני שמשקל הקובץ ירד. זה סימן חיובי, אבל התמונה עדיין צריכה לשמור על איכותה, להגיע בזמן ולטפל בצוואר הבקבוק שבגללו העבודה התחילה. אם הקובץ קטן יותר וה־LCP לא השתנה, צריך לעצור ולבדוק מה פספסנו — לא לדחוס אותו שוב.

שאלות שחשוב לשאול לפני שמאשרים אופטימיזציה של תמונות

לפני שמתקינים תוסף, ממירים ספרייה שלמה או מוחקים קבצים, כדאי לקבל תשובות ברורות:

• מהו רכיב ה־LCP בתבניות המרכזיות, והאם הוא בכלל תמונה?
• האם העיכוב נובע מההורדה, מגילוי מאוחר, מהשרת או מהצגת הרכיב?
• באילו ממדים התמונות מוצגות במובייל ובמחשב, ואילו קבצים נשלחים בפועל?
• האם האתר מייצר גרסאות רספונסיביות שמתאימות לפריסה האמיתית?
• מי אחראי לדחיסה וליצירת הגרסאות: מערכת הניהול, תוסף, תהליך בנייה או CDN?
• מהי רמת האיכות המקובלת לכל סוג תמונה, ומי מאשר אותה מבחינה חזותית?
• האם קובצי המקור נשמרים, והאם קיימת דרך מסודרת לחזור לאחור?
• מהם נתוני הבסיס, וכיצד תימדד הצלחת השינוי לאחר העלייה לאוויר?

לצורך המדידה משלבים בדיקות מעבדה עם נתוני שטח. Lighthouse ו־DevTools מאפשרים לשחזר תנאים ולנתח בקשות. Search Console ונתוני CrUX, כאשר הם זמינים, משקפים משתמשים אמיתיים לאורך זמן. צריך לזכור שהדיווח ב־Search Console עשוי לקבץ כתובות דומות, ולכן דיווח על קבוצת עמודים אינו בהכרח תוצאה פרטנית לכל כתובת.

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

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

הטיפ האישי שלי: הדחיסה הסתירה בעיית גילוי

במבט חוזר: המשתמש אינו צריך לשלם על קובץ שלא הותאם לו

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

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

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