תגובות של משתתפים בסקר על טכניקות שונות לאופטימיזציה של תמונות
בפוסט הזה מפורט המשוב החופשי שצוות Google Web DevRel קיבל בסקר שערך בקיץ 2019 בנושא טכניקות לאופטימיזציה של תמונות. התגובות התקבלו דרך Web Fundamentals ו-@ChromiumDev. המטרה של הסקר הייתה לגלות למה רוב האתרים לא פועלים לפי השיטות המומלצות לאופטימיזציה של תמונות, למרות שנראה שזו דרך קלה יחסית לשפר את הביצועים. נתוני התגובות לא מופיעים כאן כי היו פגמים במתודולוגיה של הסקר.
קהל
- אם אתם מפתחי אתרים, הפוסט הזה יכול לעזור לכם לגלות שיטות חדשות לאופטימיזציה של תמונות, או פרטים על האופן שבו מפתחי אתרים אחרים פתרו בעיה שאתם מתמודדים איתה, וגם את העלויות, היתרונות והמגבלות של כל שיטה.
- אם אתם ספקי שירותי תמונות או ספקי CDN של תמונות, הפוסט הזה יכול לעזור לכם למצוא הזדמנויות חדשות בשוק.
- אם אתם מפתחים של מסגרת, כלי build או מערכת ניהול תוכן (CMS), הפוסט הזה יכול לתת לכם רעיונות לתכונות חדשות שאפשר להטמיע.
תגובות
WebP
- "אני אוהב את WebP, אבל הוא עדיין לא מוכן לגמרי. בנוסף, WordPress לא תומך ב-WebP. גם Photoshop, אחת מהאפליקציות הכי פופולריות לעריכת תמונות, לא תומכת ב-WebP באופן מובנה. לכן אנחנו לא יכולים להסתמך על אפליקציות או שירותים של צד שלישי לדחיסת תמונות".
- "Make WebP usable on Safari" (הפעלת WebP ב-Safari).
- "הייתי שמח להשתמש ב-WebP אם הייתי יכול לייצא אותם מ-Photoshop, מ-Figma או מ-Sketch, ואם כל הדפדפנים היו תומכים בפורמט הזה". [הערה: Sketch תומך ב-WebP]
- "פתרון עיצוב מהדור הבא יהיה נהדר".
- "תפסיקו לדחוף את WebP כל כך חזק כשהתמיכה בדפדפן גרועה, ותשקלו את הצורך ב-PNG במקום ב-JPEG לצילומי מסך".
- "אין תמיכה ב-WebP ב-Google Docs".
- "היינו משתמשים רק ב-WebP, אבל אנחנו חוששים לגבי התאימות לדפדפנים".
- "קודם צריך לתקן את התאימות לדפדפנים ולעדכן דפדפנים מדור קודם או להוסיף תיקונים לדפדפנים מדור קודם, ואז אנשים יהיו מוכנים יותר לאמץ סוגי תמונות חדשים כמו WebP…"
- "כדאי לעודד מפתחים של פלאגינים או עיצובים לשקול לספק תמיכה ב-WebP ובסוגי תמונות אחרים מהדור הבא, כדי שמשתמשים שהם לא מפתחים לא יצטרכו להתעסק עם זה".
תמונות וקטוריות ו-SVG
- "אם אפשר, אני משתמש ב-SVG (מונפש). gatsby-image פתר הרבה מהבעיות האלה. אבל כשבוחנים את מה שהם עשו, זה לא הגיוני שאתר רגיל יצטרך לבנות משהו כזה כדי שהתמונות יעבדו כמו שצריך. הדפדפן צריך לקחת על עצמו יותר מהאחריות הזו".
- "אפשר לתעד איך יוצרים אנימציות SVG באמצעות lottie.js?"
- "אנחנו משתדלים להשתמש באתר שלנו בתמונות JPEG ברזולוציה גבוהה ובגודל קובץ קטן, כדי למנוע זמני טעינה ארוכים. אנחנו גם מקפידים להשתמש בקובצי SVG כשצריך כדי לספק איכות לעיצוב רספונסיבי".
- "אנחנו משתדלים להשתמש בגרפיקה וקטורית שעברה אופטימיזציה לכל דבר חוץ מתמונות, אם זה אפשרי".
פורמטים אחרים של תמונות
- "אנחנו צריכים להסביר לאנשים למה כדאי להפסיק להשתמש ב-GIF".
טעינה מדורגת
- "חשוב לזכור את המשתמש כששוקלים להשתמש בתכונות כמו טעינה מדורגת, כי היא מעצבנת הרבה אנשים".
- "Make the lazy load attribute work with background-image please."
- "מסגרות צריכות לעבד נכסים בצורה טובה יותר כבר מההתחלה".
- "הפסקנו להשתמש בטעינה מדורגת לפני הרבה זמן. משתמשים מדווחים שמיליוני תמונות ואתרים "לא נטענים". זה מה שהצוות שלנו הבין. למשתמשים לא טכניים קשה לתאר בעיות".
- "אני רוצה להבין טוב יותר איך להשתמש ב-Intersection Observer API לטעינה מדורגת במקום להשתמש בשיטות המסורתיות".
- "הפתרון הזה עובד בשבילי: pwafire.org/developer/codelabs/progressive-loading".
תמונות רקע
- "בדרך כלל אני טוען תמונות כרקעים ב-CSS".
- "התג
<img>הוא בעייתי וקשה לשלוט בפרטים הקטנים שלו, במיוחד בתוכן שנשלח על ידי משתמשים. אנחנו משתמשים ב-<div>ובסגנון background-image הרבה יותר, כי הם מאפשרים לנו להשתמש ב-background-size וב-background-position, ולמנוע שמירה של התמונה בלחיצה ימנית".
שקיפות
- "אנחנו בשנת 2019. איך יכול להיות שקובצי JPG עדיין לא תומכים בשקיפות אלפא?"
- "אני משתמש בקובצי PNG לתמונות רק כשאני צריך רקע שקוף".
תמונות פלייסהולדר באיכות נמוכה (LQIP)
- "אנחנו משתמשים ב-LQIPS וזו טכניקה נהדרת לשמור על מעורבות המבקרים בלי לטעון תמונות באיכות גבוהה בשלב מוקדם מאוד".
ביצועים
- "לאחרונה הייתה לנו בעיה בביצועים של התמונות. כשהמשתמש גולל למטה באתר, אנחנו מציגים את 60 הכרטיסים הבאים, שכוללים תמונה ממוזערת. בגלל המגבלה של 6 חיבורים לאותו דומיין, התמונות הממוזערות נחסמו, וגם בקשת ה-AJAX הבאה לקבלת 60 הכרטיסים הבאים אם המשתמש ממשיך לגלול למטה".
- "היינו שמחים להשתמש ב-HTTP/2, אבל רוב הלקוחות שלנו משתמשים ב-IE11! לכן אנחנו בוחנים את האפשרות של פיצול דומיינים או טעינת בקשות נתונים של AJAX JSON מדומיין אחר".
התאמת גודל
- "סליחה על intrinsicsize, נראה לי שעדיף להשתמש ב-height/width".
- "אני מחפש דרך ליצור פחות גדלים, כרגע יש בערך 12".
- "שינוי דינמי של גודל התמונות הוא קשה מאוד ובלתי אפשרי בלי JS".
- "כלי כמו responsivebreakpoints.com מתאים ל-web.dev :)".
תמונות באיכות וברזולוציה גבוהות
- "איך מורידים תמונות דחוסות בלי לפגוע באיכות ה-DPI?"
- "אנחנו חברה לניהול מסמכים. האפליקציות שלנו מטפלות במיליוני תמונות סרוקות ברזולוציה גבוהה, בדרך כלל בפורמט TIFF או PDF".
- "זה טרטור. קבצי תמונות ברזולוציה גבוהה נדרשים לפורמט הדפסה, וחייבים להיות מותאמים לאינטרנט. זה קצת מעצבן להקטין תמונות לאינטרנט, אבל אם המחברים מספקים רק קבצים קלים לתמונות שמיועדות לפרסום בדפוס, זה יכול להיות קריטי. אנחנו מספקים מסרים סותרים לגבי הדרישות לשליחת כתבי יד עם גרפיקה. כתוצאה מכך, אנחנו צריכים להשתמש בתהליכי עבודה מורכבים כדי לעבד את החומרים האלה".
יכולת הדפדפן
- "חיתוך אוטומטי של src רספונסיבי מהדפדפן כתכונה [מובנית] יהיה שימושי מאוד, כי חיתוך של כל התמונות ל-4 גדלים וכתיבת כל תגי העיצוב גוזלים זמן רב. אם נוכל להעלות תמונה אחת גדולה ולכתוב תג תמונה פשוט, שדפדפנים ייצרו באופן אוטומטי את מאפייני ה-src המרובים, זו תהיה תכונה מנצחת".
- "באופן אישי, קשה לי להימנע מפריסה מחדש של הדף כשרוחב התמונה מוגדר על ידי CSS לתמונות רספונסיביות (max-width: 100%; height auto או height: width: 100%; height auto), במיוחד בשילוב עם ניהול אומנותי מתמונות מותאמות/תג תמונה. הדרך הכי טובה להימנע מכך היא להשתמש ב "פריצה של ריפוד שלילי" כדי לקבוע יחס תמונה קבוע, ואז למקם את התמונה בתוך תיבת היחס הזו. תמיכה טובה יותר בדפדפן או טיפול בתמונות רספונסיביות יעזרו מאוד!"
- "צריך להשבית את ההפעלה האוטומטית של קובצי GIF על ידי שליפת הפריים הראשון בלבד".
רשתות CDN ושירותי תמונות
- "Google צריכה לספק CDN בחינם כמו Cloudflare".
- "אולי כדאי להוסיף עוד כלים להגדרת התאמה דינמית ורשתות CDN עם ספקים שונים".
- "תמונה אחת גדולה מדי ודחוסה מדי היא פתרון טוב מאוד ללא עלות ייצור נוספת. אתם צריכים תמונות ברוחב של כ-1,000 פיקסלים לנייד (רוחב עיבוד של 500 פיקסלים), וזה גם הגודל שאתם צריכים למסכים גדולים או למסכי מחשב שהם לא מסכי רטינה. אני חושב שרשתות CDN לשינוי גודל של תמונות הן פתרון גרוע מאוד, למרות שהשתמשתי בהן בעבר. מערכת ניהול התוכן צריכה לטפל בשינוי הגודל, ואם זה מורכב מדי להגדרה, פתרון אחד הוא פשרה טובה (בינתיים)."
- "CloudFlare מתאימה באופן אוטומטי את התמונות שלנו לתצוגה של המשתמש. כך אנחנו יכולים לחסוך זמן טעינה, כי התמונות נטענות בהתאם למסך של המשתמש. לדוגמה, אם משתמש נמצא בטלפון, הוא לא ייטען ברקע בגודל של מחשב שולחני".
- "Cloudflare עושה את זה ברקע בלי שאנחנו צריכים לעשות שום דבר חוץ מלסמן תיבה בחלונית ההגדרות שלנו".
- "רק כדי להדגיש, הסיבה היחידה שאני מצליח להשתמש ב-srcset וכו' היא בגלל הקלות של Cloudinary. אבל Cloudinary נהיה יקר ממש מהר. זה מרגיש כמו חור גדול בחוויית הפיתוח".
- "אנחנו צריכים דרך קלה לחתוך תמונות באופן אוטומטי וחכם, כדי שהן יתאימו ליחסי גובה-רוחב שונים בהקשרים שונים".
- "אני משתמש גם בתמונות מספקים אחרים כמו Unsplash, שבהם יש פחות שליטה על הרזולוציה, האיכות והדחיסה".
מערכת ניהול תוכן, פלטפורמה ו-framework
- "אני עדיין מתקשה להבין מהי הדרך הטובה ביותר להשתמש בתמונות כשאני בונה אתר באמצעות מערכת ניהול תוכן (CMS). יוצרים נוטים להגדיר תמונות במידות שונות, ומצפים שהתמונות לא יתכווצו או ישתנו. אני לא בטוח/ה אם אפשר להגדיר רוחב מקסימלי או גובה מקסימלי לתמונות"
- "השתמשתי ב-gatsby-image בכמה פרויקטים אחרונים, ומאז אני לא יכול בלעדיו".
- "תמונות הן לעיתים קרובות החלק הקשה, כי הן מוזנות למערכת ניהול התוכן על ידי משתמש הקצה. המשתמשים יכולים להשתמש בכל גודל או פורמט, ולפעמים התמונה המקורית לא זמינה בפורמט ובמידות האידיאליים".
- "קשה לתחזק תמונות כי המערכת שלנו היא בניהול עצמי. קשה להוסיף אמצעי בקרה, אלא אם דברים קורים באופן אוטומטי בלי להשפיע על הרזולוציה. וגם התמונות לא נראות טוב בנייד לעומת המחשב"
- "אני עוזר לאנשים לבצע אופטימיזציה של האתרים שלהם (WordPress). הבעיות הכי גדולות שנתקלתי בהן בנוגע לתמונות הן: צריך להסתמך על CDN או על פלאגינים כדי ליצור WebP. מפתחי העיצוב צריכים לקודד את srcset/picture בצורה נכונה. רוב הפלאגינים של טעינה מדורגת נטענים לאט ופוגעים בחוויית המשתמש. קשה לטעון תמונות רקע באופן מדורג".
עלות/תועלת
- "השיטות החדשות יעילות, אבל הן מאריכות את זמן הפיתוח של האתרים".
- "חברות רבות ברשימת Fortune 500 לא ממהרות לאמץ את הסטנדרטים החדשים, כמו srcset ו-WebP. לכן, חברות רבות מתנגדות לשינוי הזה, כי הן רואות בו עלות פיתוח מיותרת לאתרים קיימים. השיפורים בביצועים לא נדונים או מדווחים באופן נרחב על ידי משתמש הקצה (UX). אם כבר, זה קצת מקשה על שמירת תמונות מהאינטרנט".
- "יקר ליצור ולנהל כמה גדלים וגרסאות".
- "הם תופסים הרבה מקום בשרת שלנו".
SEO
- "קשה לאזן בין איכות תמונה קבילה לבין גודל הקובץ. מצד אחד, אני רוצה שהאתר ייטען מהר כדי לשפר את ה-SEO, אבל מצד שני, תמונות באיכות נמוכה יפגעו בממשק המשתמש ובחוויית המשתמש".
התפקיד של תמונות באינטרנט
- "יש יותר מדי באינטרנט. תפסיקו להשתמש בתמונות חסרות תועלת שלא משפרות את התוכן הכתוב".
- "אתם זוכרים את התקופה שבה לא היו תמונות באינטרנט ושיתפנו תמונות סלפי בתור אמנות ASCII?"
כלים, הנחיות, תקנים ושיטות מומלצות: תסכולים ובקשות
- [אחד מהמשתתפים כתב פוסט בבלוג בתגובה לסקר הזה]
- "נראה שהדרישות משתנות כל הזמן. בתור מפתח אתרים, זה מאוד מתסכל כי לוקח הרבה זמן לשמור את התמונות מלכתחילה. אנחנו מבצעים אופטימיזציה כמיטב יכולתנו, בודקים את האתר, ואז חודשים לאחר מכן Google מחליטה שאפשר לדחוס את התמונות עוד יותר או שהן צריכות להיות בפורמט אחר. זה מונע מאיתנו לספק ללקוח את הפתרון הטוב ביותר לטווח הארוך, ובמקום זאת יוצר מאמץ יקר עבורו ועבורנו. לחלק מהלקוחות שלנו, שהם בעלי עסקים קטנים, פשוט אין תקציב לשלם לנו על תיקון התמונות ושמירה שלהן מחדש כדי לעמוד בדרישות. אין לנו תקציב לבצע את העבודה הזו במסגרת חבילות הניהול שלהם. כתיבת הקוד לקריאה לגדלים שונים של תמונות במכשירים שונים גם לוקחת זמן. היה נהדר אם הייתה מערכת לשמירת תמונות שהייתה עקבית לאורך זמן".
- "כן, נראה לי שלא הבנת נכון את ההמלצה "Keep Request Counts Low And File Sizes Small" (שמירה על מספר נמוך של בקשות ועל גודל קובץ קטן) ב-Lighthouse. אם האתר משתמש ב-HTTP1.x, אז כן, אבל אם האתר משתמש ב-HTTP2, מספר הבקשות פחות חשוב או אפילו לא מהווה בעיה אם הן מגיעות מאותו שם מארח. יש לי אתר קל, אבל אני טוען 30 קובצי WebP קטנים של כ-35 בקשות בסך הכול, דרך HTTP2 באותו שם מארח. Lighthouse מסמן את זה כבעיה מסוג "Keep Request Counts Low And File Sizes Small" (מספר בקשות נמוך וקובצי קטנים), אבל זה מהיר מאוד ובגלל HTTP2 באותו שם מארח, מספר הבקשות לא מהווה בעיה. וכן, הקבצים כבר קטנים (רובם בין 1KB ל-2KB או פחות). אפשר לטעון ספרייט, אבל אז צריך לבצע עוד חישובי CSS. לכן, צריך לעדכן את הדוח "Keep Request Counts Low And File Sizes Small" (שמירה על מספר נמוך של בקשות ועל גודל קובץ קטן) ב-Lighthouse כדי להביא בחשבון את HTTP2 באותו שם מארח".
- "אנשים מתקשים לזכור לדחוס את התמונות שלהם".
- "ההתנהגות בדפדפנים שונים עדיין לא צפויה, ולכן הפתרונות הפשוטים ביותר הם בדרך כלל הבטוחים ביותר".