בטח נתקלתם בנתון הזה בעבר: בערך 70% מהעגלות באתרי קניות ננטשות עוד לפני התשלום. רוב האנשים מאשימים בכך את עלויות המשלוח או טופס מסורבל. אבל יש גורם שקט יותר שכמעט אף אחד לא מזכיר: כמה מהר עמוד התשלום שלכם באמת נטען.
כל שנייה נוספת בקופה עולה לכם כסף. מחקרים של Google ופלטפורמות מסחר שונות מצאו שאחוזי ההמרה יורדים באופן משמעותי ברגע שזמן הטעינה עובר את סף שלוש השניות. בקופה, כשהלקוח כבר הוציא את הכרטיס אשראי, הנטישה הזו פוגעת אפילו יותר. אז בואו נדבר על הגורמים הספציפיים ברמת האחסון שהופכים את הקופה למהירה, ולמה אחסון לחנויות אונליין שנבנה למטרה הזו חשוב יותר ממה שרוב בעלי החנויות מבינים.
למה עמודי קופה שונים מכל עמוד אחר
עמוד הבית והפוסטים בבלוג שלכם הם בעיקר סטטיים. עמודי קופה לא. הם דינמיים, מותאמים אישית, ומלאים בחלקים נעים: סכומי עגלה, חישובי מס, אפשרויות משלוח, קריאות לשער תשלום, נתוני סשן, ובדיקות מלאי. כל אחד מהשלבים האלה נוגע בשרת ובבסיס הנתונים שלכם.
זה אומר שהגדרת אחסון כללית שמותאמת להגשה מהירה של עמודים סטטיים עדיין יכולה להיתקע בקופה, כי צוואר הבקבוק הוא לא העמוד עצמו. זה מה שקורה מאחורי הקלעים בכל לחיצה.
בסיס הנתונים הוא בדרך כלל צוואר הבקבוק האמיתי
עמודי עגלה וקופה פונים לבסיס הנתונים כל הזמן, שולפים נתוני מוצרים, מיישמים כללי הנחה, מחשבים מחדש סכומים. בחנות עמוסה, זה מצטבר מהר. אם בסיס הנתונים שלכם לא מותאם לפעולות כתיבה מרובות ובו זמניות, הקופה מתחילה להיתקע בדיוק ברגע שאתם הכי לא יכולים להרשות לעצמכם, בזמן מבצע או קפיצת תנועה.
כתבנו בעבר על איך שאילתות בסיס נתונים איטיות חוסמות בשקט אפליקציות ווב, ותהליכי קופה הם דוגמה מובהקת לכך. כאן בדיוק אחסון לחנויות אונליין ראוי מוכיח את עצמו, כי הוא בנוי סביב העובדה שעמוד הקופה שלכם עושה הרבה יותר עבודה מכל פוסט בלוג סטטי.
קאשינג בצד השרת שמדלג נכון על עמודי הקופה
קאשינג מאיץ כמעט הכל בחנות שלכם, אבל צריך להגדיר אותו בזהירות סביב עמודי עגלה וקופה. אם תשמרו בקאש את העמודים האלה בצורה לא נכונה, לקוח אחד עלול לראות את סכום העגלה של לקוח אחר. ואם לא תשמרו בקאש נכון את שאר האתר, כל עמוד קטגוריה ומוצר ייטען לאט, ויידחוף קונים החוצה עוד לפני שהם מגיעים לקופה.
אחסון טוב לחנויות אונליין מטפל בהבחנה הזו באופן אוטומטי: שומר בקאש את הקטלוג, משאיר את העגלה והקופה דינמיים, ומנתב סשנים של משתמשים מחוברים בצורה שונה מגלישה אנונימית. אם אתם מריצים WooCommerce, סוג כזה של קאשינג מודע לפלטפורמה (דילוג על קאש בעגלה, קופה ועמוד חשבון תוך שמירה אגרסיבית בקאש של כל השאר) יוצר הבדל מדיד במהירות הנתפסת בלי לשבור פונקציונליות. קראו עוד על איך קאשינג ברמת השרת עובד אם אתם רוצים את התמונה הטכנית המעמיקה יותר.
קאשינג אובייקטים מאיץ שליפות חוזרות
מעבר לקאשינג עמודים, קאשינג אובייקטים (בדרך כלל באמצעות Redis) שומר בזיכרון תוצאות של שאילתות בסיס נתונים שחוזרות על עצמן. במסחר אלקטרוני, זה אומר שנתוני מוצרים, פרטי סשן, ותוכן העגלה לא צריכים להיות מחושבים מחדש מאפס בכל בקשה. זו החלטה ארכיטקטונית קטנה עם השפעה גדולה על מהירות הקופה, במיוחד בתקופות של תנועה גבוהה. קאשינג עם Redis הוא אחד מאותם דברים מאחורי הקלעים שרוב בעלי החנויות אף פעם לא חושבים עליהם עד שהם חסרים.
מרווח משאבים חשוב יותר ממפרטי CPU מפורסמים
הקופה כוללת גם קריאות חיצוניות, לשערי תשלום, ל-APIs של מס, למחשבוני משלוח. כל אחת מהן מוסיפה השהיה שאין לכם שליטה עליה. מה שכן אתם יכולים לשלוט בו הוא לוודא שהשרת שלכם לא כבר מתקשה עם העומס שלו כשהתשובות החיצוניות האלה חוזרות. שרת שרץ קרוב לתקרת המשאבים שלו הופך תגובה של 200 מילישניות משער תשלום להמתנה של 2 שניות אצלכם, כי האפליקציה שלכם ממתינה בתור מאחורי תהליכים אחרים.
זה חלק מהסיבה שטענו שחנויות מסחר אלקטרוני ראויות לאחסון שנבנה בדיוק לאופן שבו הן עובדות, לא אחסון משותף כללי שמותאם לאתרי תדמית.
התמודדות עם קפיצות תנועה בלי שהקופה תואט
מבצע בזק או מוצר שהופך ויראלי מביא גל של תהליכי קופה בו זמניים, לא רק צפיות בעמודים. זה דפוס עומס שונה מאוד מקפיצת תנועה באתר תוכן. שרתים שמוגדרים למסחר אלקטרוני צריכים מספיק יכולת עיבוד מקבילה וחיבורי בסיס נתונים מכוונים היטב כדי להתמודד עם עשרות או מאות אנשים שמבצעים תשלום בו זמנית מבלי שהעסקה של קונה אחד תאט את זו של אחר.
בעבור WooCommerce ספציפית, אנחנו מטפלים בזה דרך הגדרות שמותאמות לקופה, כמו התאמת טעינת קבצים בעמודים שאינם עמודי חנות והפעלת שיפור CSS ממוקד כך שתבנית הקופה נטענת מהר בלי להסיר סגנונות שהיא באמת צריכה. זהו סוג כיוונון צר וספציפי שאחסון כללי פשוט לא טורח לספק.
SSL ואבטחת תשלומים בלי השהיה נוספת
כל עמוד קופה צריך HTTPS, בלי יוצא מן הכלל. אבל תהליכי handshake של SSL/TLS כן מוסיפים קצת עומס אם הם לא מוגדרים היטב. אחסון מודרני מטפל בחידוש תעודות ובשיפור סשן TLS באופן אוטומטי, כך שהאבטחה לא באה על חשבון המהירות. אם אתם עדיין עוקבים ידנית אחרי תאריכי חידוש SSL, כדאי לתקן את זה בלי קשר לתוכניות המסחר האלקטרוני שלכם. גלו איך ניהול SSL אוטומטי עובד.
ניטור זמינות תופס תקלות בקופה לפני שהלקוחות מתלוננים
לפעמים הבעיה היא לא מהירות, אלא קופה שבורה שאף אחד לא שם לב אליה במשך שעה. ניטור זמינות רציף ונקודות קצה מתריע לצוות שלכם ברגע שהקופה מתחילה לזרוק שגיאות, במקום לגלות את זה מלקוח מתוסכל ברשתות החברתיות. הגדרות ניטור שעוקבות ספציפית אחרי נתיבי עסקאות מרכזיים, לא רק זמינות עמוד הבית, תופסות את התקלות האלה מהר יותר.
מה זה אומר בשבילכם
לנטישת עגלות יש תריסר סיבות, ולא תפתרו את כולן רק עם אחסון. אבל התשתית הטכנית, ביצועי בסיס הנתונים, גבולות קאשינג נכונים, קאשינג אובייקטים, ומרווח לקפיצות תנועה, קובעים את התקרה למהירות המקסימלית האפשרית של הקופה. שום ליטוש בממשק לא יתקן עמוד קופה שממתין לשאילתת בסיס נתונים איטית.
אם אתם בוחנים את ההגדרה הנוכחית שלכם, התחילו במדידת זמן תהליך הקופה שלכם בתנאים רגילים ובשעות עומס. אם הוא זוחל, הפתרון כנראה לא נמצא בערכת העיצוב שלכם. הוא נמצא בשכבת האחסון שמתחתיה.
