זירוז WooCommerce ו-WordPress, עם קוד להעתקה

לפני שמתחילים: למדוד ולבחור

אי אפשר לשפר מה שלא מודדים. הריצו את האתר ב-PageSpeed Insights או GTmetrix, רשמו את התוצאה, ובעיקר בדקו על טלפון אמיתי. אחרי כל שינוי, מדדו שוב. וכדי לבחור מאיפה להתחיל, הנה מפת ההשפעה והסיכון של כל פעולה במדריך:

הכלל: התחילו מהירוק בהשפעה (תמונות, קאשינג, WooCommerce), והיזהרו עם האדום בסיכון (דחיית JavaScript).

תמונות: המשקל מספר אחת

למה עושים את זה: בכ-90% מהאתרים, התמונות הן הגורם הכבד ביותר. תמונה אחת לא מותאמת יכולה לשקול יותר מכל שאר העמוד יחד. זה הסעיף הכי משפיע במדריך, ולכן הוא ראשון.

שלושת הצעדים: ראשית, מידות נכונות, אל תעלו תמונה של 4000 פיקסל לרוחב למקום של 400. שנית, פורמט מודרני: WebP קל בהרבה מ-JPEG, ו-AVIF קל אף יותר. שלישית, תמונות רספונסיביות (srcset), וורדפרס מייצר אוטומטית כמה גדלים, כך שטלפון מקבל גרסה קטנה יותר, ודאו שהתבנית משתמשת בזה.

טעינה עצלה (lazy loading): תמונות שמחוץ למסך נטענות רק כשגוללים אליהן. זה מובנה בוורדפרס (מגרסה 5.5), אז אין צורך בתוסף ייעודי בשבילו, הרבה אנשים עדיין מתקינים תוסף מיותר לזה.

מתי לא להשתמש: אין "מתי לא", אבל אל תתקינו חמישה תוספי תמונות. תוסף אופטימיזציה איכותי אחד (שממיר ל-WebP ודוחס) מספיק.

קאשינג, דחיסה ו-CDN

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

# --- דחיסת GZIP ---
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/json image/svg+xml
</IfModule>

# --- קאשינג בדפדפן ---
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg   "access plus 1 year"
  ExpiresByType image/png    "access plus 1 year"
  ExpiresByType image/webp   "access plus 1 year"
  ExpiresByType text/css     "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

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

Object Cache (Redis / Memcached): שומר בזיכרון תוצאות של שאילתות מסד נתונים חוזרות. עוזר בעיקר לאתרים דינמיים וכבדים (למשל WooCommerce עם הרבה מוצרים). דורש תמיכה מצד האחסון, ופחות רלוונטי לאתר תדמית קטן.

WooCommerce: פולינג ונכסים

למה עושים את זה: WooCommerce טוען סקריפט שמעדכן את מונה העגלה בכל טעינת עמוד (גם בבלוג ובדף הבית), וכן גיליונות סגנון בכל האתר. בעמודים שאין בהם חנות, זו עבודה מיותרת. הקטע הראשון מבטל את פולינג העגלה מחוץ לחנות:

add_action( 'wp_enqueue_scripts', function () {
    if ( function_exists( 'is_woocommerce' )
        && ! is_woocommerce() && ! is_cart() && ! is_checkout() ) {
        wp_dequeue_script( 'wc-cart-fragments' );
    }
}, 99 );

והקטע הבא מסיר את שאר נכסי WooCommerce מעמודים שאינם חנות, עגלה, צ'קאאוט או חשבון:

add_action( 'wp_enqueue_scripts', function () {
    if ( ! function_exists( 'is_woocommerce' ) ) {
        return;
    }
    if ( ! is_woocommerce() && ! is_cart() && ! is_checkout() && ! is_account_page() ) {
        wp_dequeue_style( 'woocommerce-general' );
        wp_dequeue_style( 'woocommerce-layout' );
        wp_dequeue_style( 'woocommerce-smallscreen' );
        wp_dequeue_script( 'woocommerce' );
        wp_dequeue_script( 'wc-add-to-cart' );
        wp_dequeue_script( 'wc-cart-fragments' );
    }
}, 99 );

מתי לא להשתמש: שימו לב לשני מקרים. ראשית, אם יש לכם מיני-עגלה בהדר שמתעדכנת בזמן אמת בכל עמוד, ביטול wc-cart-fragments יגרום למונה לא להתעדכן עד רענון ידני. שנית, אם עמודי העגלה או הצ'קאאוט בנויים כעמודים מותאמים אישית (למשל דרך Elementor Pro או FunnelKit) ולא כעמודי WooCommerce הרגילים, ייתכן ש-is_cart() ו-is_checkout() לא יזהו אותם, והקוד יסיר נכסים שהם דווקא צריכים. במקרה כזה הוסיפו את מזהי העמודים לחריגה בתוך התנאי, למשל && ! is_page( array( 123, 456 ) ).

דחיית JavaScript (defer)

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

למה בחרנו ב-defer ולא ב-async: שניהם לא חוסמים את הצגת העמוד, אבל defer שומר על סדר הריצה ומריץ את הסקריפטים רק אחרי שה-HTML נבנה, כך שסקריפט שתלוי ב-jQuery או באחר עדיין יעבוד. async לעומת זאת מריץ כל סקריפט ברגע שהורד, בלי שום סדר, מה שעלול לשבור סקריפטים של חנות או טפסים. לכן defer הוא הבחירה הבטוחה.

add_filter( 'script_loader_tag', function ( $tag, $handle ) {
    // הוסיפו כאן ידיות (handles) של סקריפטים לא-קריטיים בלבד
    $defer = array( 'contact-form-7', 'my-slider' );
    if ( in_array( $handle, $defer, true ) ) {
        return str_replace( ' src', ' defer src', $tag );
    }
    return $tag;
}, 10, 2 );

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

defer מול async: שניהם לא חוסמים את בניית העמוד, אבל שונים מהותית. defer שומר על סדר הריצה ומריץ את הסקריפטים אחרי שה-HTML נבנה, מה שבטוח לסקריפטים שתלויים זה בזה או ב-jQuery. async מריץ כל סקריפט ברגע שהסתיימה הורדתו, בלי שום סדר, וזה מסוכן לסקריפטים של חנות או טפסים. לכן הבחירה כאן ב-defer היא הבטוחה.

מסד נתונים ו-Heartbeat

למה עושים את זה: וורדפרס שומר גרסאות אינסופיות של כל עמוד, מה שמנפח את מסד הנתונים. הקטע הבא מגביל אותן, והוא נכנס ל-wp-config.php (מעל השורה /* That's all, stop editing! */):

define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 120 );

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

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 60;
    return $settings;
} );

בונוס, ניקוי Transients: וורדפרס צובר בטבלת wp_options אלפי שורות זמניות (Transients) שפג תוקפן, במיוחד באתרי WooCommerce ותיקים שאוגרים נתוני סשן של אורחים. הן מנפחות את מסד הנתונים. הדרך הבטוחה לנקות אותן היא לא דרך שאילתת SQL ידנית, אלא באחת משתיים. אם יש לכם גישת WP-CLI, הפקודה הבאה מוחקת רק את פגי-התוקף:

wp transient delete --expired

או, פשוט יותר, תוסף אחזקה כמו WP-Optimize שמנקה Transients פגי-תוקף ומייעל טבלאות בלחיצה, וניתן לתזמן אותו אוטומטית.

סקריפטים מיותרים

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

add_action( 'init', function () {
    remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
    remove_action( 'wp_print_styles', 'print_emoji_styles' );
    remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
    remove_action( 'admin_print_styles', 'print_emoji_styles' );
} );

איך לוודא שזה עבד

אחרי כל שינוי: (1) רעננו את האתר ובדקו שהכול תקין, במיוחד עגלה, צ'קאאוט וטפסים. (2) הריצו שוב PageSpeed / GTmetrix והשוו למספר ההתחלתי. (3) והכי חשוב, בדקו על טלפון אמיתי איך העמוד מרגיש. אם משהו נשבר, הסירו את הקטע האחרון וזהו. עבדו קטע-קטע, לא הכול בבת אחת.