הגדרת LiteSpeed Cache ל-WooCommerce: מדריך מפורט

מרבית המדריכים על LiteSpeed Cache עוברים לשונית אחר לשונית, בלי להתמקד בהגדרות שבאמת חשובות לחנויות WooCommerce.

התוצאה? בעלי חנויות מפעילים cache אגרסיבי מדי ושוברים את עמוד התשלום, או נזהרים יותר מדי, ובדרך משלמים על זה בביצועים.

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

במדריך הזה נעבור על ההחלטות שצריך לקבל כשמגדירים LiteSpeed Cache לחנות WooCommerce – מבחירת אסטרטגיית cache נכונה, דרך טיפול ב-cart fragments וקונפליקטים עם שערי תשלום, ועד הגדרות מולטי-מטבע.

אם עדיין לא הגדרתם את ההגדרות הכלליות של LiteSpeed Cache, התחילו עם המדריך המלא להגדרות LiteSpeed Cache ואז חזרו לכאן לחלק שמתמקד ב-WooCommerce.

דלגו ישירות לשלבי ההגדרה

איך LiteSpeed Cache מטפל ב-WooCommerce

LiteSpeed Cache כולל אינטגרציה מובנית עם WooCommerce דרך מודול ה-Third Party שלו. ברגע שהתוסף מזהה את WooCommerce, הוא מחיל אוטומטית כמה כללי cache מאחורי הקלעים.

התוסף מגדיר cookies ייעודיים ל-WooCommerce (כמו woocommerce_items_in_cart ו-woocommerce_cart_hash) בתור טריגרים ל-cache variation. בנוסף, הוא מסמן את דפי העגלה, עמוד התשלום ועמוד החשבון כדפים שלא נשמרים ב-cache כברירת מחדל.

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

מה הזיהוי האוטומטי מכסה

כש-LiteSpeed Cache מזהה התקנה פעילה של WooCommerce, הוא מחיל את הכללים הבאים אוטומטית:

• דפי העגלה, עמוד התשלום ועמוד החשבון מוחרגים מה-cache הציבורי.
• ה-cookie של woocommerce_items_in_cart מפעיל private cache variation.
• דפי מוצרים נכנסים ל-cache ציבורי כברירת מחדל.
• נקודות הקצה של WooCommerce REST API מכבדות את הגדרת ה-REST cache הגלובלית.

מה עדיין צריך להגדיר ידנית

הזיהוי האוטומטי לא מכסה בלוקים של ESI ל-mini-carts, החרגות של קבוצות object cache, אופטימיזציית cart fragments, התנהגות ה-crawler בקטלוגים גדולים, או cache variation למולטי-מטבע.

ושם בדרך כלל מרוויחים או מאבדים את רוב הביצועים.

Public cache, private cache, או ESI

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

מתי להשתמש בכל גישה

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

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

ESI עובד הכי טוב כשרוב הדף זהה לכל המבקרים, אבל יש לכם בלוקים דינמיים קטנים – מונה mini-cart ב-header, ווידג'ט ״נצפו לאחרונה״, או ברכה למשתמש מחובר.

בפועל, ESI מאפשר לשמור את גוף הדף ב-cache ציבורי, ולהגיש בלוקים דינמיים קטנים מתוך cache פרטי. בבלוג של LiteSpeed תמצאו פירוט טכני על אופן הפעולה של שלוש הגישות.

החרגות cache ל-WooCommerce

הזיהוי האוטומטי של LiteSpeed Cache מטפל בדפים המובנים מאליהם, אבל שווה לוודא ולהוסיף עוד כמה ידנית.

דפים להחרגה

נווטו אל LiteSpeed Cache > Cache > Excludes ותוודאו שהכתובות הבאות מופיעות תחת ״Do Not Cache URIs״:

• /cart/
• /checkout/
• /my-account/
• /wishlist/ (אם אתם משתמשים בתוסף רשימת משאלות)
• כל endpoint מותאם אישית שמציג נתונים ספציפיים למשתמש

LiteSpeed Cache בדרך כלל מוסיף את שלושת הראשונים אוטומטית, אבל בדקו ליתר ביטחון. במיוחד אחרי עדכוני WooCommerce או תוספים שעלולים לשנות את ה-slugs של הדפים.

Cookies שצריך לשים לב אליהם

תחת LiteSpeed Cache > Cache > Excludes > Do Not Cache Cookies, תיזהרו עם מה שאתם מוסיפים. הוספת cookie שמופיע בכל בקשת דף (כמו woocommerce_cart_hash) למעשה משביתה את ה-caching לכל האתר.

במקום זאת, השתמשו בגישת Vary Cookie תחת Cache > Advanced > Vary Cookies. כך LiteSpeed ייצור גרסאות cache שונות לפי ערכי cookies, במקום לוותר על cache לגמרי.

Query strings

חלק מתוספי WooCommerce מוסיפים query strings למעקב או לסינון. תחת Do Not Cache Query Strings, הוסיפו כל פרמטר שמחזיר תוצאות ספציפיות למשתמש:

• add-to-cart
• removed_item
• undo_item

פתרון בעיית ה-cart fragments

WooCommerce מגיע עם סקריפט בשם wc-cart-fragments ששולח בקשת AJAX בכל טעינת דף. הבקשה (?wc-ajax=get_refreshed_fragments) מעדכנת את ווידג'ט ה-mini-cart עם תוכן העגלה הנוכחי.

הבעיה: הקריאה הזו רצה בכל דף בודד, גם כשהעגלה ריקה וגם כשהתבנית שלכם בכלל לא מציגה mini-cart. בחנות עמוסה, הבקשות האלה מצטברות מהר. ראיתי מקרים שבהם הן היוו 30-40% מסך הבקשות לשרת.

איך לזהות את הבעיה

פתחו את DevTools בדפדפן, עברו ללשונית Network, וסננו לפי wc-ajax. אם אתם רואים בקשת get_refreshed_fragments יוצאת בדפי מוצרים או ארכיון, אתם משלמים מחיר ביצועים בכל טעינת עמוד.

בדקו את זמן התגובה – תגובה תקינה צריכה להסתיים תוך פחות מ-300ms.

אם זה לוקח יותר, וככל שיש יותר גולשים במקביל, העומס רק גדל.

שלושה פתרונות

אפשרות 1: השביתו fragments בכל מקום חוץ מהעגלה ומעמוד התשלום. זו הגישה הכי בטוחה לחנויות שלא מסתמכות על mini-cart דינמי ב-header.

add_action( 'wp_enqueue_scripts', function () {
    if ( is_cart() || is_checkout() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}, 100 );

אפשרות 2: טעינת fragments רק אחרי אינטראקציה של המשתמש. פתרון זה דוחה את קריאת ה-AJAX עד שהמבקר גולל, לוחץ או מרחף. כך שומרים על הפונקציונליות בלי לשלם את העלות מראש.

<?php
add_action( 'wp_enqueue_scripts', function () {
    if ( is_cart() || is_checkout() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}, 100 );

add_action( 'wp_footer', function () {
    if ( is_cart() || is_checkout() ) {
        return;
    }
    ?>
    <script>
    (function() {
        var loaded = false;
        function loadFragments() {
            if (loaded) return;
            loaded = true;
            var s = document.createElement('script');
            s.src = '<?php echo includes_url( "js/jquery/jquery.min.js" ); ?>';
            s.onload = function() {
                var f = document.createElement('script');
                f.src = '<?php echo WC()->plugin_url(); ?>/assets/js/frontend/cart-fragments.min.js';
                document.body.appendChild(f);
            };
            document.body.appendChild(s);
        }
        ['scroll','mouseover','touchstart','keydown'].forEach(function(e) {
            window.addEventListener(e, loadFragments, {once: true, passive: true});
        });
    })();
    </script>
    <?php
}, 99 );

אפשרות 3: טעינה מותנית על בסיס cookies. שולחים את בקשת ה-fragments רק כשקיים cookie של עגלת WooCommerce, כלומר כשלמבקר יש בפועל פריטים בעגלה.

add_action( 'wp_enqueue_scripts', function () {
    if ( is_cart() || is_checkout() ) {
        return;
    }
    if ( ! isset( $_COOKIE['woocommerce_items_in_cart'] ) || $_COOKIE['woocommerce_items_in_cart'] == 0 ) {
        wp_dequeue_script( 'wc-cart-fragments' );
    }
}, 100 );

החל מ-WooCommerce 7.8, cart fragments מושבתים כברירת מחדל אלא אם כן בלוק Cart Widget מרונדר בדף. אם אתם על WooCommerce 7.8 ומעלה, בדקו אם הסקריפט בכלל נטען לפני שמחילים את התיקונים האלה.

הגדרת ESI עבור WooCommerce

אם אתם על LiteSpeed Enterprise או משתמשים ב-QUIC.cloud, ESI מאפשר לשלב בין דפים שנשמרים ב-cache לבין בלוקים דינמיים בדיוק היכן שצריך.

בואו נראה את ההגדרות תחת LiteSpeed Cache > Cache > ESI.

אילו בלוקים כדאי לשים ב-ESI

בלוקי ה-ESI שהכי חשובים ל-WooCommerce:

• Cache Admin Bar: ON – שומר את סרגל הניהול כבלוק ESI נפרד למנהלים מחוברים הגולשים בחנות.
• Cache Comment Form: ON – שומר על טופס התגובות/ביקורות דינמי בלי לפגוע ב-cache של שאר דף המוצר.
• ESI Nonces: הוסיפו nonces ספציפיים ל-WooCommerce שצריכים להיות מוגשים דינמית. LiteSpeed כבר מגדיר מראש כמה nonces של WooCommerce (כולל של PayPal Checkout), אבל אם אתם משתמשים בתוספי צד שלישי עם nonces מותאמים, הוסיפו אותם כאן.

Mini-cart ESI

ווידג'ט ה-mini-cart הוא השימוש הנפוץ ביותר ב-ESI בחנויות WooCommerce. כש-ESI מופעל, מונה העגלה והתוכן שלה נשמרים ב-cache פרטי לכל סשן, בזמן שדף המוצר סביבם נשאר ב-cache ציבורי.

בפועל זה מבטל את הצורך בקריאת AJAX של cart fragments בכל דף. בלוק ה-mini-cart מוגש ישירות מ-ESI private cache, ומתעדכן רק כשהעגלה באמת משתנה.

Vary groups לתמחור לפי תפקיד

אם החנות שלכם משתמשת בתמחור לפי תפקיד (למשל, סיטונאי מול קמעונאי), הגדירו Vary Groups תחת לשונית ה-ESI. תנו מזהה Vary Group שונה לכל תפקיד משתמש כדי שיקבל את גרסת ה-cache הנכונה.

לדוגמה, הגדירו את התפקיד "wholesale_customer" ל-Vary Group 1 והשאירו לקוחות רגילים על 0. LiteSpeed ישמור עותקי cache נפרדים לכל קבוצה.

הגדרות Object cache עבור WooCommerce

Object caching עם Redis או Memcached מצמצם שאילתות מסד נתונים בכל טעינת דף דינמי שלא נשמר ב-cache. בחנויות WooCommerce עם קטלוגים גדולים, ההבדל ב-TTFB מורגש. במיוחד אם כבר הפעלתם HPOS לטיפול מהיר יותר בהזמנות.

נווטו אל LiteSpeed Cache > Cache > Object.

Redis מול Memcached

שניהם עובדים, אבל Redis הוא הבחירה הטובה יותר ל-WooCommerce כי הוא תומך בחיבורים מתמשכים ובמבני נתונים שמתאימים ל-sessions ול-transients של WooCommerce.

הנה מספרי TTFB מהשטח, מחנות WooCommerce שבדקתי עם ובלי Redis:

הגדרות מומלצות

• Object Cache: ON (רק אם לשרת שלכם מותקן Redis או Memcached).
• Method: Redis.
• Host: 127.0.0.1 (או נתיב Unix socket ל-latency נמוך יותר).
• Port: 6379.
• Default Object Lifetime: 3600 שניות (שעה). אל תרדו מתחת ל-600 שניות, כי זה עלול לגרום לבעיות עם טוקני איפוס סיסמה וולידציה של sessions ב-WooCommerce.
• Persistent Connection: ON.
• Cache WP-Admin: OFF – דפי הניהול של WooCommerce (הזמנות, עריכת מוצרים) חייבים לקבל נתונים חיים.
• Store Transients: ON.

קבוצות להחרגה

תחת Do Not Cache Groups, ודאו ש-comment, counts, וכל קבוצה שקשורה ל-sessions מופיעים ברשימה. ה-sessions של WooCommerce מנוהלים דרך ה-session handler שלו, אבל אם יש לכם תוספים שמאחסנים נתוני session בקבוצות object cache של וורדפרס, הוסיפו את אותן קבוצות כאן.

אסטרטגיית TTL לדפי מוצרים

לא כל דפי WooCommerce צריכים את אותו TTL. דף מוצר עם מלאי שמתעדכן מהר לא אמור לקבל את אותו משך cache כמו דף ״אודות״ סטטי.

נווטו אל LiteSpeed Cache > Cache > TTL.

TTLs מומלצים

כללי purge לשינויי מלאי ומחיר

LiteSpeed Cache כולל ״Smart Purge״ שמנקה אוטומטית את ה-cache של מוצר כשהפוסט מתעדכן. זה מכסה עריכות ידניות של מוצרים, אבל שינויי מלאי שמגיעים מהזמנות דורשים תשומת לב נוספת.

כשלקוח משלים רכישה, WooCommerce מפחית מלאי דרך ה-hook בשם woocommerce_reduce_stock. האינטגרציה של LiteSpeed בדרך כלל תופסת את זה ומנקה את ה-cache של דף המוצר.

אבל אם אתם משתמשים בתוספי ניהול מלאי צד שלישי שמעדכנים מלאי מחוץ ל-hooks הסטנדרטיים של WooCommerce, יכול להיות שתצטרכו להפעיל purge ידנית:

do_action( 'litespeed_purge_post', $product_id );

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

תחת LiteSpeed Cache > Cache > Purge, השאירו את ״Purge All On Upgrade״ מופעל. עדכוני WooCommerce יכולים לשנות את פלט התבניות, והגשת HTML ישן אחרי עדכון גורמת לבעיות layout.

אופטימיזציית CSS/JS בלי לשבור את הצ'קאאוט

תכונות אופטימיזציית העמוד של LiteSpeed Cache (כלומר minify, combine, defer) עלולות לשבור את תהליך הצ'קאאוט ב-WooCommerce. סקריפטים של שערי תשלום רגישים במיוחד לשילוב, דחייה, או עיכוב.

קונפליקטים נפוצים

• Stripe: כפתורי Google Pay ו-Apple Pay נעלמים כשסקריפטים משולבים או נדחים. stripe.js חייב להיטען סינכרונית.
• Braintree/PayPal: שדות טופס התשלום לא מתרנדרים אם סקריפטים מ-braintreegateway.com עוברים minification או עיכוב.
• Variation swatches: תוספים שמרנדרים דוגמיות צבע/מידה בדפי מוצרים עלולים להישבר אם ה-JS שלהם מאוגד עם סקריפטים אחרים.
• תוספי checkout מותאמים: CheckoutWC ודומיו דורשים ש-ESI יהיה מושבת (אגב, לפי התיעוד שלהם).

איך לאבחן

הוסיפו ?LSCWP_CTRL=before_optm לכל URL כדי לטעון את הדף בלי אופטימיזציית CSS/JS של LiteSpeed. אם הדף עובד תקין עם הפרמטר הזה, הבעיה היא בהגדרות האופטימיזציה ולא ב-cache עצמו.

אסטרטגיית החרגה בטוחה

נווטו אל LiteSpeed Cache > Page Optimization > Tuning Settings והוסיפו את הסקריפטים הבעייתיים לשדות ההחרגה הרלוונטיים:

1. JS Deferred Excludes: סקריפטים של שערי תשלום שחייבים להיטען סינכרונית (למשל stripe.js, braintreegateway.com).
2. JS Delayed Excludes: סקריפטים שנשברים כשהם נטענים רק באינטראקציה (למשל variation swatches, בוררי כמויות).
3. JS Combine Excludes: סקריפטים צד שלישי שמתנגשים כשהם מאוגדים (למשל SDKs של תשלום, מעקבי אנליטיקס בצ'קאאוט).

אם בא לכם פתרון גורף, הוסיפו את התכונה data-no-optimize לתגית script בתבנית או בתוסף שלכם כדי להחריג אותו מכל האופטימיזציות של LiteSpeed בבת אחת.

הגדרות Crawler עבור WooCommerce

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

נווטו אל LiteSpeed Cache > Crawler.

סריקה מבוססת Sitemap

ה-crawler משתמש ב-sitemap שלכם לגילוי URLs. ודאו שה-sitemap של מוצרי WooCommerce כלול (בדקו תחת Crawler > Sitemap).

אם אתם עובדים עם Yoast SEO או Rank Math, ה-sitemap של המוצרים נמצא בדרך כלל ב-/product-sitemap.xml.

כיוונון delay לקטלוגים גדולים

ה-crawl delay של ברירת המחדל עובד מצוין לחנויות קטנות. לקטלוגים גדולים, כדאי להוריד את ה-delay כדי לחמם את ה-cache מהר יותר בלי להעמיס על השרת:

• Delay: התחילו עם 500 מיקרו-שניות לחנויות עם פחות מ-1,000 מוצרים. הורידו ל-200 לקטלוגים גדולים אם השרת שלכם מחזיק.
• Run Duration: השאירו את ברירת המחדל, או הגדילו אם ה-crawler לא מספיק לסיים מחזור שלם בזמן המוקצב.
• Interval Between Runs: הגדירו ערך קצר מה-TTL הנמוך ביותר של הדפים. אם דפי מוצרים פגים אחרי 24 שעות, הריצו את ה-crawler לפחות כל 12 שעות.

מגבלת חימום cache לפי מיקום גיאוגרפי

אם החנות שלכם משתמשת בתמחור או תצוגת מטבע לפי מיקום גיאוגרפי (דרך WPML או תוסף דומה), ה-crawler יכול לחמם את ה-cache רק לפי המיקום של השרת. הוא לא יכול לדמות מבקרים ממדינות שונות.

האפשרות ״Geolocate (with page caching support)״ של WooCommerce מוסיפה פרמטר גרסה ל-URLs לפי מדינה ויוצרת רשומות cache נפרדות. מכיוון שה-crawler רץ מה-IP של השרת, הוא מחמם cache רק לאותו מיקום בודד.

מבקרים ממדינות אחרות עדיין עלולים להגיע בביקור הראשון לדף שלא חומם מראש.

אין פתרון עוקף לזה בתוך LiteSpeed Cache לבד. אם cache גיאוגרפי חשוב לחנות שלכם, ה-CDN של QUIC.cloud יכול להגיש ולחמם cache מנקודות קצה ברחבי העולם.

Caching למולטי-מטבע ורב-לשוניות

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

Caching רב-לשוני עם Polylang או WPML

אם אתם מריצים אתר וורדפרס רב-לשוני עם Polylang או WPML, LiteSpeed Cache מטפל ב-variation שפה אוטומטית דרך מבנה ה-URL. לכל גרסת שפה יש URL שונה, ולכן כל אחת מקבלת רשומת cache משלה.

לא צריך הגדרות נוספות ל-caching שפות, כל עוד תוסף התרגום שלכם משתמש ב-URLs מבוססי תיקיות או תת-דומיינים (למשל /en/shop/ מול /he/shop/).

הגדרת מולטי-מטבע

מולטי-מטבע דורש הגדרה מדויקת יותר. כשמבקר מחליף מטבע, הבחירה נשמרת ב-cookie.

LiteSpeed צריך להכיר cookie זה כדי להגיש את גרסת ה-cache הנכונה.

נווטו אל LiteSpeed Cache > Cache > Advanced > Vary Cookies והוסיפו את ה-cookie של המטבע שהתוסף שלכם משתמש בו:

• WPML + WooCommerce Multilingual: wcml_client_currency
• Aelia Currency Switcher: aelia_cs_selected_currency
• WOOCS: woocs_current_currency

ב-WPML ספציפית, יכול להיות שתצטרכו גם לכפות אחסון מבוסס cookies במקום sessions. הוסיפו את הקוד הבא ל-functions.php של התבנית:

add_filter( 'wcml_user_store_strategy', function ( $strategy, $key ) {
    return 'cookie';
}, 10, 2 );

בלי הפילטר הזה, בחירת המטבע עלולה להישמר ב-PHP session, ואת זה LiteSpeed לא יכול לנצל ל-cache variation. גישת ה-cookie מבטיחה שכל מטבע יקבל גרסת cache משלו.

שאלות נפוצות

בואו נעבור על השאלות הנפוצות:

סיכום

עד כאן על הגדרת LiteSpeed Cache ל-WooCommerce. כפי שראיתם, זה חורג מהבסיס שמכוסה במדריך הגדרות כללי. התחילו מבחירת אסטרטגיית ה-cache הנכונה (public, private, או ESI) לסוג החנות שלכם.

אחר כך טפלו ב-cart fragments, הגדירו object cache עם TTLs מתאימים, והחריגו סקריפטים של שערי תשלום מאופטימיזציית CSS/JS.

אם אתם משתמשים ב-Guest Mode, ודאו שהוא מוגדר נכון לצד ההגדרות הספציפיות ל-WooCommerce שכיסינו כאן.

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