תגובות של המשיבים לסקר לגבי שיטות שונות לאופטימיזציה של תמונות
בפוסט הזה נסקור את המשוב שקיבלנו בטופס הפתוח בסקר של Google Web DevRel על טכניקות לאופטימיזציה של תמונות, שנערך בקיץ 2019. התשובות התקבלו דרך Web Fundamentals ו-@ChromiumDev. מטרת הסקר הייתה לבדוק למה רוב האתרים לא פועלים לפי השיטות המומלצות לאופטימיזציה של תמונות, למרות שזו דרך יחסית קלה לשפר את הביצועים. נתוני התשובות לא מופיעים כאן כי היו ליקויים במתודולוגיה של הסקר.
קהל
- אם אתם מפתחי אתרים, יכול להיות שהפוסט הזה יעזור לכם לגלות שיטות חדשות לאופטימיזציה של תמונות, או לקבל פרטים על האופן שבו מפתחי אתרים אחרים פתרו בעיה שאתם נתקלים בה, וגם על העלויות, היתרונות והמגבלות של כל שיטה.
- אם אתם ספקי שירותי תמונות או ספקי CDN לתמונות, יכול להיות שהפוסט הזה יעזור לכם למצוא הזדמנויות חדשות בשוק.
- אם אתם מפתחים של מסגרת, כלי build או מערכת ניהול תוכן, יכול להיות שהפוסט הזה ייתן לכם רעיונות לתכונות חדשות שאפשר להטמיע.
תגובות
WebP
- "אני אוהב את WebP, אבל הוא עדיין לא מוכן לגמרי. בנוסף, מערכת WordPress שלנו לא תומכת ב-WebP. גם אחת מאפליקציות עריכת התמונות הפופולריות ביותר, Photoshop, לא תומכת ב-WebP כברירת מחדל. לכן אנחנו לא יכולים להסתמך על אפליקציות או שירותים של צד שלישי לדחיסת תמונות".
- "Make WebP usable on Safari" (הפעלת WebP ב-Safari).
- "הייתי רוצה להשתמש ב-WebP אם הייתי יכול לייצא אותם מ-Photoshop/Figma/Sketch וכל הדפדפנים היו תומכים בפורמט הזה". [הערה: כן יש תמיכה ב-WebP ב-Sketch]
- "Next gen formatting solution would be great"
- "כדאי להפסיק להשתמש ב-WebP כשהתמיכה בדפדפנים חלשה, ולשקול להשתמש ב-PNG במקום ב-JPEG לצילומי מסך".
- "Google Docs לא תומך ב-WebP"
- "אנחנו רוצים להשתמש ב-WebP בלבד, אבל אנחנו מודאגים לגבי תאימות הדפדפנים".
- "קודם צריך לתקן את התאימות לדפדפנים ולעדכן דפדפנים מדור קודם או להוסיף תיקונים לדפדפנים מדור קודם, ואז אנשים יהיו מוכנים יותר להשתמש בסוגי תמונות חדשים כמו WebP…"
- "מומלץ לעודד מפתחי תוספים/עיצובים לדון באפשרות לספק תמיכה ב-WebP ובסוגים אחרים של תמונות מהדור הבא, כדי שאנשים שאינם מפתחים לא יצטרכו להתעסק בזה".
קובצי SVG ותמונות וקטוריות
- "אם אפשר, אני משתמש ב-SVG (מונפש). הרבה מהבעיות האלה נפתרו ב-gatsby-image. אבל כשבודקים לעומק את מה שהם עשו, ברור שזה לא הגיוני בכלל שאתר רגיל יצטרך לפתח משהו כזה כדי שהתמונות יפעלו כמו שצריך. הדפדפן צריך לקחת על עצמו יותר מהאחריות הזו".
- "האם אפשר לקבל מידע על יצירת אנימציות SVG באמצעות lottie.js?"
- "רוב הזמן אנחנו מנסים להשתמש בתמונות JPEG ברזולוציה גבוהה ובגדלים קטנים באתר שלנו כדי לקצר את זמני הטעינה. אנחנו גם מקפידים להשתמש ב-SVG כשצריך כדי לספק איכות לעיצוב רספונסיבי".
- "אנחנו מנסים להשתמש בגרפיקה וקטורית אופטימיזציה בכל התמונות, מלבד תמונות רגילות, אם אפשר".
פורמטים אחרים של תמונות
- "אנחנו צריכים ללמד אנשים בצורה טובה יותר להפסיק להשתמש ב-GIF".
טעינה מדורגת
- "חשוב לזכור את המשתמש כשמדברים על תכונות כמו טעינת פריטים ברקע, כי הרבה משתמשים מוצאים את התכונה הזו מעצבנת".
- "צריך לגרום למאפיין הטעינה האיטית לפעול עם background-image".
- "המסגרות צריכות לבצע עיבוד יעיל יותר של נכסים כברירת מחדל".
- "עברנו מטעינה איטית לפני הרבה זמן. דיווחים של משתמשים על מיליוני תמונות ואתרים שלא 'נטענים'. זו הייתה הסיכום של הצוות שלנו. קשה למשתמשים לא טכניים לתאר בעיות".
- "אני רוצה להבין טוב יותר איך משתמשים ב-Intersection Observer API לטעינה איטית במקום בשיטות מסורתיות".
- "הקוד הזה עובד טוב אצלי: pwafire.org/developer/codelabs/progressive-loading."
תמונות רקע
- "I usually load images as backgrounds in CSS"
- "התג
<img>
בעייתי וקשה לשלוט בפרטים מפורטים לגביו, במיוחד בתוכן שנשלח על ידי משתמשים. אנחנו משתמשים ב-<div>
ובסגנון background-image בתדירות גבוהה בהרבה, כי זה מאפשר לנו להשתמש ב-background-size וב-background-position ולמנוע שמשתמשים ישמרו את התמונה בלחיצה ימנית."
שקיפות
- "אנחנו בשנת 2019. איך קובצי JPG עדיין לא כוללים שקיפות אלפא?"
- "אני משתמש בקבצים מסוג PNG לתמונות רק כשאני צריך רקע שקוף".
placeholders של תמונות באיכות נמוכה (LQIP)
- "אנחנו משתמשים ב-LQIPS, וזו טכניקה מצוינת לשמירה על רמת העניין של המבקרים בלי לטעון תמונות באיכות גבוהה בשלב מוקדם מדי."
ביצועים
- "לאחרונה הייתה לנו בעיה בביצועים של תמונות. כשמשתמש גולל למטה באתר שלנו, אנחנו מציגים את 60 הכרטיסים הבאים שכוללים תמונה ממוזערת. עקב מגבלת 6 החיבורים באותו דומיין, התמונות הממוזערות נחסמו, וגם הבקשה הבאה ל-AJAX כדי לקבל את 60 הכרטיסים הבאים אם המשתמש ממשיך לגלול למטה".
- "היינו רוצים להשתמש ב-HTTP/2, אבל רוב הלקוחות שלנו משתמשים ב-IE11! לכן אנחנו בוחנים חלוקה של דומיינים או טעינת בקשות לנתוני JSON של AJAX מדומיין אחר".
התאמת גודל
- "Sorry for intrinsicsize; leveraging height/width seems better to me"
- "Looking for a way to generate less sizes, right now it's ~12"
- "שינוי דינמי של גודל התמונות הוא קשה מאוד ובלתי אפשרי בלי JavaScript".
- "כלי כמו responsivebreakpoints.com מתאים ל-web.dev :)"
תמונות באיכות גבוהה וברזולוציה גבוהה
- "How to download compress images without losing DPI quality?"
- "אנחנו חברה לניהול מסמכים. האפליקציות שלנו מטפלות במיליוני תמונות סרוקות ברזולוציה גבוהה, בדרך כלל בפורמט TIFF או PDF".
- "זה מטריד. קובצי תמונה ברזולוציה גבוהה נדרשים לפורמט הדפסה. הם חייבים להיות מותאמים לאינטרנט. קשה לצמצם את הגודל של תמונות לאינטרנט, אבל אם המחברים מספקים רק קבצים קלים לתמונות שמיועדות לפרסום במדפסת, זה יכול לגרום לבעיות. אנחנו מסיימים לתת מסרים סותרים לגבי הדרישות לשליחת כתבי יד עם גרפיקה. לאחר מכן נוצרים תהליכי עבודה מורכבים לעיבוד החומרים האלה".
יכולות הדפדפן
- "Auto responsive src crop from browser as [built-in] feature would be very useful as it is time consuming to crop all images to 4 sizes and writing all the markup. אם נוכל להעלות תמונה אחת גדולה ולכתוב תג תמונה פשוט, הדפדפנים ייצרו באופן אוטומטי את מאפייני ה-src הרבים, וזו תהיה תכונה מצוינת".
- "קשה לי להימנע מעיבוד מחדש של הדף כשרוחב התמונה מוגדר באמצעות CSS לתמונות רספונסיביות (max-width: 100%; height auto או height: width: 100%; height auto), במיוחד בשילוב עם כיוון אמנותי מתמונות או תג תמונה עם התאמה דינמית. נראה שהדרך הטובה ביותר להימנע מכך היא להשתמש ב'טריק של מרווחים שליליים' ליחס תמונה קבוע, ואז למקם את התמונה בתוך תיבת היחס הזו. תמיכה טובה יותר בדפדפנים או טיפול מותאם בתמונות יעזרו מאוד!"
- "יש להשבית את ההפעלה האוטומטית של קובצי GIF על ידי אחזור רק של הפריים הראשון".
CDN ושירותי תמונות
- "Google צריכה לספק CDN בחינם כמו Cloudflare".
- "יכול להיות שיהיו עוד כלים להגדרת התאמה דינמית ו-CDN עם ספקים שונים".
- "תמונה אחת גדולה מדי ודחוסה מדי היא פתרון מצוין ללא עלות נוספת בייצור. צריך תמונות ברוחב של כ-1,000 פיקסלים לנייד (רוחב רינדור של 500 פיקסלים). זה גם הגודל הנדרש למסכים גדולים או למחשבים שלא כוללים מסך Retina. לדעתי, שימוש ב-CDN לצורך שינוי הגודל של תמונות הוא פתרון גרוע מאוד, למרות שהשתמשתי בו בעבר. מערכת ניהול התוכן אמורה לטפל בשינוי הגודל, ואם ההגדרה של זה מורכבת מדי, פתרון יחיד הוא פשרה טובה (בינתיים)."
- "מערכת CloudFlare משנה את הגודל של התמונות שלנו באופן אוטומטי כדי להתאים אותן בצורה הטובה ביותר למסך של המשתמש. כך אנחנו יכולים לחסוך בזמן הטעינה, כי התמונות נטענות בהתאם למסך של המשתמש. לדוגמה, אם משתמש נמצא בטלפון, הוא לא יטען ברקע בגודל של מסך מחשב."
- "Cloudflare מבצעת את הפעולה הזו ברקע, בלי שנצטרך לעשות משהו מלבד לסמן תיבה בחלונית ההגדרות שלנו".
- "רק רציתי להדגיש, הסיבה היחידה שאני יכול להשתמש ב-srcset וכו' היא בגלל הקלות של Cloudinary. אבל השימוש ב-Cloudinary יקר באמת מהר. זה נראה כמו חור גדול בחוויית הפיתוח".
- "אנחנו צריכים דרך לחתוך תמונות באופן אוטומטי ובאופן חכם, כדי שאפשר יהיה להשתמש בהן ביחסי גובה-רוחב שונים בהקשרים שונים".
- "אני משתמש גם בתמונות מספקים אחרים כמו Unsplash, שבהם יש שליטה פחותה בהרבה ברזולוציה, באיכות ובדחיסת התמונות".
מערכת ניהול תוכן, פלטפורמה ו-framework
- "עדיין קשה לי להבין איזו דרך הכי טובה להשתמש בתמונות כשאני בונה אתר באמצעות מערכת ניהול תוכן. בדרך כלל, יוצרים מגדירים תמונות במימדים שונים ומצפים שהתמונות לא יתכווצו או ישתנו. לא ברור לי אם מותר להגדיר max-width או max-height לתמונות"
- "השתמשתי ב-gatsby-image בפרויקטים האחרונים שלי ולא חזרתי אחורה".
- "התמונות הן לרוב החלק הקשה, כי משתמש הקצה הוא זה שמוסיף אותן למערכת ניהול התוכן. הוא יכול להשתמש בכל גודל ובכל פורמט, ולפעמים התמונה המקורית בפורמט תמונה אידיאלי ובמידות לא זמינות."
- "קשה לתחזק את התמונות כי המערכת שלנו היא מערכת שירות עצמי. קשה להוסיף אמצעי בקרה, אלא אם הדברים קורים באופן אוטומטי בלי להשפיע על הרזולוציה. בנוסף, גם אצלנו התמונות לא נראות כמו שצריך בנייד לעומת במחשב"
- "אני עוזר לאנשים לבצע אופטימיזציה של האתרים שלהם (WordPress). הבעיות הגדולות ביותר שראיתי לגבי תמונות הן: צריך להסתמך על CDN או על יישומי פלאגין כדי ליצור WebP. מפתחי העיצובים צריכים לקודד את srcset/picture בצורה נכונה. רוב הפלאגינים לטעינה מדורגת נטענים לאט, וכתוצאה מכך חוויית המשתמש (UX) גרועה. קשה לבצע טעינה מדורגת של תמונות רקע".
עלות-תועלת
- "השיטות החדשות יעילות, אבל הן מאריכות את משך הפיתוח של האתרים".
- "חברות רבות ברשימת Fortune 500 לא ממהרות לאמץ את הסטנדרטים החדשים, כמו srcset ו-WebP. בעקבות זאת, חברות רבות התנגדו לשינוי כי הוא כרוך בעלויות פיתוח מיותרות לאתרים הקיימים. משתמשי הקצה (חוויית המשתמש) לא מדברים הרבה על השיפורים בביצועים או מדווחים עליהם. אם בכלל, זה מקשה קצת יותר לשמור תמונות מהאינטרנט".
- "יצירה וניהול של כמה גדלים וגרסאות יקרים".
- "הם תופסים הרבה מקום בשרת שלנו".
אופטימיזציה עבור מנועי חיפוש
- "קשה למצוא איזון בין איכות תמונה מקובלת לבין גודל הקובץ. מצד אחד, אני רוצה שהטעינה תהיה מהירה כדי לשפר את האופטימיזציה למנועי חיפוש, אבל מצד שני, תמונות באיכות נמוכה יפגעו בממשק המשתמש (UI) ובחוויית המשתמש (UX)."
התפקיד של תמונות באינטרנט
- "יש יותר מדי באינטרנט. מפסיקים להשתמש בתמונות חסרות תועלת שלא משפרות את התוכן הכתוב".
- "האם עדיין זוכרים את הימים שבהם לא היו תמונות באינטרנט ושיתפנו סלפי כאמנות ASCII?"
כלים, הנחיות, תקנים ושיטות מומלצות: תסכולים ובקשות
- [משתתף אחד כתב פוסט בבלוג בתגובה לסקר הזה]
- "נראה שהדרישות משתנות כל הזמן. כמפתחי אינטרנט, זה מאוד מתסכל כי שמירת התמונות בכלל דורשת זמן רב. אנחנו מבצעים אופטימיזציה כמיטב יכולתנו, בודקים את האתר, ואז חודשים לאחר מכן Google מחליטה שאפשר לדחוס את התמונות עוד יותר או שהן צריכות להיות בפורמט אחר. המצב הזה מונע מאיתנו לספק ללקוחות שלנו את הפתרון הטוב ביותר שאפשר, פתרון שיחזיק מעמד לאורך זמן, ובמקום זאת יוצר מצב שבו אנחנו והלקוחות שלנו צריכים להשקיע מאמצים יקרים. לחלק מהלקוחות שלנו שהם עסקים קטנים אין פשוט את התקציב הנדרש כדי שנמשיך לתקן תמונות ולשמור אותן מחדש בהתאם לדרישות. אין לנו תקציב לבצע את העבודה הזו במסגרת חבילות הניהול שלהם. גם כתיבת הקוד לקריאה לגדלים שונים של תמונות למכשירים שונים דורשת זמן רב. כדאי לפתח מערכת לשמירת תמונות שתהיה עקבית לאורך זמן ארוך יותר".
- "כן, לדעתי הבדיקה 'יש לצמצם ככל האפשר את מספר הבקשות ואת גודל ההעברות' ב-Lighthouse לא נכונה. אם האתר מציג תוכן דרך HTTP1.x, אז כן, אבל אם האתר מציג תוכן דרך HTTP2, מספר הבקשות פחות חשוב או שהוא לא בעיה בכלל אם הוא מגיע מאותו שם מארח. יש לי אתר קל, אבל אני טוען 30 קובצי WebP קטנים של כ-35 בקשות בסך הכול, דרך HTTP2 באותו שם מארח. מערכת Lighthouse מסמנת את הבעיה הזו כ'יש לצמצם ככל האפשר את מספר הבקשות ואת גודל ההעברות', אבל האתר מהיר מאוד, ומכיוון שנעשה שימוש ב-HTTP2 באותו שם מארח, מספר הבקשות לא מהווה בעיה. כן, הקבצים כבר קטנים (רובם בגודל של 1KB עד 2KB או פחות). אפשר לטעון ספריית sprite, אבל אז צריך לבצע עוד חישובים ב-CSS. לכן, עליך לעדכן את הדוח 'יש לצמצם ככל האפשר את מספר הבקשות ואת גודל הקובץ' ב-Lighthouse כך שיכלול את השימוש ב-HTTP2 באותו שם מארח.
- "אנשים התקשו לזכור לדחוס את התמונות שלהם".
- "התנהגות בדפדפנים שונים עדיין לא צפויה, ולכן הפתרונות הפשוטים ביותר הם לרוב הבטוחים ביותר".