וורדפרס
קאש בוורדפרס: מה זה באמת, ולמה זה אף פעם לא רק תוסף אחד
אם אי פעם ניסיתם להאיץ אתר וורדפרס, כנראה נתקלתם בעצה הקבועה: “תתקינו תוסף קאש”. התקנתם, סימנתם V על כמה תיבות, ובמקרה הטוב האתר באמת נהיה מהיר יותר (ובמקרה הפחות טוב האתר נשבר). אבל מה בעצם קרה שם? ולמה לפעמים זה לא עוזר בכלל, או גרוע מזה, שובר את האתר?
קאש בוורדפרס הוא שכבה של כמה מנגנונים, לא תוסף בודד. כל מנגנון פותר בעיה אחרת, יושב במקום אחר, ונמצא בשליטה של גורם אחר, לפעמים שלכם, ולפעמים של חברת האחסון.
במדריך הזה אני אפרק את כל המושגים, page cache, object cache, Redis, OPcache, CDN, edge cache, להסבר פשוט: מה כל אחד עושה, מה ההבדל ביניהם, מה באמת חשוב ומה סתם רעש, ובעיקר, מה בשליטה שלכם ומה תלוי באחסון שלכם. בלי להמליץ לכם על תוסף ספציפי, ובלי באזז.
למה וורדפרס בכלל צריך קאש
כשמבקר נכנס לדף בוורדפרס, השרת לא מחזיק את הדף “מוכן”. הוא בונה אותו מחדש בכל פעם: וורדפרס מריץ קוד PHP, פונה למסד הנתונים (MySQL/MariaDB) בעשרות שאילתות, להביא את הפוסט, את התגובות, את התפריט, את הווידג’טים, מרכיב מכל זה דף HTML, ורק אז שולח אותו לדפדפן. כל זה קורה תוך מילישניות, אבל זו עבודה אמיתית, והיא חוזרת על עצמה אצל כל מבקר ומבקר.
עכשיו שימו לב לאבסורד: אם אלף אנשים קוראים את אותו פוסט, השרת בנה את אותו דף בדיוק אלף פעמים, עם אותה תוצאה. זה בזבוז עצום של זמן ושל משאבי שרת.
קאש פותר בדיוק את זה: לעשות את העבודה פעם אחת, שומור את התוצאה, ומגיש אותה שוב ושוב בלי לבנות הכל מחדש. זה כל הרעיון. כל סוגי הקאש שנדבר עליהם הם וריאציות על המשפט הזה, כל אחד מהם פשוט שומר תוצאה בשלב אחר של התהליך.
הרעיון המרכזי: קאש זה שכבות, לא תוסף
בקשה של מבקר עוברת דרך כמה תחנות בדרך אל האתר שלכם, ובכל תחנה אפשר “לתפוס” אותה ולהגיש תשובה מוכנה, בלי להמשיך פנימה. ככל שתופסים אותה מוקדם יותר, כך מהר יותר, ופחות עומס על השרת.
ככה נראית הדרך, מבחוץ פנימה:
לא כל אתר חייב את כל השכבות האלה. אבל כל בעל אתר צריך להבין איזו שכבה הוא מפספס, כי שם נמצא השיפור הבא. בואו נעבור עליהן אחת-אחת.
שכבה אחר שכבה: מה כל אחת עושה ומי שולט בה
לכל שכבה אענה על אותן ארבע שאלות: מה היא עושה, דימוי פשוט, מה היא באמת מזרזת, ומי שולט בה, אתם, חברת האחסון, או Cloudflare.
1. קאש דפים (Page Cache), זה מה שרוב האנשים מתכוונים אליו
מה זה עושה: שומר את דף ה-HTML המוגמר אחרי שווורדפרס בנה אותו. המבקר הבא שמבקש את אותו דף מקבל את הקובץ השמור ישירות, בלי PHP, בלי מסד נתונים.
דימוי: במקום לכתוב מחדש את אותו מכתב לכל אדם, אתם מצלמים אותו פעם אחת ומחלקים עותקים.
מה זה מזרז: הכי הרבה. לאתרי תוכן (בלוגים, אתרי תדמית) זו השכבה שנותנת את עיקר השיפור, לרוב מ”שנייה וחצי” ל”כמעט מיידי”.
מי שולט: אתם, או השרת שלכם. אפשר להפעיל קאש דפים דרך תוסף (כמו WP Super Cache, W3 Total Cache ואחרים), או שהשרת עצמו עושה את זה ברמת השרת. כאן נכנס הבדל חשוב: שרתי LiteSpeed מציעים קאש דפים מובנה ומהיר במיוחד דרך התוסף LiteSpeed Cache, אבל הוא נותן את מלוא הכוח שלו רק על שרת LiteSpeed. על Apache או nginx רגילים תצטרכו פתרון אחר. כלומר, איזה תוסף קאש דפים מתאים לכם תלוי קודם כול בשרת שעליו האתר יושב, ולא בהעדפה שלכם. לזה נחזור בהמשך.
כלל ברזל: קאש דפים אחד בלבד. לעולם אל תפעילו שני תוספי קאש דפים במקביל, הם נלחמים זה בזה, יוצרים עותקים סותרים ושוברים דברים.
2. Object Cache (Redis / Memcached), לדפים שלא יכולים להישמר כמו שהם
מה זה עושה: שומר תוצאות של שאילתות בודדות למסד הנתונים ושל אובייקטים פנימיים של וורדפרס, בזיכרון מהיר. כך אם אותה שאלה נשאלת שוב (“מי המחבר של פוסט 42?”), התשובה כבר מוכנה ולא צריך לרוץ שוב למסד.
דימוי: פתק שעליו רשומות התשובות לשאלות שחוזרות על עצמן, מציצים בפתק במקום לחפש בארכיון בכל פעם.
מה זה מזרז: בעיקר דפים דינמיים שאי אפשר לשמור כקאש דפים שלם, אזורי משתמש מחוברים, עגלת קניות בחנות WooCommerce, לוח הבקרה של וורדפרס, אתרים גדולים עם המון שאילתות. לבלוג קטן וסטטי ברובו, לרוב לא תרגישו הבדל גדול.
מי שולט: תלוי באחסון. object cache דורש ש-Redis או Memcached יהיו מותקנים על השרת, וזה לא בשליטתכם אם אתם על אחסון משותף. אם הם קיימים, מחברים אליהם את וורדפרס דרך תוסף קטן (למשל Redis Object Cache). אם הם לא קיימים, אין מה להתקין, וצריך לדבר עם חברת האחסון.
“רגע, אם Redis כבר מותקן בשרת, הוא לא מאיץ את האתר שלי מעצמו?” זו נקודה שמבלבלת המון אנשים, אז נחדד אותה: לא. עצם זה ש-Redis (או Memcached) מותקן ורץ על השרת לא עושה כלום לוורדפרס שלכם בפני עצמו. וורדפרס לא “מתחבר” לזיכרון הזה אוטומטית, צריך להתקין תוסף (כמו Redis Object Cache) שמניח קובץ מיוחד בשם
object-cache.phpבתוך האתר ומחבר ביניהם. בלי החיבור הזה, וורדפרס משתמש ב-object cache הפנימי והזמני שלו, שמתאפס בסוף כל בקשה, כלומר לא חוסך כלום בין מבקר למבקר. השורה התחתונה: Redis בשרת הוא תנאי הכרחי, אבל לא מספיק. בלי תוסף שמחבר אליו את האתר, אין שיפור. (שימו לב להבדל מ-OPcache בהמשך, שהוא כן עובד אוטומטית.)
3. OPcache, קיים, עובד, ואין לכם מה לעשות איתו
מה זה עושה: שומר את קוד ה-PHP שלכם בגרסה “מהודרת” (מקומפלת) בזיכרון, כדי ש-PHP לא יצטרך לפרש את אותם קבצים מאפס בכל בקשה.
דימוי: במקום לתרגם מחדש את אותו ספר בכל פעם שמישהו רוצה לקרוא אותו, שומרים את התרגום המוכן.
מה זה מזרז: את זמן הריצה של PHP עצמו. השיפור אמיתי, אבל הוא קורה “מתחת למכסה המנוע”.
מי שולט: השרת, באופן אוטומטי. אין מה להתקין ואין תוסף. OPcache הוא חלק מ-PHP, וברוב האחסונים המודרניים הוא כבר פעיל כברירת מחדל, וכאן בדיוק ההבדל מ-object cache: OPcache עובד מעצמו, ואילו object cache חייב חיבור יזום. הזכרתי אותו רק כדי שהתמונה תהיה שלמה, לא כדי שתעשו איתו משהו.
4. קאש דפדפן (Browser Cache), הקאש שיושב אצל המבקר
מה זה עושה: מורה לדפדפן של המבקר לשמור אצלו מקומית קבצים סטטיים, תמונות, CSS, JavaScript, כך שבביקור הבא הוא לא מוריד אותם שוב מהשרת.
דימוי: במקום להביא את אותם כלים מהמחסן בכל פעם, אתם משאירים אותם על שולחן העבודה.
מה זה מזרז: את הביקורים החוזרים ואת המעבר בין דפים באותו אתר. זו השורה “leverage browser caching” / “serve static assets with an efficient cache policy” שאתם רואים בבדיקות מהירות כמו PageSpeed.
מי שולט: אתם, בעקיפין. זה נקבע על ידי כותרות (HTTP headers) שהשרת שולח, ולרוב תוסף הקאש או הגדרת השרת מטפלים בזה אוטומטית. אפשר גם לנהל את זה דרך Cloudflare, שמאפשר לקבוע מלוח הבקרה שלו כמה זמן הדפדפן ישמור קבצים סטטיים, בלי לגעת בשרת בכלל. בכל מקרה, נדיר שתיגעו בזה ידנית.
5. CDN, פיזור גאוגרפי, לא “תוסף קאש”
מה זה עושה: מחזיק עותקים של הקבצים הסטטיים שלכם (תמונות, CSS, JS) על שרתים בכל העולם. מבקר מקבל אותם מהשרת הקרוב אליו פיזית, מבקר בברלין לא צריך למשוך תמונה מישראל.
דימוי: רשת של מחסנים בכל מדינה, במקום מחסן מרכזי אחד שכולם נוסעים אליו.
מה זה מזרז: את זמן ההורדה של הקבצים, בעיקר לקהל בינלאומי, ומוריד עומס מהשרת שלכם.
מי שולט: אתם. מפעילים CDN (כמו Cloudflare, BunnyCDN ואחרים) דרך הגדרה או תוסף. רובם מציעים שכבת חינם נדיבה.
6. קאש בקצה (Edge Cache), קאש דפים, אבל רחוק מהשרת
מה זה עושה: מאפשר ל-Cloudflare (או שירות דומה) להחזיק את דף ה-HTML המלא ברשת הקצה שלו, כך שאפילו ה-HTML מוגש מהקצה, והבקשה לא מגיעה בכלל לשרת שלכם.
דימוי: זה קאש דפים, אבל במקום שיֵשב על השרת שלכם, הוא יושב הרבה יותר קרוב למבקר.
מה זה מזרז: הכול, כי הבקשה נעצרת בתחנה הראשונה. זו השכבה החזקה ביותר, אבל גם הפחות מובנת, ולפעמים המסוכנת ביותר: צריך לוודא שהקאש מתנקה כשמעדכנים תוכן, ושאתם לא מגישים בטעות דף אישי (משתמש מחובר, עגלה) לכל העולם.
כמה שאלות שטבעי לשאול כאן:
- זה כמו CDN, אבל לכל הדף? בדיוק. ההבדל מ-CDN רגיל: CDN שומר בקצה רק את הקבצים הסטטיים, בעוד קאש בקצה שומר בקצה את כל דף ה-HTML. אז כן, אותו רעיון של “קרוב למבקר”, רק שהפעם זה הדף השלם ולא רק התמונות.
- זה בתשלום? תלוי איך. קאש בקצה בסיסי אפשר להפעיל גם בתוכנית החינם של Cloudflare (דרך כלל “Cache Everything” ב-Cache/Page Rules), אבל זה פתרון “עשה זאת בעצמך”: אתם אחראים לדאוג שהקאש מתנקה בעדכון תוכן ושדפים אישיים לא נשמרים בטעות, וזה עדין לתוכן דינמי. הפתרון המנוהל לוורדפרס, APO (Automatic Platform Optimization), עושה את כל זה אוטומטית וחכם, אבל הוא בתשלום: כ-5 דולר לחודש בתוכנית החינם, וכלול ללא תוספת בתוכניות בתשלום של Cloudflare.
- למי זה הכי משתלם? בעיקר לאתרים שפונים לקהל מפוזר גאוגרפית או רחוק מהשרת. אתר ישראלי שמאוחסן בישראל ופונה לקהל ישראלי ייהנה פחות מקיצור המרחק, המבקרים ממילא קרובים לשרת. אבל יש כאן יתרון שני שנשאר נכון בכל מצב: קאש בקצה מוריד מהשרת שלכם את הבקשות לגמרי, וזה עוזר מאוד בעומסי תנועה ובשיאים פתאומיים, בלי קשר למרחק.
מי שולט: אתם, דרך Cloudflare. אבל בזהירות, ובתיאום עם שאר השכבות (ראו את האזהרה בהמשך על שכבות שנלחמות).
CDN מול קאש, נקודה שחשוב לשים לב אליה
זו אולי נקודת הבלבול הנפוצה ביותר, אז ניישר אותה בבירור: CDN ו”תוסף קאש” הם לא אותו דבר, והם לא מחליפים זה את זה.
- CDN פותר בעיה של מרחק: איפה הקבצים יושבים פיזית ביחס למבקר.
- קאש דפים פותר בעיה של עבודה כפולה: כמה פעמים השרת בונה את אותו דף.
CDN בלי קאש דפים, השרת שלכם עדיין בונה כל דף מחדש בכל בקשה. קאש דפים בלי CDN, הדף מוגש מהר, אבל תמיד מאותו מיקום אחד בעולם. הם פותרים בעיות שונות, והם עובדים מצוין יחד. אל תתבלבלו ותחשבו ש”יש לי Cloudflare, אז אני מסודר עם קאש”, זה רק חצי מהסיפור (אלא אם הפעלתם אצלם גם קאש בקצה).
מה בשליטתכם ומה תלוי באחסון
זו אולי הטבלה הכי שימושית במדריך הזה. לפני שאתם מנסים “לתקן” משהו, כדאי לדעת אם זה בכלל בידיים שלכם:
| שכבה | מי שולט | מה אתם יכולים לעשות |
|---|---|---|
| קאש דפים (תוסף) | אתם | להתקין/להגדיר תוסף מתאים לשרת שלכם |
| קאש דפים (שרת, LiteSpeed) | האחסון קובע אם זמין; אתם מגדירים | אם אתם על LiteSpeed, להשתמש ב-LiteSpeed Cache |
| Object cache (Redis) | האחסון קובע אם זמין | אם זמין, לחבר דרך תוסף |
| OPcache | האחסון, אוטומטי | בדרך כלל כלום, כבר פעיל |
| קאש דפדפן | אתם, בעקיפין | התוסף/השרת/Cloudflare מטפל; נדיר שתיגעו ידנית |
| CDN | אתם | להפעיל ולהגדיר |
| קאש בקצה (edge) | אתם, דרך Cloudflare | להפעיל בזהירות ובתיאום |
השורה התחתונה של הטבלה: חלק גדול ממה שקובע כמה מהיר האתר שלכם נקבע בבחירת האחסון, עוד לפני שהתקנתם תוסף אחד. אם האחסון לא מציע LiteSpeed ולא מציע Redis, חסם מסוים כבר קבוע, וזו לפעמים הסיבה האמיתית שאתר “לא מצליח להיות מהיר” כמה תוספים שלא תתקינו.
מזעור ואיחוד קבצים (minify), קרוב לקאש, אבל לא קאש
תוך כדי שמתעסקים בתוספי קאש, נתקלים כמעט תמיד באפשרויות נוספות: מזעור (minify) ואיחוד (combine) של קבצי CSS ו-JavaScript. חשוב להבין שזה לא קאש, זו אופטימיזציה אחרת שפשוט “גרה” באותו תוסף, ולכן קל להתבלבל ולסמן אותה כאילו היא חלק מאותו דבר.
- מזעור (minify) מוחק רווחים, הערות ושורות מיותרות מקבצי הקוד כדי להקטין אותם. התוצאה: הקבצים מעט קטנים יותר ויורדים מעט מהר יותר.
- איחוד (combine) מאחד כמה קבצים נפרדים לקובץ אחד גדול, כדי להפחית את מספר הבקשות לשרת. בעידן HTTP/2 ו-HTTP/3 התועלת בזה קטנה בהרבה מפעם, ולעיתים אין בה צורך כלל.
הרווח כאן בדרך כלל קטן, והסיכון אמיתי: מזעור, ובעיקר איחוד, יכולים לשבור עיצוב או סקריפטים באתר. לכן הכלל פשוט: אל תסמנו את כל התיבות בבת אחת. הפעילו אפשרות אחת בכל פעם, ובדקו את האתר אחריה. אם משהו נשבר, תדעו בדיוק מה גרם לזה, ותוכלו לכבות רק אותה.
מה חשוב באמת ומה רעש
עכשיו, כשהתמונה ברורה, אפשר לחתוך דרך כל הרעש. הנה מה שבאמת קובע, ומה אפשר להתעלם ממנו:
- קאש דפים נותן את רוב השיפור. לאתרי תוכן, השכבה הזאת לבדה אחראית לרוב התחושה של “פתאום האתר מעופף”. התחילו ממנה.
- object cache הוא לא חובה לכולם. הוא קריטי לחנויות ולאתרים דינמיים/גדולים, ולעיתים כמעט בלתי מורגש בבלוג קטן. אל תרדפו אחרי Redis אם האתר שלכם ברובו סטטי.
- לא להפעיל שני תוספי קאש. חזרה על הכלל, כי זו הטעות הכי נפוצה: שני תוספי קאש דפים = מלחמה, באגים, ודפים תקועים.
- מזעור ואיחוד הם סיכון, לא קסם (הרחבנו על זה למעלה), הרווח קטן, והם עלולים לשבור דברים. הפעילו בהדרגה ובדקו אחרי כל שינוי.
- מה שקובע זו ההגדרה הנכונה, לא שם התוסף. המדד האמיתי הוא כמה מהבקשות מוגשות מהקאש במקום להיבנות מחדש, מה שנקרא “יחס פגיעה” (hit ratio). תוסף פחות מוכר שמוגדר היטב ומגיש 95% מהבקשות מהקאש עדיף בהרבה על תוסף מפורסם שמוגדר ברישול ומגיש רק מחצית. אל תחפשו את התוסף “הכי טוב”, הגדירו נכון את זה שכבר בחרתם.
- כמעט הכול חינמי. קאש דפים, object cache, CDN וקאש בקצה בסיסי, לכל אחד מהם יש פתרון חינמי ומצוין. ברוב האתרים, ביצועים טובים הם עניין של הבנה והגדרה נכונה, לא של תקציב.
מדריך החלטה קצר לפי סוג אחסון
בלי להמליץ על תוסף יחיד “הכי טוב”, כי כזה לא קיים, הנה איך לחשוב על זה לפי מה שיש לכם:
- אתם על אחסון מבוסס LiteSpeed (נפוץ מאוד באחסונים בישראל ובאחסונים מבוססי cPanel): השתמשו ב-LiteSpeed Cache. הוא מובנה, מהיר, וכולל גם חיבור ל-object cache וגם אפשרויות CDN, הכול בתוסף אחד. איך תדעו? כותרת השרת בבדיקה מהירה תראה
LiteSpeed. - אתם על Apache / nginx רגיל (לא LiteSpeed): בחרו תוסף קאש דפים טוב אחד שמתאים לסביבה הזאת, וצרפו Cloudflare מקדימה (גם בחינם) ל-CDN ולשכבת קצה.
- יש לכם אתר דינמי או חנות WooCommerce: קודם כול ודאו קאש דפים תקין, ואז, אם האחסון שלכם מציע Redis, הוסיפו object cache. זו השכבה שתעשה את ההבדל באזורים שלא ניתן לשמור כקאש מלא.
- בכל מקרה: Cloudflare בחינם מקדימה זה כמעט תמיד רעיון טוב, רק שימו לב לא ליצור התנגשות בין קאש בקצה לבין קאש הדפים שעל השרת (לתאם ניקוי, ולא לשמור דפים אישיים).
שורה תחתונה
קאש בוורדפרס עובד בשכבות, וכל שכבה פותרת בעיה אחרת במקום אחר. ברגע שמבינים את זה, שלוש מסקנות מתבהרות:
- אתם לא צריכים את כל השכבות, אתם צריכים את אלה שמתאימות לסוג האתר שלכם, ובראש ובראשונה קאש דפים.
- חלק גדול מהסיפור נקבע באחסון, עוד לפני שנגעתם בתוסף. אם משהו “מסרב להיות מהיר”, הסתכלו קודם על השרת, לא על רשימת התוספים.
- כמעט הכול חינמי, והעיקר הוא הבנה והגדרה נכונה, לא תקציב ולא תוסף יקר.
התחילו מקאש דפים אחד טוב, הוסיפו Cloudflare מקדימה, והגיעו ל-object cache רק אם וכשהאתר שלכם באמת זקוק לו. זה הסדר הנכון, וזה כמעט תמיד מספיק.
תגובות
טוען תגובות…