כדי לשפר מהירות בחנות Shopify, משנים את התבנית, האפליקציות, התמונות וקוד האינטראקציות שבשליטת החנות, ואז בודקים את ההשפעה על מסלולי קנייה אמיתיים. Shopify מנהלת את האחסון וחלק גדול מתשתית ההגשה. העבודה המועילה לבעל החנות היא זיהוי פעולות מיותרות, הצגה מוקדמת של תוכן חיוני ושמירה על תגובה מהירה בבחירת מוצרים ובעגלה.
המדריך מתייחס לחנות Online Store המבוססת על תבניות. לחנות headless יש ארכיטקטורת רינדור ואחסון אחרת, ולכן החלטות הפריסה והמטמון שלה דורשות בדיקה נפרדת.
מפרידים בין אחריות הפלטפורמה להחלטות החנות
התיעוד של Shopify מתאר CDN מנוהל, דחיסה, תמיכה ב-HTTP/3 ואופטימיזציות נוספות. אלה יכולות של הפלטפורמה, לא הגדרות שמפתח תבנית צריך ליצור מחדש בקובץ Nginx. הפרוטוקול בבקשה מסוימת תלוי גם בחיבור ובלקוח. משאבים של אפליקציה חיצונית אינם עוברים אוטומטית דרך אותה תשתית.
חלוקת האחריות המעשית נראית כך.
| תחום | Shopify מנהלת בדרך כלל | צוות החנות יכול לשנות |
|---|---|---|
| אחסון והגשה | תשתית החנות ו-CDN של Shopify | קבצים ושירותים חיצוניים שהתבנית מבקשת |
| פלט התבנית | סביבת הרינדור של Liquid | תבניות, מקטעים, אזורים ועבודה חוזרת |
| תמונות | עיבודים והגשה נתמכים | קובצי מקור, גדלים ועדיפות טעינה |
| אפליקציות בחנות | מנגנוני שילוב | אפליקציות, הטמעות פעילות ומיקום פונקציות |
| אינטראקציות | ממשקי הדפדפן והפלטפורמה | טיפול באירועים, אתחול ועדכוני DOM |
אם דוח ממליץ לשנות כותרות שרת שאי אפשר להגדיר, מתעדים את המגבלה ובודקים את החלקים שבשליטתכם. לא מתקינים אפליקציית מהירות רק משום שדוח כללי הזכיר הגדרת שרת. קודם מזהים את המשאב שהפיק את הממצא ומי שולט בתגובה שלו.
שומרים על מסלול המשאבים הרגיל של Shopify. משתמשים במסנני הכתובות של Liquid במקום להרכיב כתובות CDN ידנית. כתובת שרת קשיחה או הסרת פרמטר גרסה עלולות לפגוע בהגשה ובעדכון שהפלטפורמה כבר מספקת.
מודדים את העמודים והפעולות שמאפשרים לקנות
מכינים קבוצת בדיקה קטנה: בית, קולקציה, מוצר, תוצאות חיפוש ועגלה. כוללים מוצר עם וריאציות ומדיה עשירה. בודקים נייד ומחשב בנפרד ומתעדים גרסת תבנית, אפליקציות פעילות, הסכמה, שוק ושפה. תצוגה מקדימה עם תוכן אחר אינה השוואה מבוקרת.
דוחות ביצועי האינטרנט של Shopify מספקים מדידות משתמשים של LCP, INP ו-CLS, גם לפי עמוד וסוג עמוד. בודקים תקופה, סינון מכשירים וכמות תנועה לפני פירוש שינוי. Shopify מציינת שעיבוד הדוחות עשוי לעכב נתונים. דוח ריק אינו הוכחה לחנות מהירה או לתקלה.
משתמשים ב-PageSpeed Insights וב-Chrome DevTools לחקר עמוד מסוים. בדיקת ניווט של Lighthouse אינה משחזרת בחירת וריאציות, מסננים או מגירת עגלה. מקליטים את הפעולות בנפרד. מדריך Core Web Vitals מסביר מדוע ציון טעינה ותגובתיות אמיתית עונים על שאלות שונות.
מתעדים התקנות אפליקציות ופרסום תבניות ביומן שינויים. אם המגמה משתנה, משווים תבניות והרכב מבקרים לפני קביעה סיבתית. קמפיין שמביא מכשירים אחרים יכול לשנות את ההתפלגות ללא שינוי בתבנית. מאשרים חשד להידרדרות באמצעות בדיקה שניתן לשחזר.
מפשטים את התבנית לפני הוספת שכבות אופטימיזציה
משכפלים את התבנית הפעילה לפני עריכה ושומרים דרך חזרה ברורה. בודקים את המסך הראשון בכל תבנית חשובה. תמונה מועילה, מחיר, זמינות, אפשרויות וניווט צריכים לעזור להבין את המוצר ולפעול. מעבירים תוכן משני להמשך בלי להסתיר מידע שנחוץ לקונה.
מסירים אזורים ובלוקים שאינם בשימוש בעותק הבדיקה. הסתרה ב-CSS אינה מונעת בהכרח טעינת HTML, מדיה וסקריפטים. בודקים פלט ובקשות רשת. מתג בעורך עשוי לשנות מראה בלי להסיר את כל התלויות.
בוחנים פעולות שחוזרות בכל כרטיס מוצר: תצוגה מהירה, מדיה בריחוף, מועדפים ותגיות מונפשות. הן יכולות להוסיף עבודה לכל כרטיס. מחליטים מה חייב להתאתחל לפני שימוש ושומרים על קישורים ומידע בסיסי בזמן טעינת ההרחבות.
משווים תבניות עם תוכן מייצג ואותם שילובים נחוצים. הדגמה דלה אינה התחייבות לביצועים בחנות מלאה. מעדיפים פונקציות מובנות שמתאימות לצורך במקום כפילות דרך כמה אפליקציות, אך מודדים בפועל ולא מסתמכים על תווית שיווקית.
בודקים אפליקציות, הטמעות ושאריות קוד
ממפים את האפליקציות ומזהים אילו פועלות בצד שהלקוחות רואים. חיבור מלאי ניהולי שונה מווידג'ט ביקורות בכל עמוד מוצר. רושמים מטרה, הטמעות פעילות, עמודי יעד ואחראי.
בעותק התבנית מכבים הטמעה או בלוק אופציונליים ומשווים את אותו מסלול. היעלמות הווידג'ט אינה מוכיחה שכל הבקשות נעצרו. בודקים את Network ואת יוזמי הסקריפטים שנותרו. בדיקת סקריפטים של צד שלישי מפרידה בין הורדה, הרצה והשפעה על פעולות.
הסרת אפליקציה יכולה להשאיר קוד שנוסף ידנית לתבנית. פועלים לפי הוראות הספק ובודקים עם המפתח מקטעים ותגיות ישנים. לא מוחקים קוד לא מוכר רק לפי שמו; בודקים הפניות ושומרים עותק שניתן לשחזר.
דוחים צ'אט, וידאו והרחבות ביקורות באמצעות הגדרות נתמכות. לא דוחים באופן עיוור תלויות תשלום או בחירת מוצר. בודקים אישור הסכמה והפעלה ראשונה, משום שהעברת כל האתחול ללחיצה אחת עלולה להחמיר תגובתיות גם כשהטעינה הראשונית השתפרה.
מבקשים תמונה מתאימה ולא רק מקטינים את המקור
שומרים מקור איכותי שמתאים לגודל התצוגה הגדול המתוכנן ומבקשים גרסאות בגודל הנכון. image_url ו-image_tag מסייעים לייצר סימון רספונסיבי. בודקים מה יורד בפועל בטלפון ובמסך צפוף פיקסלים; משקל המקור לבדו אינו מתאר את ההעברה.
קטע Liquid הבא מיועד לתבנית מוצר עם אובייקט product. הוא מניח שהתמונה הראשית היא התמונה החשובה הנראית ומועמדת ל-LCP. מתאימים את sizes לפריסה ולא נותנים עדיפות גבוהה לכל הגלריה.
{% if product.featured_image %}
{{ product.featured_image
| image_url: width: 1600
| image_tag:
widths: '400, 800, 1200, 1600',
sizes: '(min-width: 990px) 50vw, 100vw',
loading: 'eager',
fetchpriority: 'high'
}}
{% endif %}image_tag בדרך כלל מוסיף מידות ומועמדים רספונסיביים. ברירת המחדל יכולה לדחות תמונות באזורים מאוחרים. זה מועיל לתוכן משני, אך תמונה חשובה במסך הראשון אינה צריכה להמתין. בודקים את המאפיינים הסופיים לאחר שינויי אפליקציות וקוד פרטי.
נעזרים במדריך אופטימיזציית התמונות להערכת פורמט, מידות ואיכות. שומרים טקסט חלופי משמעותי ברשומת המדיה. צילום מוצר צריך לאפשר בדיקה של המוצר; הקובץ הקטן ביותר אינו בהכרח התוצאה הנכונה.
נמנעים מטעינה בו-זמנית של תמונות ראשיות לנייד ולמחשב כאשר רק אחת מוצגת. כשדרושים חיתוכים שונים, בוחרים משאב דרך סימון רספונסיבי. בודקים את תרשים הבקשות במקום להניח ש-display: none מונע הורדה. מוודאים שהחיתוך עדיין מציג את המוצר במדויק.
מונעים ממדיה וגופנים לעכב את המסך השימושי הראשון
לסרטון אופציונלי משתמשים בתמונת פתיחה או בתצוגה קלה במקום לאתחל כל נגן מיד. שומרים מידות כדי שהגעת הנגן לא תדחוף את כפתורי הרכישה. בודקים הפעלה, קול, מקלדת וחלופה כאשר הספק חסום.
בגלריות מפרידים בין התמונה הראשונה להמשך. משאירים את המדיה הנבחרת זמינה במהירות וטוענים אחרות לפי הצורך. בודקים ששינוי וריאציה מעדכן תמונה וזמינות בלי לאתחל את כל העמוד. גלריה יכולה להיראות נהדר בצילום ועדיין להיתקע בבחירה.
ממפים משפחות גופנים, משקלים ותמיכת שפות. גופן מערכת חוסך הורדה כאשר הוא מתאים לעיצוב. בגופנים מותאמים מצמצמים וריאציות מיותרות ובודקים את החלופה. לא מסירים תווים הנחוצים לחנות מתורגמת כדי לחסוך מעט נתונים.
טוענים מראש רק משאבים שהוכח שהם חיוניים. טעינה מראש של כל הגופנים או התמונות יוצרת עדיפויות מתחרות. בודקים את רצף הרשת ורכיב ה-LCP בפועל ומוודאים שהשינוי מקדים אותו בלי לעכב תוכן חשוב אחר. אותו כלל חל על סקריפט שספק מכנה קריטי.
משתמשים ב-Theme Inspector ל-Liquid וב-DevTools לדפדפן
Shopify Theme Inspector ל-Chrome מציג פרופיל רינדור Liquid בתרשים להבה. הוא מסייע לאתר מקטעים יקרים ועבודה חוזרת. הוא אינו מחליף הקלטת דפדפן של JavaScript, פריסה ואינטראקציות.
מחפשים לולאות מיותרות, הפעלות מסננים חוזרות ורינדור תוכן שהתבנית אינה צריכה. מוציאים חישובים קבועים מלולאות כאשר אפשר לשמור על ההתנהגות. מצמצמים עבודה לפני שיפורי תחביר קטנים ובודקים את הפלט אחרי כל שינוי מבני.
התיעוד העדכני מתאר גם הזרמת תגובות HTML. הדפדפן יכול לקבל את תחילת המסמך בזמן שאזורים נוספים עדיין נוצרים. לכן בית ראשון מהיר אינו מוכיח שכל התוכן הגיע מהר. קוראים את תרשים המסמך יחד עם פרופיל הרינדור.
משתמשים ב-Theme Check לאיתור בעיות סטטיות ואז בודקים בדפדפן. מעבר בדיקת קוד אינו מוכיח שבחירת וריאציה מהירה או ששירות חיצוני אמין. מתאימים כל כלי לשאלות שהוא מסוגל לענות עליהן.
משפרים תגובתיות בלי לשבש את מצב ההזמנה
מקליטים פתיחת תפריט, בחירת וריאציות, סינון והוספה לעגלה. בוחנים עבודה סביב הפעולה האיטית ומפרידים בין המתנה לפני הטיפול באירוע, עבודה בתוכו ועדכון המסך שאחריו.
מציגים מיד מצב המתנה אמיתי כאשר דרושה רשת. נמנעים מבנייה מחדש של אזורים גדולים לצורך שינוי קטן במחיר או במלאי. בודקים פעולות אפליקציות שרצות במקביל לתבנית ומאזינים כפולים אחרי החלפת אזורים.
לא מודיעים על הצלחה לפני השלמת פעולת העגלה. תגובה חזותית מהירה יכולה לאשר שהלחיצה נקלטה ובמקביל למנוע שליחה כפולה. בודקים שגיאות, וריאציות חסרות, חזרה בדפדפן ופתיחה חוזרת של העגלה. מצב הזמנה נכון הוא חלק מעבודת הביצועים.
מפרסמים שינוי שנמדד ועוקבים אחר הראיות המתאימות
הנחיות הביצועים לתבניות Shopify הן מקור היישום העיקרי. מתעדים תבנית, פונקציה, עלות חשודה, תנאי בדיקה ודרך ביטול. בוחנים את העותק לפני פרסום בתהליך הרגיל.
חוזרים על בדיקות מעבדה בתנאים זהים ועוקבים אחר משתמשים אמיתיים לאחר הפרסום. חלון דיווח היסטורי אינו מתאר מיד רק את הגרסה החדשה. משווים סוגי עמודים ומכשירים ועוקבים אחר שגיאות קנייה לצד המדדים, בלי להמציא תחזית סיבתית למכירות.
משתמשים בבודק Core Web Vitals לפירוש נתונים קיימים ובמדריכי הפלטפורמות כאשר הבעיה נוגעת גם לדפדפן. מתחילים מתבנית עם תנועה ומבעיה מדידה אחת. שומרים את השינוי רק כשהעמוד נשאר תקין והנתונים תומכים בשיפור.
