שיפור מהירות אתר – איך לגרום לאתר אלמנטור להיטען מהר יותר?

תומר, בונה אתרים ותיק, מתרגש להשיק אתר חדש ללקוח שלו – הוא עיצב את האתר, בנה אותו באלמנטור, השלים כל עמוד לפרטי פרטים, ושילב תמונות ואיורים. אך כבר ברגע שהאתר עלה לאוויר, תומר מתחיל לקבל תלונות על זמני טעינה ממושכים. הוא מראה לי וואצאפ שהלקוח העביר לו, ממשתמש שמתלונן על כך שהאתר החדש אמנם יפה מאוד, אבל זמני הטעינה מתישים. תומר אמנם התקין תוסף מטמון וניסה כמיטב יכולתו לטפל בבעיות, אך בסופו של יום נותר מתוסכל: למרות שמותקן באתר תוסף מטמון שתומר משלם עליו מידי שנה, הציון שהאתר קיבל בGoogle page speed נותר נמוך – בין 40 ל 70 (תלוי באיזה דף).

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

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

למה כולם שונאים התעסקות עם קאשינג?

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

אם זה לא מספיק מסובך גם ככה, חשוב להבין שכאשר מדברים על קאשינג (Caching) לא מדובר במנגנון יחיד אלא בשכבות רבות ושונות של קאש, שכל אחת פועלת בנקודה אחרת בתהליך הטעינה ומשלימה את האחרות. קיימים מנגנוני קאש ברמת הדפדפן, ברמת השרת, ברמת ה־CDN, ברמת מסד הנתונים או האובייקטים (Object Cache) וברמת הוידג'טים של אלמנטור (Element cache). כל שכבה מטפלת בהיבט מסוים של התהליך – החל משמירת קבצים סטטיים כמו תמונות וסקריפטים, ועד שמירה של שאילתות מסד נתונים כדי להימנע מעיבודים חוזרים. כאשר מתעוררת בעיה, למשל תוכן חדש שלא מופיע למשתמשים, קשה לעיתים לזהות איזו שכבת קאש היא האחראית לכך – הדפדפן? ה־CDN? או אולי Page cache שיצר תוסף המטמון?

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

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

למה החלטתי לכתוב על מהירות אתרים?

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

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

מהי מהירות אתר ולמה היא חשובה?

מהירות אתר היא הזמן שלוקח לעמודי האתר להיטען בדפדפן של המשתמש. זמן הטעינה מושפע משילוב של גורמים – מבנה האתר, איכות הקוד, ביצועי השרת, נפח וכמות הקבצים (תמונות, CSS, JavaScript), דחיסה של הקבצים ועוד. למה חשוב שאתר ייטען מהר?

1. חוויית משתמש (UX): אתר איטי פוגע בסבלנות הגולשים. מעבר לעובדה שמשתמשים עשויים לעזוב אתר שזמן הטעינה שלו גבוה משלוש שניות, הם גם עלולים לפתח רושם שלילי על המותג כולו.
2. קידום אורגני (SEO): מנוע החיפוש של גוגל (וגם של אחרים) שם דגש גדול על מהירות הטעינה. אתרים מהירים מדורגים לרוב טוב יותר בתוצאות החיפוש.
3. הגדלת יחס המרה (CRO): אם האתר שלכם מוכר מוצרים, מספק שירותים או מייצר לידים, זמני טעינה קצרים מגדילים את הסיכוי שהמשתמש יישאר באתר ויבצע פעולה.

איך בוחנים מהירות אתר? נעים להכיר: Core Web Vitals

Core Web Vitals (מדדי ליבה של אתרי אינטרנט), שהוצגו על ידי Google בשנת 2020, נולדו מתוך רצון למפות טוב יותר את חוויית המשתמש האמיתית בעת גלישה באתרים. הם מהווים חלק מהדוחות שמפיק הכלי ש-Google פיתחה – Lighthouse. גוגל ביקשה למקד את המדידה בפרמטרים המשקפים תחושה של "מהירות" או "נוח לגלישה", ולא רק נתונים טכניים אבסטרקטיים.

המדדים העיקריים:

1. Largest Contentful Paint (LCP) – מודד את הזמן שעובר עד שהאלמנט הגדול או המרכזי ביותר בעמוד נטען ונראה לעין – בדרך כלל תמונה, וידאו, או כותרת מרכזית באזור העליון של העמוד (Above the Fold). המדד מתמקד בחוויית המשתמש, שכן הוא מסמן את הרגע שבו התוכן העיקרי של העמוד הופך לנגיש. זמני LCP גבוהים יכולים להיגרם מטעינת משאבים כבדים (כמו תמונה גדולה או וידאו), עיבוד CSS מורכב, או זמן תגובה איטי של השרת, וניתן לשפר אותם באמצעות שיפור מהירות השרת, טעינה מוקדמת (Preload) של משאבים קריטיים, והגדרת גדלים נכונים לתמונות ולמדיה.
2. First Input Delay (FID) – מודד את הזמן שעובר מהרגע שבו המשתמש מבצע פעולה ראשונית (למשל, לחיצה על כפתור או קישור) ועד שהדפדפן מתחיל לעבד את הפעולה ולהגיב אליה. מדד זה משקף את מידת האינטראקטיביות של העמוד. עיכוב גבוה ב־FID נובע לרוב מעומס JavaScript בדפדפן, ולכן ניתן לשפרו על ידי הפחתת משקל הסקריפטים, חלוקתם לטעינה אסינכרונית ושיפור ביצועי השרת.
3. Cumulative Layout Shift (CLS) – מדד שבודק עד כמה הפריסה של הדף “זזה” או משתנה באופן בלתי צפוי בזמן טעינתו. ככל שהעמוד כולל יותר אלמנטים שעוברים ממקום למקום בזמן הטעינה (למשל, תמונות או מודעות המשנות את מיקומן), כך הערך של CLS עולה (וזה לא טוב). הרעיון המרכזי הוא להבטיח שהמשתמש לא ייתקל במצב שבו הוא לוחץ על כפתור, אך ברגע האחרון הכפתור “קופץ” והלחיצה מתבצעת במקום שונה. גם גופנים שנטענים באיחור עלולים לגרום לשינוי בגודל הטקסט או במיקומו בעמוד, מה שישפיע לרעה על ה־CLS.
4. First Contentful Paint (FCP) – מודד את הזמן שלוקח לדפדפן להציג לראשונה תוכן כלשהו מהעמוד – טקסט, תמונה או אלמנט ויזואלי אחר. למעשה, זה הרגע שבו המשתמש רואה בפעם הראשונה שיש “משהו” באתר ולא עמוד ריק, ולכן FCP נחשב למדד חשוב לחוויית המשתמש הראשונית. אם זמן ה־FCP ארוך, המשתמשים עשויים לחשוב שהאתר לא מגיב או נטען לאט מדי.

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

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

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

באיזה מכשיר האתר שלכם נבדק?

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

מתי לבדוק?

אם תבדקו את האתר מיד אחרי ניקוי קאש סביר מאוד שתקבלו תוצאה לא טובה. זה לא אומר שהאתר איטי, זה רק אומר שעיבוד המטמון עבור אותו דף לא הסתיים. מייד לאחר ריקון מטמון (Cache), שינוי במבנה הדף או ניקוי CSS שאינו בשימוש השרת עסוק בתהליכים כמו בניית מטמון מחדש או עיבוד משאבים, מה שמאט את האתר באופן זמני. יש להמתין כמה דקות עד לסיום התהליכים האלו, לטעון את הדף בצורה ידנית במצב גלישה בסתר, לוודא שהכל נטען כראוי ורק לאחר מכן לבצע בדיקה בכלי כמו PageSpeed Insights. סבלנות בתהליך הזה תבטיח הבנה אמיתית של ביצועי האתר.

רוצים מהירות? אתם מסתכלים על הדבר הלא נכון

PageSpeed Insights מציג את הביצועים של הדף בצורת ציון מספרי, אך ההתמקדות בציון עצמו היא טעות נפוצה. הציון הכללי יכול להיראות נמוך או גבוה, אבל מה שבאמת משנה זה ההסבר שמאחוריו – מהם הגורמים המשפיעים עליו? אילו מדדי Core Web Vitals ספציפיים מורידים את הציון, ומה ניתן לעשות כדי לשפר אותם? רבים נוטים להסתכל על המספר ולחפש "פתרון קסם" להעלאתו, אבל זה לא מה שיבטיח חוויית גלישה טובה יותר למשתמשים.

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

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

אנחנו מוכנים להתחיל! כל השיטות ליצירת אתר מהיר שאפרט בהמשך מבוססות על מדדי Core Web Vitals ונוגעות בדיוק בנקודות ש־Google משתמשת בהן כדי למדוד ביצועים.

מהירות אתר זה ממש לא רק התקנת תוסף קאשינג

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

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

עם זאת לא מדובר במאמר טכני מסובך: כל ההסברים במאמר הם על דברים פשוטים שלא דורשים ידע מיוחד בניהול שרתים או יכולות תיכנות.

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

צד שרת מול צד לקוח

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

פעולות בצד השרת נועדו להפחית את כמות העבודה שוורדפרס צריכה לבצע כדי לבנות דף לפני שהוא נשלח לדפדפן. כל טעינת עמוד בוורדפרס כרוכה בהרצת קוד PHP, טעינת קבצים מהתבנית והתוספים, שליפת נתונים ממסד הנתונים, עיבודם והמרתם לפלט HTML. ככל שתהליך זה מהיר ויעיל יותר, כך זמן התגובה הראשוני של השרת (TTFB – Time to First Byte) מתקצר. אופטימיזציות בצד השרת כוללות שימוש במטמון דפים (Page Cache), מטמון אובייקטים (Object Cache), קיצור זמני שאילתות למסד הנתונים, והפחתת כמות קוד ה־PHP המתבצע בכל בקשה.

פעולות בצד הלקוח מתמקדות בשיפור הדרך שבה הדפדפן מציג את התוכן לאחר שהוא מתקבל מהשרת. גם אם ה־TTFB קצר, עדיין עלול להיווצר עיכוב משמעותי בטעינת האתר אם הדף מכיל משאבים רבים כמו תמונות כבדות, סקריפטים מיותרים, או קבצי CSS גדולים ומפוצלים. אופטימיזציות בצד הלקוח כוללות דחיסת קבצים, טעינה מתוזמנת של סקריפטים (Defer או Async), הפחתת מספר הבקשות לשרת (Request Minimization), שימוש בפורמטים יעילים לתמונות (WebP/AVIF), והבטחת חוויית טעינה חלקה עם טכניקות כמו Lazy Loading.

מדדי Core Web Vitals כמו First Contentful Paint (FCP), First Input Delay (FID) ו־Largest Contentful Paint (LCP) מושפעים הן מצד השרת והן מצד הלקוח, ולכן שיפור הביצועים מחייב התייחסות לשני ההיבטים במקביל. אתר יכול להחזיר תגובה מהירה מהשרת, אך עדיין להיות כבד ואיטי בדפדפן בגלל עומס קבצים וסקריפטים. מצד שני, אופטימיזציות בצד הלקוח לא יועילו אם השרת מגיב לאט מלכתחילה. לכן, שילוב של שיפורים בשני הצדדים – הקטנת העומס על השרת לצד ניהול נכון של משאבי הדפדפן – הוא הדרך היעילה ביותר להבטיח אתר מהיר, יציב וחוויית גלישה טובה באמת.

חלקו את התוכן והתמקדו בפשטות ויזואלית – זה הבסיס לאתר מהיר

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

1. חלוקת תוכן לעמודים קטנים יותר:
   עמודים ארוכים במיוחד, עמוסי מידע, תמונות או אלמנטים דינמיים, עלולים להכביד על הטעינה וליצור חוויה מתסכלת למשתמשים. במקום עמוד אחד "ענק", עדיף לחלק את התוכן למספר עמודים או להוסיף ניווט פנימי יעיל שמאפשר טעינה הדרגתית של מידע.
2. עיצוב Above the Fold נקי:
   האזור הראשון שהמשתמש רואה (Above the Fold) צריך להיות מינימליסטי וקל משקל. מומלץ לכלול בו אלמנטים חיוניים בלבד, כמו כותרת מרכזית, לוגו ותפריט ניווט פשוט.
   אלמנטים כבדים, כמו וידאו, שקופיות מתחלפות או גלריות גדולות יעשו כאן רק נזק. המקום שלהם (אם בכלל מגיע להם מקום) הוא בהמשך העמוד.
3. מינימליזם בעיצוב ובתוכן:
   נסו להימנע מעודף אנימציות, אפקטים מורכבים, או מבנה עמודים מורכב מדי. עיצוב מינימליסטי לא רק שמשדר מקצועיות, אלא גם מפחית עומס על הדפדפן ומשפר את חוויית המשתמש.
4. אופטימיזציה של סקריפטים ואלמנטים אינטראקטיביים:
   סקריפטים של JavaScript, כמו אלו שנחוצים לצורך הפעלה של קרוסלות, אנימציות לוטי, הנפשות גלילה מבוססות GSAP, פיד אינסטגרם או טעינת וידאו רקע מYouTube יכולים להאט את העמוד באופן משמעותי. מומלץ לחסוך באלמנטים כאלו באופן כללי, וכאשר משתמשים בהם לשלב אותם רחוק מהאזור הראשון בדף, כך שיהיה אפשר לטעון אותם אחרי אינטראקציה של המשתמש (ראו JS Delay בהגדרות תוסף המטמון), והם לא יפריעו לטעינה הראשונית של הדף.

רוצים להאיץ את האתר? צמצמו תוספים

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

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

1. הימנעות מכפילויות:
   התקנת שני תוספי אופטימיזציית תמונות או שני תוספים שמנהלים מטמון במקביל יכולה ליצור בעיקר קונפליקטים, האטה ובזבוז משאבים. לפני כל התקנה, יש לבדוק אם התוסף החדש באמת נחוץ, ואם אין תוסף קיים שכבר ממלא את התפקיד. אם יש פיצ'ר מסויים שקיים בשני כלים באתר (טעינה עצלה לתמונות רקע, למשל, קיימת גם באלמנטור וגם בWP Rocket) ודאו שהוא פועל רק במקום אחד.
2. שימוש מושכל בהרחבות לאלמנטור:
   אלמנטור ואלמנטור פרו מספקים מגוון רחב של וידג'טים שימושיים, אך לעיתים קרובות יוצרים מתקינים תוספים נוספים (Add-ons) המספקים ווידג'טים נוספים. בעוד שפתרונות אלו מוסיפים לנו נוחות, כל הרחבה כזו מוסיפה קבצי CSS ו-JS, לעיתים בכל העמודים באתר, גם כשהם אינם נחוצים. המחיר של זה במהירות הוא כבד.
   מומלץ להשתמש רק בהרחבות הכרחיות ולהימנע מהתקנת תוספים המספקים פונקציות מיותרות. זה נכון גם לגבי הרחבות אהובות מאוד, כמו Jet מבית Crocoblock – כדאי ללמוד איך לבנות אתרים בלעדיהן (או לפחות להבין את הנטל הכבד שלהן על מהירות הטעינה). יצא לי פעם למחוק תוסף שלקוח שלי התקין כי הוא אהב את וידג'ט האקורדיון שהוא סיפק ועוד אייקונים מותאמים לבחירה (תוסף מוכר מספריית וורדפרס עם יותר ממיליון התקנות). המחיקה הזאת (ההתפשרות על הפיצ'רים ה"רגילים" שאלמנטור מספק) הייתה שווה לא פחות מ15 נקודות לכל העמודים (לא רק בעמודים בהם נעשה שימוש בתוסף) – אתם קולטים?
3. העדפת פתרונות קוד נקיים:
   במקרים מסוימים, ניתן להחליף תוספים בקוד מותאם אישית, במיוחד כאשר מדובר בפעולות פשוטות (כגון הוספת פונקציות קצרות לקובץ functions.php). פתרונות אלו מפחיתים את התלות בתוספים ומסייעים בשמירה על אתר מהיר ויעיל.

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

טפלו בתמונות והגישו אותן בפורמטים מתקדמים

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

קיימים תוספים רבים לדחיסת תמונות: Imagify, ShortPixel, Image Optimizer ואחרים, רובם בתשלום. כל תוסף מציע פיצ'רים מעט שונים, אבל האמת שההבדלים ביניהם לא גדולים – כולם משתמשים באלגוריתם דחיסה דומה, ואף אחד מהם לא באמת המציא איזו שיטה חדשנית שהאחרים לא שמעו עליה. כיוון שכולם עושים בערך את אותו הדבר ובאותה האיכות, הבחירה ביניהם היא בעיקר על בסיס מחיר ונוחות הממשק.

כל התוספים בשוק עושים שני דברים במקביל:

1. דחיסה (Compression)
2. הגשה בפורמט מתקדם.

דחיסה (Compression)

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

הגשה של תמונות בפורמטים מתקדמים WebP ו־AVIF

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

• WebP: נתמך ברוב הדפדפנים המודרניים, ומשיג חיסכון משמעותי בנפח בהשוואה ל־JPEG/PNG.
• AVIF: בעל פוטנציאל דחיסה חזק אף יותר, אך לא תמיד נתמך בכל הדפדפנים הישנים.

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

האם בכלל צריך תוסף לתמונות?

תוספי כיווץ תמונות עושים עבודה מצויינת הן בדחיסה והן בהמרה ל-WebP ו-AVIF. נשאלת השאלה – למה לא לעשות את זה לבד, לפני שמעלים את התמונות לאתר?

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

1. אפשר להעלות לאתר תמונות מתי שצריך, בלי הצורך המעיק לזכור לטפל בהן. באתרים שמתעדכנים לעיתים קרובות בכתבות או מוצרים חדשים זה חוסך המון זמן.
2. כשמשתפים דף מהאתר ברשתות חברתיות נטענת תמונה אוטומטית מאותו הדף, אבל זה לא עובד עם WebP ו-AVIF. כשמעלים לאתר תמונות JPG רגילות, זו האחריות של התוסף לתת לכל אחד מה שהוא צריך. לפייסבוק וואצאפ – תמונת JPG, למשתמש – תמונה בAVIF.
3. יש אחוז קטן של משתמשים עם דפדפנים ישנים שלא תומכים בפורמטים מתקדמים. תוסף ידע להגיש להם (ורק להם) את האתר תקין עם תמונות בפורמטים קלאסיים.
4. לפעמים, מסיבות שונות, דווקא קובץ ה-JPG או ה-PNG שוקל פחות מהקובץ המקביל בפורמט מתקדם. תוסף טוב ידע לזהות את המצבים האלו ובהם דווקא להגיש את הקובץ הרגיל.

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

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

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

אם אתם רוצים קצת קוד, תוכלו להוסיף עוד גדלי תמונות. אני למשל אוהב להוסיף בכל אתר גם גרסאות ברוחב 450 פיקסלים ו540 פיקסלים באמצעות קוד הPHP הבא (אפשר להכניס לfunctions.php בתבנית הבת):

// New media size
add_action( 'after_setup_theme', 'wpdocs_theme_setup' );
function wpdocs_theme_setup() {
    add_image_size( 'medium-450', 450 ); 
    add_image_size( 'medium-550', 550 ); 
}

כך, אם יש לי תמונה שהיא קצת יותר רחבה מ 300 פיקסלים (גודל סטנדרטי בוורדפרס שנקרא Medium), אני לא צריך להגדיר אותה במדרגה הבאה בגדלי התמונות – 768 פיקסלים רוחב (גודל סטנדרטי בוורדפרס שנקרא Medium large) – אני יכול פשוט לבחור את הגדלים המותאמים שיצרתי, בהתאם לצרכים שלי.

התאימו את השרת לצורכי האתר והשיגו מהירות אתר גבוהה

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

• Shared Hosting (אחסון משותף): פתרון חסכוני שבו מספר אתרים חולקים משאבים (מעבד, זיכרון, רוחב פס) על אותו שרת. בעוד שהוא מתאים לאתרים קטנים או בסיסיים, הביצועים תלויים מאוד בהתנהגות של אתרים אחרים על השרת ("שכנים"). יש לקחת בחשבון שגם בין שירותי אחסון שיתופי יש הבדלים גדולים באיכות – ספקי אחסון איכותיים יכולים להציע ביצועים טובים גם באחסון משותף, באמצעות תשתיות מודרניות ויכולת ניהול עומסים יעילה. אני אישית מאחסן כמעט רק באיחסון שיתופי, ויודע להפיק הרבה מהירות בעלות חודשית קטנה.
• VPS (שרת פרטי וירטואלי): בשרת זה, המשאבים מוקצים באופן וירטואלי לכל משתמש, כך שניתן לשלוט ברמה גבוהה יותר בהגדרות המערכת. עם זאת, גם כאן איכות הביצועים תלויה בספק ובתשתיות. ספקי VPS שונים עשויים להציע חוויות ביצועים שונות גם כאשר מפרט השרתים נראה דומה. הרבה חברות ישראליות מציעות VPS מנוהל, אך אפשר גם ליצור VPS מאפס (דורש ידע מתקדם). Cloudways הוא שירות שעוזר לאנשים ללא רקע טכנולוגי לייצר לעצמם בקלות VPS. אני לא פוסל את השירות הזה, אבל גם לא מת עליו. בעיני הוא די Overrated.

אופטימיזציה חוסכת כסף!

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

במילים אחרות: יתכן מאוד שמעבר משרת שיתופי ב30 ש"ח לחודש לשרת פרטי (VPS) ב300 ש"ח לחודש תהיה שווה לכם 10 נקודות בPageSpeed Insights. אבל היי – זה לשלם פי 10 אז זה לא חכמה! בעיני הרבה יותר מגניב להישאר בשרת של 30 ש"ח בחודש ואת אותן 10 נקודות מהירות להשיג בזכות כמה שעות של עבודת אופטימיזציה נכונה!

מיקום השרת משפיע

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

העדיפו שרתי LiteSpeed – הם בנויים מראש לשיפור מהירות אתר

שרתים המבוססים על LiteSpeed הפכו לפופולריים במיוחד בשנים האחרונות, בשל היכולת שלהם לשפר ביצועים משמעותית בהשוואה לשרתים מבוססי Apache, המהווים עדיין ברירת מחדל במרבית פתרונות האחסון. היתרונות של LiteSpeed כוללים מנגנון מטמון מובנה (LSCache), ביצועים טובים יותר עם HTTP/2 ו־HTTP/3: LiteSpeed ויעילות בניהול משאבים. בחירה בשרת מבוסס LiteSpeed היא בחירה מצויינת שאינה כרוכה בחסרונות בולטים, וזו אחת הדרכים הכי קלות להרוויח עוד נקודות.

למה זה כמעט בלתי אפשרי להשוות מהירות בין שרתים?

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

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

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

בדיקות Ping – שימושיות, אך לא מספקות את כל התמונה

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

אז איך בכל זאת מזהים שרתים מהירים יותר?

למרות כל המשתנים, יש ספקי אחסון ושרתים שבאופן עקבי מציגים ביצועים טובים יותר מאחרים. הדבר ניכר במיוחד במבחנים ארוכי טווח שבהם נבדקים לא רק זמני תגובה בודדים, אלא גם יציבות הביצועים לאורך זמן, רמת האופטימיזציה של התשתיות, ותפקוד האתר בתנאי עומס. במקרים כאלו, בדיקות כמו Time to First Byte (TTFB), בדיקות עומס עם מספר מבקרים במקביל, ומדידות בפלטפורמות ניטור אובייקטיביות (כגון GTmetrix או WebPageTest) מספקות תמונה אמינה יותר מאשר מדידה נקודתית אחת.

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

גרסאות PHP – החל מגרסאות PHP 8.x נרשמה עלייה מהותית בביצועים בהשוואה לגרסאות קודמות. גרסאות אלו כוללות שיפורי אבטחה נוספים, לצד יכולת להפעיל את האתר בעומס רב יותר באותם משאבים. כדאי מאוד להריץ את האתר על גבי PHP 8.3, שהיא הגרסה היציבה הכי חדשה נכון לכתיבת שורות אלו. אם יש לכם אתר ישן שעדיין רץ על PHP 7.4 (או חס וחלילה PHP 5.6) אתם תגלו שרק ההעברה שלו לPHP 8.3 מאיצה אותו משמעותית.

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

מגבלת זיכרון – כל חשבון בשרת מגיע עם מגבלת זיכרון שמוגדרת כברירת מחדל. לפעמים ברירת המחדל כל כך נמוכה שהיא לא מאפשרת לשרת להקצות לאתר את משאבי הזיכרון הדרושים לו לפעולה תקינה. יש לקבוע מגבלת זיכרון (Memory Limit) מתאימה לסוג האתר. אתרים שמשתמשים באלמנטור, WooCommerce או תוספים כבדים אחרים, עשויים להזדקק ל־512MB (ולפעמים אף יותר). בעזרת העלאת הגדרה זו בממשק פאנל הניהול (לרוב תחת הגדרות PHP), בקובץ php.ini או wp-config.php, ניתן למנוע מצבים של קריסה או האטה בגלל מחסור בזיכרון. שימו לב – מגבלת הזיכרון היא חשובה. אנחנו רוצים להגביל את הזיכרון. זה לא טוב בכלל להעלות את המגבלה בצורה מופרזת (למשל ל2GB).

השתמשו ב־Cloudflare זה יכול לשפר את מהירות האתר ולהקל על עומסים

Cloudflare הוא שירות רשת המספק שכבת הגנה ושיפור ביצועים לאתרים באמצעות רשת שרתים גלובלית (CDN – Content Delivery Network). השירות מפיץ את התוכן של האתר דרך שרתים מבוזרים ברחבי העולם, מה שמאפשר למבקרים לקבל תוכן משרת הקרוב אליהם פיזית, ובכך משפר את מהירות הטעינה. בנוסף, Cloudflare כולל תכונות אבטחה כמו הגנה מפני מתקפות DDoS, מנגנון חומת אש (WAF), ואפשרויות אופטימיזציה כמו דחיסת קבצים והאצת פרוטוקולי HTTP. בעוד ש-Cloudflare מציעים למשתמשים בתשלום שלל פיצ'רים מתקדמים, הרי שגם התכנית החינמית שלהם מציעה לא מעט, ויכולה לעשות הרבה טוב לאתר שבניתם.

לא כל אתר צריך להיות מוגש דרך Cloudflare, אבל להרבה אתרים זה ממש עושה פלאים:

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

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

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

רוצים דוגמה? קבלו:

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

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

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

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

מחיקת קאש של קלאודפלייר ישירות דרך וורדפרס

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

שתי דרכים לריקון קאש אוטומטי מתוך וורדפרס

1. באמצעות WP Rocket
   WP Rocket כולל Add-on ייעודי ל־Cloudflare, שמאפשר לרוקן קאש אוטומטית בכל פעם שמתפרסם או מתעדכן תוכן חדש. היתרון של גישה זו הוא אינטגרציה ישירה עם המערכת לניהול מטמון של WP Rocket, כך שהתוסף יכול לסנכרן את ניהול הקאש בין רמות שונות (שרת, דפדפן, Cloudflare).
2. באמצעות התוסף הרשמי של Cloudflare
   Cloudflare הוא התוסף הרשמי שמספקת Cloudflare, ומאפשר שליטה ישירה על כל ההגדרות מבלי לצאת מלוח הבקרה של וורדפרס. אחד היתרונות הגדולים של התוסף הוא תמיכה ב־Automatic Platform Optimization (APO) – טכנולוגיה שמטמיעה את הקאש בצורה אופטימלית עבור אתרי וורדפרס ומאיצה את ביצועי צד הלקוח על ידי הפחתת בקשות לשרת.

בין אם תבחרו להשתמש ב־WP Rocket או בתוסף הרשמי של Cloudflare, תצטרכו לספק שלושה פרמטרים לזיהוי והתחברות לשירות:

• Email – כתובת האימייל המקושרת לחשבון קלאודפיילר בו מנוהל האתר.
• Global API Key – מפתח API שמאפשר לתוסף לגשת לחשבון Cloudflare ולבצע פעולות כמו ריקון קאש (תוכלו ליצור אחד בלוח הבקרה של Cloudflare תחת My Profile > API Tokens).
• Zone ID – מזהה ייחודי של האתר בתוך Cloudflare, שמאפשר חיבור ישיר לניהול הדומיין שלכם (הוא נמצא בלוח הבקרה של Cloudflare בסרגל הצד בלשונית Overview).

הפעילו מטמון (Caching) ברמת ה־PHP והשרת

הפעלת OPcache

OPcache הוא מודול מובנה ב־PHP המאפשר לשמור בזיכרון את הגרסה המהודרת (Compiled Bytecode) של קבצי PHP.

• איך מפעילים? ברוב שרתי VPS או שרתים ייעודיים ניתן לאפשר OPcache דרך ממשק הגדרות הPHP, או בקובץ ההגדרות של PHP (php.ini), על ידי הפעלת השורה opcache.enable=1.
• השפעה על ביצועים: באתרים עתירי בקשות (כמו חנויות אינטרנט) ההבדל יכול להיות משמעותי: במקום לטעון מחדש את קובצי PHP מהדיסק ולהדר אותם בכל טעינה, המערכת משתמשת בגרסה שבזיכרון.

Object Cache – Redis או Memcached

Object Cache מאחסן את אובייקטי ה־PHP והשאילתות למסד בזיכרון, ומונע ביצוע קריאות חוזרות למסד. זה לא מאוד עוזר באתרים קטנים (One pager או אתר תדמית של 4 דפים וזהו), אבל ככל שמדובר באתר גדול יותר כך ברור שאתם צריכים להגדיר לו Object Cache:

• בחירת מערכת Cache: Redis או Memcached הן שתי אפשרויות נפוצות. Redis גמיש מאוד ומציע ביצועים טובים, אך Memcached גם יעיל וסביר.
• הפעלה ברמת השרת: אם השרת שלכם תומך ב-Redis תוכלו להפעיל את המודול המתאים ב־PHP (php-redis). הדרך המדוייקת לעשות זאת משתנה משרת לשרת.
• תוסף בוורדפרס: לאחר הפעלת השירות בשרת, מתקינים תוסף ייעודי (למשל "Redis Object Cache"). לאחר ההתקנה, מגדירים את פרטי החיבור ל־Redis.
• יתרונות ביצועים: הפחתה עקבית במספר השאילתות החוזרות על עצמן. באתרים גדולים, ההבדל מתבטא בזמן תגובה מהיר יותר וביכולת התמודדות עם מספר רב של משתמשים במקביל.

הגדירו את אלמנטור למקסימום ביצועים

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

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

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

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

הגדירו תוסף מטמון (Caching Plugin)

הרבה מפעולות האופטימיזציה מתבצעות באמצעות תוסף מטמון. אלא שהשם הזה מבלבל – תוספי "מטמון" מבצעים גם מטמון אבל גם שלל פעולות אופטימיזציה אחרות, שלא נופלות תחת ההגדרה הפשוטה של מטמון. אני אישית עובד עם WP Rocket.

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

WP Rocket הוא היום הפיתרון השולט בשוק, ובעל מוניטין מצויין. יש עוד כמה חלופות נפוצות:

• LiteSpeed Cache (רלוונטי רק בשרתים המבוססים על LiteSpeed)
• Breeze (יעודי לאתרים שמאוחסנים ב-Cloudways)
• W3 Total Cache
• WP Fastest Cache

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

כל תוסף מספק ממשק להתאים הגדרות, אך חלק מהפעולות החשובות ביותר שהוא עושה פעילות מרגע שהתוסף פועל באתר, ולא דורשות בכלל התערבות שלכם. דחיסת GZIP, למשל, מקטינה את נפח הדף (HTML, CSS, JS) לפני שליחתו למשתמש ומצמצמת את התעבורה בין השרת לדפדפן. כל התוספים עושים את זה, אבל ברובם לא תצטרכו לבחור בזה – זה פשוט יקרה.

הגדרות בטוחות בתוספי מטמון

• דחיסה של קבצי CSS/JS.
• הפעלת Lazy Load לתמונות, וידאו וIframe.
• הפעלת Lazy Load לתמונות רקע – אל תפעילו אם הפעלתם את הפיצ'ר הזה דרך אלמנטור.
• Image Dimensions – הוספת הגדרות רוחב וגובה לתמונות, במקרה של תמונה שנטענת ללא התכונות האלו.
• טעינת Google Fonts לוקאלית (חוסך קריאה לשרתי Google) – אל תפעילו אם הפעלתם את הפיצ'ר הזה דרך אלמנטור
• הפעלת Preload לדף
• הפעלת Preload לקישורים (כשמשתמש מרחף מעל קישור דף היעד מתחיל להיטען ברקע, וכך מוגש מהר יותר אם המשתמש ילחץ על הקישור)
• הפעלת Preload לפונטים – אם אתם משתמשים באתר בפונטים מותאמים שהעליתם לאתר, זה חשוב שתוסיפו את נתיבי הקבצים כך שייטענו מהר יותר.
• הפחתת משאבים חיצוניים (Third-Party Scripts) – בסביבות רבות נטענות ספריות או Widget-ים חיצוניים (כגון Google Maps, סרטוני YouTube מוטמעים, מודעות פרסום). אלמנטים אלה לעיתים מאיטים את הטעינה. מומלץ לטעון אותם באופן Lazy (למשל באמצעות iframe חכם) או להימנע מהם כאשר אינם נדרשים.
• ניקוי מסד נתונים (Database Cleanup) – גם WP Rocket וגם תוספי תחזוקה דוגמת WP-Optimize מאפשרים לנו למחוק טיוטות ישנות, הערות ספאם, רשומות זמניות (Transients) ונתוני טבלה לא נחוצים. ניקוי זה מפחית את משקל מסד הנתונים ומאיץ את ביצוע השאילתות.

הגדרות שדורשות תהליכי בדיקה והחרגות

יש שני פיצ'רים שיש להם השפעה דרמטית על מהירות האתר, שניהם משפיעים על התוכן שנטען בצד הלקוח (בדפדפן של המשתמש):

• הסרת CSS שאינו בשימוש (Unused CSS).
• עיכוב/דחיית טעינת סקריפטים (Defer / Delay JS).

העניין עם שני הפיצ'רים האלו הוא שכמעט תמיד אחרי שתגדירו אותם משהו ישבר בעיצוב האתר או התפקוד שלו. מומלץ להפעיל אותם בסביבת פיתוח ולבדוק בסבלנות התנהגות במצב גלישה בסתר (Incognito). הסרת CSS עובדת לאט, ולפעים תצטרכו לחכות שעה לפני שתבדקו את ההשפעה.

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

איפה אפשר ללמוד על זה עוד?

אם אתם רוצים להבין טוב יותר כל הגדרה והגדרה בתוסף המטמון, אני ממליץ לכם לעבור על המאמרים הבאים: הגדרות WP Rocket והגדרות LiteSpeed Cache.

Rocket add-ones

דרך הממשק של WP Rocket ניתן להתקין גם את הAdd-ons שלו: פיצ'רים שרק חלק מהמשתמשים צריכים:

• User Cache – חובה להתקין באתר שבו לכל משתמש יש תצוגה נפרדת, ולכן אין היגיון בלהגיש לכל המשתמשים את אותה גרסת קאש (למשל: חנות עם התחברות משתמשים, אתר קורסים בו לכל תלמיד יש מעקב אישי אחר הקורסים שלו וההתקדמות שלו)
• Varnish – חובה להפעיל אם אתם משתמשים בVarnish (אין לכם מושג מה זה? אני מסביר ממש עוד רגע).
• WebP Compatibility – אם אתם מעלים לאתר תמונות בפורמט JPG, ולא התקנתם תוסף יעודי שימיר אותן לפורמט מתקדם, הפעילו את האפשרות הזאת כדי שWP Rocket יעשה את זה עבורכם.
• Cloudflare – אם אתם משתמשים בקלאודפלייר עליכם להפעיל את האפשרות הזאת כדי שבכל פעם שאתם מרוקנים את מטמון האתר גם המטמון של קלאודפלייר יתחדש.
• Sucuri – נועד לתמיכה בתוסף האבטחה Sucuri, אם זה מותקן לכם על האתר.

זמן אחסון מטמון ארוך: Cache Lifespan

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

הגדרת Cache Lifespan ארוך (למשל 240 שעות ואף יותר) היא הבחירה הנכונה ברוב המקרים. אם האתר שלכם לא משתנה לעיתים קרובות זה יכול להיות רעיון טוב להגדיר Cache Lifespan ל-0 (לעולם לא מתרוקן סתם). במקרה הצורך תמיד ניתן לרוקן את המטמון ידנית, נכון?

Varnish – מטמון מתקדם ברמת השרת

Varnish הוא פרוקסי הפוך (Reverse Proxy) הפועל כמנגנון מטמון ברמת ה־HTTP, ונועד להאיץ את טעינת הדפים על ידי שמירת התוכן שנשלח מהשרת לזיכרון. Varnish מאחסן את כל הדף שנוצר (HTML שלם), ומספק אותו ישירות למבקרים מבלי להעביר את הבקשה לוורדפרס או למסד הנתונים. Varnish הוא עסק מסובך שלא מתאים לכל אתר. הוא מועיל במיוחד באתרים עתירי תנועה, שבהם נדרש להחזיר את אותו תוכן בדיוק למשתמשים רבים מבלי להעמיס על השרת:

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

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

• שילוב עם וורדפרס – חובה להפעיל בWP Rocket את הadd-on הייעודי לVernish, שינקה קאש Varnish אוטומטי בעת עדכון תוכן, כך שהתוכן החדש יהיה זמין למשתמשים באופן מיידי.
• החריגו תוכן דינמי – יש להגדיר חריגות (Bypass Rules) עבור עמודים דינאמיים כמו עגלה, דף תשלום או דפי חשבון משתמשים, כדי למנוע הצגת נתונים ישנים ואחידים למשתמשים שונים.

שיקלו להימנע מתוסף Firewall (WAF) – זה יכול לשפר את מהירות האתר

תוספי אבטחה כמו Wordfence כוללים חומת אש (WAF) שסורקת ומסננת תעבורה, אך בד בבד מייצרת עומס נוסף על שרת האחסון. כאשר האתר מוגן מאחורי Firewall כמו זה שיש ב-Cloudflare או זה שמגיע בלי שתצטרכו לעשות כלום בשרתים רבים, תוסף מקומי עלול להפוך למנגנון כפול ומיותר.

Wordfence הוא אחד התוספים החזקים לאבטחת וורדפרס, אך הוא כולל WAF (Web Application Firewall) שזולל משאבים של השרת. הוא מבצע סריקות ומעקב אחר תעבורה. זה יכול להאט את האתר וליצור עומסים משמעותיים על השרת.

אני לא נגד Wordfence – להפך, אני משתמש בו הרבה בעצמי. זו בחירה אישית: אם האתר שלכם תחת מתקפות, ייתכן שתעדיפו את ההגנה שלו, גם במחיר האטה. אם אתם מעוניינים בהקשחת אבטחה בסיסית ללא WAF, אפשר להשתמש בתוסף כמו All in One Security או אחרים, שאינם מחייבים הפעלת חומת אש ברמת היישום.

בכל אופן ודאו שיש לכם באתר פתרונות אבטחה, ואל תשאריו אותו בלתי מוגן "רק בשביל המהירות". הדבר היחיד שצריך הוא להימנע מכפילות מיותרת של WAF, שלא באמת תורמת לאבטחה אבל כן מזיקה למהירות האתר (פוגעת בTime To First Byte).

ניתוח פרופיילינג (Profiling) לאיתור צווארי בקבוק

אם הבעייה המרכזית בה אתם נתקלים היא TTFB (Time to first byte) והאתר עדיין נטען לאט חרף כל האופטימיזציות, ניתן להיעזר בתוסף Query Monitor כדי לאתר את המקור לאיטיות. התוסף מראה אילו תוספים או פונקציות צורכים את מרבית המשאבים, ומאפשרים לאתר בדיוק רב את מוקד הבעיה. התוסף הזה לא רלוונטי אם האתר מגיב מהר (TTFB נמוך), והבעייה שלכם היא טעינה של יותר מידי נכסים (תמונות, וידאו, סקריפטים וגליונות סגנון) לאתר. אם זיהיתם שהתוספים הכי כבדים הם התוספים שסביר שיהיו הכי כבדים (כמו אלמנטור, ווקומרס, פולילנג…) – זה הגיוני. אם יש תוסף "קטן" שמצליח להתברג לראש הרשימה של התוספים שהכי מאטים את האתר – עשו הכל כדי להחליף אותו בפיתרון חסכוני יותר.

התמודדות עם בעיות בתהליך שיפור מהירות האתר

שיפור מהירות האתר הוא תהליך מורכב, ולעיתים קרובות יגרום לשיבושים בלתי צפויים. החדשות הטובות הן שכל שינוי שתבצעו הפיך, אך זה לא הופך את החוויה לפחות מתסכלת. לעיתים תגלו שהאתר עובד נהדר מיד לאחר השינוי, רק כדי לגלות כמה שעות מאוחר יותר שמשהו השתבש – וזה בדיוק מה שהופך איתור בעיות לאתגר. הסיבה לכך היא שלתהליכים רבים יש זמן עיבוד והחלה, במיוחד כשמדובר במנגנוני קאשינג ואופטימיזציה אגרסיבית, או פיצ'רים שהדרך ליישם אותם באתר גדול היא במנות קטנות (למשל Remove unused CSS).

איך לזהות את מקור הבעיה?

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

• תוכן חדש לא מתעדכן באתר
  אם פרסמתם פוסט, מוצר או שינוי כלשהו והוא לא מופיע – זה סימן קלאסי לכך שאחת משכבות הקאש בצד השרת "לכדה" גרסה ישנה של העמוד. האשמים העיקריים הם Object Cache (Redis, Memcached), מטמון ב־Cloudflare, או מנגנוני קאש ברמת השרת.
• באותו דף יש אלמנטים שהתעדכנו, אך נראה שוידג'טים דינאמים מסויימים לא התעדכנו
  יש לגשת לוידג'ט באלמנטור ולהגדיר לו ב"מתקדם" שלא ישמור מטמון אלמנט.
• אלמנט ספציפי מופיע ללא העיצוב שהוגדר לו
  נפוץ במיוחד עבור אלמנטים שמופיע באיחור או רק אחרי אינטראקציה עם המשתמש (למשל – הודעת הצלחה אחרי שליחת טופס, הצגת מוצרים שנוספו בתוך עגלה צפה). אם רכיב עיצובי ספציפי אינו נטען כראוי, כנראה שמדובר בהגדרה של Remove Unused CSS. מנגנון זה מסיר קבצי CSS שמזוהים כמיותרים בזמן טעינת העמוד, אך לעיתים הוא מוחק גם סגנונות שכן נדרשים אך נטענים רק מאוחר יותר.
• פונקציונליות באתר לא עובדת – תפריט שלא נפתח, קרוסלה מקולקלת, פופאפ שלא מופיע
  אם אינטראקציות כמו פתיחת תפריט, תצוגת גלריה, או טעינת ווידג'טים מסוימים מפסיקות לפעול, רוב הסיכויים שהבעיה נובעת מעיכוב בטעינת קובצי JavaScript. הגדרות כמו Defer JavaScript או Delay JavaScript Execution גורמות לדפדפן לדחות את הרצת הסקריפטים עד לאחר שהתוכן הראשי נטען, אך אם הסקריפטים הללו הכרחיים לפעילות האתר, הם עלולים להישאר מושבתים.

מה עושים כשמתגלות בעיות בגלל קאשינג?

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

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

סבלנות ולמידה – חלק מתהליך האצת האתר

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

סיכום: אפשר לשפר את מהירות הטעינה של אתרי וורדפרס

אי אפשר לזלזל בחשיבות של פיתוח אתר מהיר – שניות בודדות יכולות להוות את ההבדל בין משתמש שנוטש את האתר לבין משתמש שנשאר, גולש וקונה. מאמר זה נועד להציג רקע מקיף על סוגיות הנוגעות למהירות טעינה בוורדפרס, החל מהצגת מקורות המדדים המודרניים (Core Web Vitals של Google), דרך בחירת תשתית השרת והגדרותיה, ועד לגישות שונות לאופטימיזציה של תמונות, קוד ותוספים. אופטימיזציית ביצועים בוורדפרס אינה מסתכמת בפעולה יחידה, אלא ברצף של בחירות טכניות וסדר פעולות:

1. פשטות ויזואלית ואזור ראשון של כל דף נקי וקל.
2. מינימום (ועדיף ללא) אלמנטים שדורשים עיבוד מיוחד (קרוסלות, לוטי, GSAP, וידאו רקע, פיד אינסטגרם…).
3. חיסכון בתוספים, במיוחד כאלו שנועדו להוסיף עוד וידג'טים לאלמנטור.
4. טיפול בתמונות – דחיסה, הגשה בפורמט מתקדם, הגשה ברזולוציה מתאימה לגודל של התמונה על המסך.
5. בחירת שרת מהיר שמותאם לדרישות האתר ("כובד" האתר + כמות משתמשים).
6. הגשת האתר דרך קלאודפלייר.
7. הגדרות Object Cache ו-OPcache.
8. הגדרת ביצועים וניסויים באלמנטור.
9. הגדרות תוסף מטמון (WP Rocket).
10. Varnish לדפים סטטיים.
11. הימנעות מ-Firewall במקרה שהאתר מוגן מאחורי Firewall ברמת שרת.

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

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

בהצלחה!