קאש בוורדפרס: מדריך ל-Page Cache, CDN ו-Object Cache

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

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

במדריך הזה נעבור על Page Cache, Object Cache, Redis, OPcache, CDN ו-Edge Cache. נראה מה כל שכבה עושה, מי שולט בה ומתי היא רלוונטית. נקודת ייחוס טובה נוספת היא מדריך הקאש הרשמי של WordPress (נפתח בלשונית חדשה).

למה וורדפרס בכלל צריך קאש

בלי Page Cache, השרת בונה את הדף בכל בקשה: WordPress מריץ קוד PHP, פונה למסד הנתונים כדי להביא תוכן והגדרות, מרכיב דף HTML ורק אז שולח אותו לדפדפן. זו עבודה שחוזרת על עצמה בכל בקשה שאינה נשמרת בקאש.

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

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

הרעיון המרכזי: קאש זה שכבות, לא תוסף

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

ככה נראית הדרך, מבחוץ פנימה:

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

שכבה אחר שכבה: מה כל אחת עושה ומי שולט בה

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

1. קאש דפים (Page Cache), זה מה שרוב האנשים מתכוונים אליו

מה זה עושה: שומר את דף ה-HTML המוגמר אחרי שווורדפרס בנה אותו. המבקר הבא שמבקש את אותו דף מקבל את הקובץ השמור ישירות, בלי PHP, בלי מסד נתונים.

דימוי: במקום לכתוב מחדש את אותו מכתב לכל אדם, אתם מצלמים אותו פעם אחת ומחלקים עותקים.

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

מי שולט: אתם, או השרת שלכם. אפשר להפעיל קאש דפים דרך תוסף (כמו WP Super Cache, W3 Total Cache ואחרים), או שהשרת עצמו עושה את זה ברמת השרת. כאן נכנס הבדל חשוב: שרתי LiteSpeed מציעים קאש דפים מובנה ומהיר במיוחד דרך התוסף LiteSpeed Cache, אבל הוא נותן את מלוא הכוח שלו רק על שרת LiteSpeed. על Apache או nginx רגילים תצטרכו פתרון אחר. כלומר, איזה תוסף קאש דפים מתאים לכם תלוי קודם כול בשרת שעליו האתר יושב, ולא בהעדפה שלכם. לזה נחזור בהמשך.

כלל עבודה: אל תפעילו שני תוספים שמבצעים Page Cache במקביל בלי להבין מי מהם אחראי לשמירה ולניקוי. כפילות עלולה ליצור cache לא עקבי ולהקשות על איתור תקלות.

2. Object Cache (Redis / Memcached), לדפים שלא יכולים להישמר כמו שהם

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

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

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

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

Redis או Memcached שרצים בשרת אינם מחברים את WordPress אליהם אוטומטית. נדרש תוסף או drop-in שמניח קובץ object-cache.php ומחבר בין WordPress לשירות. בלי חיבור כזה, WordPress משתמש ב-object cache הלא מתמשך שלו, שחי רק לאורך הבקשה. אפשר לקרוא על ההתנהגות הזו בתיעוד הרשמי של WP_Object_Cache (נפתח בלשונית חדשה).

3. OPcache, בדרך כלל כבר מוגדר בשרת

מה זה עושה: שומר את קוד ה-PHP שלכם בגרסה “מהודרת” (מקומפלת) בזיכרון, כדי ש-PHP לא יצטרך לפרש את אותם קבצים מאפס בכל בקשה.

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

מה זה מזרז: את זמן הריצה של PHP עצמו. השיפור אמיתי, אבל הוא קורה “מתחת למכסה המנוע”.

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

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, דרך DNS, הגדרת שירות או תוסף. חלק מהשירותים כוללים תוכנית חינמית ואחרים מתומחרים לפי שימוש.

6. קאש בקצה (Edge Cache), קאש דפים, אבל רחוק מהשרת

מה זה עושה: מאפשר ל-Cloudflare (או שירות דומה) להחזיק את דף ה-HTML המלא ברשת הקצה שלו, כך שאפילו ה-HTML מוגש מהקצה, והבקשה לא מגיעה בכלל לשרת שלכם.

דימוי: זה קאש דפים, אבל במקום שיֵשב על השרת שלכם, הוא יושב הרבה יותר קרוב למבקר.

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

כמה שאלות שטבעי לשאול כאן:

• זה כמו CDN, אבל לכל הדף? בדיוק. ההבדל מ-CDN רגיל: CDN שומר בקצה רק את הקבצים הסטטיים, בעוד קאש בקצה שומר בקצה את כל דף ה-HTML. אז כן, אותו רעיון של “קרוב למבקר”, רק שהפעם זה הדף השלם ולא רק התמונות.
• זה בתשלום? אפשר להגדיר שמירת HTML בקצה באמצעות Cache Rules של Cloudflare (נפתח בלשונית חדשה), שזמינים גם בתוכנית Free. אתם אחראים להחרגות, ל-TTL ולניקוי. APO הוא פתרון מנוהל יותר ל-WordPress, דורש רכישה בתוכנית Free וכלול בתוכנית Pro ומעלה. בדקו את התנאים העדכניים בתיעוד APO (נפתח בלשונית חדשה) במקום להסתמך על מחיר קשיח במאמר.
• למי זה הכי משתלם? בעיקר לאתרים שפונים לקהל מפוזר גאוגרפית או רחוק מהשרת. אתר ישראלי שמאוחסן בישראל ופונה לקהל ישראלי ייהנה פחות מקיצור המרחק, המבקרים ממילא קרובים לשרת. יש גם יתרון בעומס: כשבקשה כשירה פוגעת בעותק שמור בקצה, היא אינה צריכה להגיע לשרת המקור. בקשות שלא נשמרו, הוחרגו, נוקו או דורשות אימות מחדש עדיין יכולות להגיע אליו.

מי שולט: אתם, דרך Cloudflare. אבל בזהירות, ובתיאום עם שאר השכבות (ראו את האזהרה בהמשך על שכבות שנלחמות).

CDN מול קאש, נקודה שחשוב לשים לב אליה

זו אולי נקודת הבלבול הנפוצה ביותר, אז ניישר אותה בבירור: CDN ו”תוסף קאש” הם לא אותו דבר, והם לא מחליפים זה את זה.

• CDN פותר בעיה של מרחק: איפה הקבצים יושבים פיזית ביחס למבקר.
• קאש דפים פותר בעיה של עבודה כפולה: כמה פעמים השרת בונה את אותו דף.

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

מה בשליטתכם ומה תלוי באחסון

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

השורה התחתונה של הטבלה: האחסון קובע אילו מנגנונים זמינים ברמת השרת, אך LiteSpeed ו-Redis אינם הדרכים היחידות לאתר מהיר. קיימים גם Nginx FastCGI Cache, Varnish ופתרונות מנוהלים אחרים. בדקו מה הספק מפעיל בפועל לפני שאתם מוסיפים שכבה נוספת.

מזעור ואיחוד קבצים (minify), קרוב לקאש, אבל לא קאש

תוך כדי שמתעסקים בתוספי קאש, נתקלים כמעט תמיד באפשרויות נוספות: מזעור (minify) ואיחוד (combine) של קבצי CSS ו-JavaScript. חשוב להבין שזה לא קאש, זו אופטימיזציה אחרת שפשוט “גרה” באותו תוסף, ולכן קל להתבלבל ולסמן אותה כאילו היא חלק מאותו דבר.

• מזעור (minify) מוחק רווחים, הערות ושורות מיותרות מקבצי הקוד כדי להקטין אותם. התוצאה: הקבצים מעט קטנים יותר ויורדים מעט מהר יותר.
• איחוד (combine) מאחד כמה קבצים נפרדים לקובץ אחד גדול, כדי להפחית את מספר הבקשות לשרת. בעידן HTTP/2 ו-HTTP/3 התועלת בזה קטנה בהרבה מפעם, ולעיתים אין בה צורך כלל.

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

מה חשוב באמת ומה רעש

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

• קאש דפים נותן את רוב השיפור. לאתרי תוכן, השכבה הזאת לבדה אחראית לרוב התחושה של “פתאום האתר מעופף”. התחילו ממנה.
• Object Cache אינו חובה לכולם. הוא עשוי לעזור לאתרים דינמיים או גדולים לאחר מדידה, ולעיתים כמעט אינו מורגש בבלוג קטן. אל תרדפו אחרי Redis אם אין צוואר בקבוק שהוא יכול לפתור.
• לא להפעיל שני תוספי קאש. חזרה על הכלל, כי זו הטעות הכי נפוצה: שני תוספי קאש דפים = מלחמה, באגים, ודפים תקועים.
• מזעור ואיחוד הם סיכון, לא קסם (הרחבנו על זה למעלה), הרווח קטן, והם עלולים לשבור דברים. הפעילו בהדרגה ובדקו אחרי כל שינוי.
• מה שקובע זו ההגדרה הנכונה, לא שם התוסף. אם כלי האחסון מציג hit ratio, השתמשו בו כדי לבדוק כמה בקשות באמת מוגשות מהקאש. שם התוסף לבדו אינו מדד לביצועים.
• העלות תלויה בתשתית. יש כלים חינמיים, אבל שרת חזק יותר, Redis מנוהל, CDN או שירות Edge עשויים לעלות כסף. השוו את העלות לשיפור שנמדד בפועל.

מדריך החלטה קצר לפי סוג אחסון

בלי להמליץ על תוסף יחיד “הכי טוב”, כי כזה לא קיים, הנה איך לחשוב על זה לפי מה שיש לכם:

• אתם על אחסון מבוסס LiteSpeed: בדקו בלוח האחסון או מול הספק אם מנוע LSCache פעיל, ואז השתמשו ב-LiteSpeed Cache כממשק הניהול שלו. כותרת Server לבדה אינה בדיקה אמינה מאחורי proxy או CDN.
• אתם על Apache או Nginx: בחרו מנגנון Page Cache אחד שמתאים לסביבה. הוסיפו CDN רק אם מיקום הקהל, העומס או צרכי האבטחה מצדיקים אותו. שמירת HTML בקצה היא הגדרה נפרדת.
• יש לכם אתר דינמי או חנות WooCommerce: ודאו קודם שקאש הדפים מחריג עגלות, checkout ומשתמשים מחוברים. אם האחסון מציע Redis ויש עומס מתאים, Object Cache עשוי לעזור.
• בכל מקרה: מדדו לפני ואחרי כל שינוי, נקו cache ובדקו בגלישה פרטית גם דפים ציבוריים וגם תהליכים דינמיים.

שורה תחתונה

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

1. אתם לא צריכים את כל השכבות. התחילו בזו שפותרת צוואר בקבוק שנמדד, ובאתרי תוכן זו בדרך כלל Page Cache.
2. האחסון קובע אילו כלים זמינים. בדקו את מנגנוני השרת לפני התקנת תוסף נוסף.
3. מחיר אינו תחליף למדידה. גם שירות בתשלום וגם תוסף חינמי יכולים להיות מיותרים אם אינם פותרים את הבעיה הנכונה.

באתר תוכן, התחילו ב-Page Cache אחד שמתאים לאחסון ומדדו לפני ואחרי. הוסיפו CDN אם המרחק או העומס מצדיקים אותו, ו-Object Cache רק כשהאתר והשרת זקוקים לו. אם אתם עדיין מקימים את האתר, חזרו למדריך לבניית אתר WordPress.