‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

בניית רכיב תמונה יעיל

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

Leena Sohoni

Kara Erickson

Alex Castle

תמונות הן מקור נפוץ לצווארי בקבוק בביצועים של אפליקציות אינטרנט, וחשוב להתמקד באופטימיזציה שלהן. תמונות לא אופטימליות תורמות לניפוח הדף ומייצגות יותר מ-70% מהמשקל הכולל של הדף בבייטים באחוזון 90^th. יש הרבה דרכים לבצע אופטימיזציה של תמונות, ולכן כדאי להשתמש ב'רכיב תמונה' חכם עם פתרונות ביצועים מובנים כברירת מחדל.

הצוות של Aurora עבד עם Next.js כדי ליצור רכיב כזה. המטרה הייתה ליצור תבנית תמונה שעברה אופטימיזציה, ומפתחי אתרים יוכלו להתאים אותה אישית. הרכיב הזה משמש כמודל טוב ומגדיר תקן ליצירת רכיבי תמונה במסגרות אחרות, במערכות לניהול תוכן (CMS) ובמערכים טכנולוגיים. שיתפנו פעולה בפיתוח רכיב דומה ל-Nuxt.js,ואנחנו עובדים עם Angular על אופטימיזציה של תמונות בגרסאות עתידיות. בפוסט הזה נסביר איך עיצבנו את רכיב התמונה של Next.js ואילו לקחים הפקנו במהלך התהליך.

רכיב תמונה כהרחבה של תמונות

בעיות והזדמנויות לאופטימיזציה של תמונות

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

תמונות ללא גודל פוגעות ב-CLS

תמונות שמוצגות בלי שצוין הגודל שלהן עלולות לגרום לחוסר יציבות בפריסה ולתרום למדד גבוה של יציבות חזותית (CLS). הגדרת המאפיינים width ו-height ברכיבי <img> יכולה לעזור למנוע שינויי פריסה. לדוגמה:

<img src="flower.jpg" width="360" height="240">

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

תמונות גדולות עלולות לפגוע ב-LCP

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

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

דחיסה לא טובה של תמונות עלולה לפגוע ב-LCP

פורמטים מודרניים של תמונות כמו AVIF או WebP יכולים לספק דחיסה טובה יותר מאשר פורמטים נפוצים כמו JPEG ו-PNG. דחיסה טובה יותר מקטינה את גודל הקובץ ב-25% עד 50% במקרים מסוימים, בלי לפגוע באיכות התמונה. ההפחתה הזו מובילה להורדות מהירות יותר עם צריכת נתונים נמוכה יותר. האפליקציה צריכה להציג פורמטים מודרניים של תמונות בדפדפנים שתומכים בפורמטים האלה.

טעינה של תמונות מיותרות פוגעת ב-LCP

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

אתגרים באופטימיזציה

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

סדרי עדיפויות: מפתחי אתרים בדרך כלל מתמקדים באופטימיזציה של קוד, JavaScript ונתונים. לכן, יכול להיות שהם לא מודעים לבעיות בתמונות או לא יודעים איך לבצע אופטימיזציה שלהן. יכול להיות שתמונות שנוצרו על ידי מעצבים או שהועלו על ידי משתמשים לא יופיעו גבוה ברשימת העדיפויות.
פתרון מוכן לשימוש: גם אם המפתחים מודעים לניואנסים של אופטימיזציה של תמונות, יכול להיות שהם לא ירצו להשתמש בפתרון אם אין פתרון מוכן לשימוש שמתאים למסגרת או לסט הטכנולוגיות שלהם.
תמונות דינמיות: בנוסף לתמונות סטטיות שמהוות חלק מהאפליקציה, משתמשים מעלים תמונות דינמיות או שולפים אותן ממסדי נתונים חיצוניים או ממערכות CMS. יכול להיות שיהיה קשה להגדיר את הגודל של תמונות כאלה אם המקור של התמונה הוא דינמי.
עומס יתר של תגי עיצוב: כדי לכלול את גודל התמונה או את srcset לגדלים שונים, צריך להוסיף תגי עיצוב לכל תמונה, וזה יכול להיות מייגע. המאפיין srcset הושק בשנת 2014, אבל רק ב-26.5% מהאתרים נעשה בו שימוש היום. כשמשתמשים ב-srcset, המפתחים צריכים ליצור תמונות בגדלים שונים. כלים כמו just-gimme-an-img יכולים לעזור, אבל צריך להשתמש בהם באופן ידני לכל תמונה.
תמיכה בדפדפן: פורמטים מודרניים של תמונות כמו AVIF ו-WebP יוצרים קובצי תמונה קטנים יותר, אבל צריך לטפל בהם באופן מיוחד בדפדפנים שלא תומכים בהם. מפתחים צריכים להשתמש באסטרטגיות כמו משא ומתן על תוכן או ברכיב <picture> כדי שהתמונות יוצגו בכל הדפדפנים.
בעיות בטעינה מדורגת: יש כמה טכניקות וספריות שזמינות להטמעה של טעינה מדורגת של תמונות בחלק הנגלל. יכול להיות שיהיה לכם קשה לבחור את האפשרות הכי טובה. יכול להיות שמפתחים לא יודעים מה המרחק הכי טוב מהחלק העליון של הדף לטעינה של תמונות שנטענות בהשהיה. הדברים מסתבכים עוד יותר בגלל גדלים שונים של אזורי תצוגה במכשירים.
שינויים בסביבה: ככל שהדפדפנים מתחילים לתמוך בתכונות חדשות של HTML או CSS כדי לשפר את הביצועים, יכול להיות למפתחים קשה להעריך כל אחת מהתכונות האלה. לדוגמה, Chrome משיק את התכונה Fetch Priority כגרסת מקור לניסיון. אפשר להשתמש בתג הזה כדי להגדיל את העדיפות של תמונות ספציפיות בדף. באופן כללי, יהיה למפתחים קל יותר אם השיפורים האלה ייבדקו ויוטמעו ברמת הרכיב.

רכיב תמונה כפתרון

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

בשנה האחרונה עבדנו עם מסגרת Next.js כדי לתכנן ולהטמיע את רכיב התמונה שלהם. אפשר להשתמש בו כתחליף מוכן לשימוש לרכיבי <img> הקיימים באפליקציות Next.js, באופן הבא.

// Before with <img> element:
function Logo() {
  return <img src="/logo.jpg" alt="logo" height="200" width="100" />
}

// After with image component:
import Image from 'next/image'

function Logo() {
  return <Image src="/logo.jpg" alt="logo" height="200" width="100" />
}

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

הגנה מפני שינויים בפריסה

כמו שציינו קודם, תמונות ללא גודל גורמות לשינויים בפריסה ותורמות ל-CLS. כשמשתמשים ברכיב Image של Next.js, מפתחים חייבים לציין את גודל התמונה באמצעות המאפיינים width ו-height כדי למנוע שינויים בפריסה. אם הגודל לא ידוע, המפתחים צריכים לציין layout=fill כדי להציג תמונה ללא גודל שמוצבת בתוך קונטיינר בגודל מסוים. לחלופין, אפשר להשתמש בייבוא של תמונות סטטיות כדי לאחזר את הגודל של התמונה בפועל בכונן הקשיח משך זמן של תהליך build ולכלול אותו בתמונה.

// Image component with width and height specified
<Image src="/logo.jpg" alt="logo" height="200" width="100" />

// Image component with layout specified
<Image src="/hero.jpg" layout="fill" objectFit="cover" alt="hero" />

// Image component with image import
import Image from 'next/image'
import logo from './logo.png'

function Logo() {
  return <Image src={logo} alt="logo" />
}

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

שיפור ההיענות

כדי שהתמונות יהיו רספונסיביות בכל המכשירים, המפתחים צריכים להגדיר את המאפיינים srcset ו-sizes ברכיב <img>. רצינו לצמצם את המאמץ הזה באמצעות רכיב התמונה. רכיב התמונה של Next.js מוגדר כך שיקבע את ערכי המאפיינים רק פעם אחת לכל אפליקציה. אנחנו מחילים אותן על כל המקרים של רכיב התמונה על סמך מצב הפריסה. הגענו לפתרון בשלושה חלקים:

נכס deviceSizes: אפשר להשתמש בנכס הזה כדי להגדיר נקודות עצירה באופן חד-פעמי על סמך המכשירים שמשותפים לבסיס המשתמשים של האפליקציה. ערכי ברירת המחדל של נקודות עצירה כלולים בקובץ התצורה.
מאפיין imageSizes: זהו גם מאפיין שאפשר להגדיר, והוא משמש לקבלת גדלי התמונות שמתאימים לנקודות עצירה של גודל המכשיר.
מאפיין layout בכל תמונה: המאפיין הזה משמש לציון אופן השימוש במאפיינים deviceSizes ו-imageSizes לכל תמונה. הערכים הנתמכים של מצב הפריסה הם fixed, ‏ fill, ‏ intrinsic ו-responsive

כשמתבצעת בקשה לתמונה עם מצבי פריסה רספונסיבי או מילוי,‏ Next.js מזהה את התמונה שצריך להציג על סמך הגודל של המכשיר שממנו נשלחת הבקשה לדף, ומגדיר את התגים srcset ו-sizes בתמונה בהתאם.

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

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

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

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

פריסה = מילוי: הרוחב והגובה מותאמים למילוי מאגר האב. (הרוחב של רכיב ההורה `<div>` מוגדר ל-300*500 בדוגמה הזו)

הוספת טעינה מדורגת מובנית

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

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

ברכיב Image של Next.js, הטעינה מוגדרת כ-"lazy" כברירת מחדל. הטעינה העצלנית מיושמת באמצעות Intersection Observer, שזמין ברוב הדפדפנים המודרניים. המפתחים לא צריכים לעשות שום דבר נוסף כדי להפעיל את התכונה, אבל הם יכולים להשבית אותה כשצריך.

טעינה מראש של תמונות חשובות

לעתים קרובות, רכיבי LCP הם תמונות, ותמונות גדולות יכולות לעכב את ה-LCP. מומלץ לטעון מראש תמונות קריטיות כדי שהדפדפן יוכל לגלות את התמונה מוקדם יותר. כשמשתמשים ברכיב <img>, אפשר לכלול רמז לטעינה מראש בכותרת ה-HTML באופן הבא.

<link rel="preload" as="image" href="important.png">

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

<Image src="/hero.jpg" alt="hero" height="400" width="200" priority />

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

עידוד אירוח תמונות עם ביצועים גבוהים

מומלץ להשתמש ברשתות CDN לתמונות כדי לבצע אופטימיזציה אוטומטית של תמונות. הן גם תומכות בפורמטים מודרניים של תמונות כמו WebP ו-AVIF. רכיב התמונה של Next.js משתמש ב-CDN של תמונות כברירת מחדל באמצעות ארכיטקטורת טעינה. בדוגמה הבאה אפשר לראות שרכיב הטעינה מאפשר הגדרה של ה-CDN בקובץ התצורה של Next.js.

module.exports = {
  images: {
    loader: 'imgix',
    path: 'https://ImgApp/imgix.net',
  },
}

במסגרת התצורה הזו, מפתחים יכולים להשתמש בכתובות URL יחסיות במקור התמונה, והמסגרת תשרשר את כתובת ה-URL היחסית עם נתיב ה-CDN כדי ליצור את כתובת ה-URL האבסולוטית. יש תמיכה ברשתות פופולריות להעברת תוכן של תמונות כמו Imgix,‏ Cloudinary ו-Akamai. הארכיטקטורה תומכת בשימוש בספק שירותי ענן מותאם אישית על ידי הטמעה של פונקציית loader מותאמת אישית לאפליקציה.

תמיכה בתמונות שמתארחות בשרתים עצמאיים

יכולים להיות מצבים שבהם אתרים לא יכולים להשתמש ב-CDN של תמונות. במקרים כאלה, רכיב התמונה צריך לתמוך בתמונות שמתארחות באופן עצמאי. רכיב התמונה של Next.js משתמש בכלי לאופטימיזציה של תמונות כשרת תמונות מובנה שמספק API שדומה ל-CDN. אם הכלי הזה מותקן בשרת, הוא משתמש ב-Sharp כדי לבצע טרנספורמציות של תמונות בייצור. הספרייה הזו היא בחירה טובה לכל מי שרוצה לבנות צינור משלו לאופטימיזציה של תמונות.

תמיכה בטעינה הדרגתית

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

רכיב התמונה של Next.js תומך בטעינה הדרגתית של התמונה באמצעות המאפיין placeholder. אפשר להשתמש בערך הזה כ-LQIP (placeholder לתמונה באיכות נמוכה) כדי להציג תמונה באיכות נמוכה או מטושטשת בזמן שהתמונה בפועל נטענת.

השפעה

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

כשחברת Leboncoin העבירה את חזית האתר שלה מ-JavaScript מדור קודם ל-Next.js, היא גם שדרגה את צינור התמונות שלה כדי להשתמש ברכיב התמונה של Next.js. בדף שהועבר מ-<img> ל-next/image, מדד ה-LCP ירד מ-2.4 שניות ל-1.7 שניות. הנפח הכולל של בייטים של תמונות שהורדו לדף ירד מ-663kB ל-326kB (עם ‎~100kB של בייטים של תמונות שנטענו בטעינה עצלה).

הפקת לקחים

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

שסתומי בטיחות עלולים לגרום יותר נזק מתועלת

בגרסה מוקדמת של רכיב התמונה של Next.js, סיפקנו מאפיין unsized שאפשר למפתחים לעקוף את דרישת הגודל ולהשתמש בתמונות עם מידות לא מוגדרות. חשבנו שזה יהיה הכרחי במקרים שבהם אי אפשר לדעת מראש את הגובה או הרוחב של התמונה. עם זאת, שמנו לב שמשתמשים ממליצים על מאפיין unsized בבעיות ב-GitHub כפתרון כללי לבעיות שקשורות לדרישות הגודל, גם במקרים שבהם הם יכולים לפתור את הבעיה בדרכים שלא יגרמו להחמרה ב-CLS. בהמשך הוצאנו משימוש את המאפיין unsized והסרנו אותו.

ההבדל בין חיכוך מועיל לבין טרטור מיותר

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

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

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

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

הגדרת תוכנית דרך להטמעת תכונות

קשה מאוד לבנות פתרון שפועל בצורה מושלמת בכל המצבים. יכול להיות שתתפתו לעצב משהו שמתאים ל-75% מהאנשים, ואז להגיד ל-25% הנותרים ש"במקרים האלה, הרכיב הזה לא בשבילכם".

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

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

סיכום

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

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

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

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