אם אי פעם התקנתם תוסף caching על WordPress, אתם מכירים את התהליך. בוחרים אחד, מגדירים תריסר הגדרות, מקווים שהוא לא יתנגש עם התוספים האחרים שלכם, ומצליבים אצבעות שהוא בכלל עובד. יש דרך מהירה ונקייה יותר להשיג את אותה תוצאה, וזה קורה כולו בשכבת השרת: FastCGI cache של Nginx.
FastCGI cache מאפשר ל-Nginx לשמור עמודי HTML מעובדים במלואם ולהגיש אותם ישירות, בלי לגעת ב-PHP וב-MySQL בכלל עבור מבקרים חוזרים. בלי תוסף. בלי הרצת PHP. רק Nginx שמוציא קובץ סטטי במהירות מקסימלית.
מה FastCGI Cache עושה בעצם
כשמישהו נכנס לעמוד WordPress, זה המסלול הרגיל: Nginx מקבל את הבקשה, מעביר אותה ל-PHP-FPM, PHP טוען את הליבה של WordPress, מריץ את התבנית והתוספים שלכם, שולח שאילתות למסד הנתונים, בונה את ה-HTML, ושולח אותו בחזרה. כל התהליך הזה יכול בקלות לקחת 200-800 מילישניות באתר טיפוסי, ואפילו יותר אם אתם מריצים page builder כבד או WooCommerce.
FastCGI cache משנה את זה. בפעם הראשונה שמבקשים עמוד, Nginx עדיין עובר את כל תהליך PHP, אבל שומר את פלט ה-HTML שהתקבל לדיסק. כל בקשה נוספת לאותו עמוד נשלחת ישירות מהקובץ השמור. בלי PHP-FPM. בלי שאילתה למסד הנתונים. רק Nginx שקורא קובץ ושולח אותו.
ההבדל בביצועים דרמטי. אנחנו רואים באופן קבוע ירידה בזמן התגובה הראשוני (TTFB) מ-300-600 מילישניות עד ל-5-20 מילישניות לאחר שה-FastCGI cache "מתחמם". זה לא שיפור שולי, זה שיפור בסדר גודל שלם.
הגדרות בסיסיות של Nginx
הנה גרסה מפושטת של איך ההגדרות נראות. בבלוק ה-http שלכם, אתם מגדירים את נתיב ה-cache:
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
אחר כך, בתוך בלוק השרת או מיקום ה-PHP, אתם מגדירים ל-Nginx מתי בעצם להשתמש ב-cache:
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
המשתנה $skip_cache הזה הוא החלק החשוב. אתם לא רוצים לשמור הכל בעיניים עצומות, אתם צריכים חוקים שמדלגים על ה-cache עבור משתמשים מחוברים, בקשות POST, עמודי ניהול, וכל דבר עם query string שמעיד על תוכן דינמי כמו עגלת קניות או עמוד תשלום.
למה חוקי הדילוג חשובים
כאן הרבה הגדרות עצמאיות של FastCGI cache נכשלות. אם תשמרו ב-cache עמוד של משתמש מחובר, המבקר הבא עלול לראות סרגל ניהול או תוכן מותאם אישית שלא שלו. אם תשמרו ב-cache עמוד עגלת קניות של WooCommerce, לקוחות עלולים לראות את תכולת העגלה של מישהו אחר. הגדרת תנאי הדילוג בצורה נכונה היא לא אופציונלית, זה ההבדל בין אתר מהיר לאתר תקול.
בלוק דילוג טיפוסי בודק דברים כמו קוקי ה-wordpress_logged_in, קוקי תגובות, ותבניות URI ספציפיות:
if ($http_cookie ~* "wordpress_logged_in") {
set $skip_cache 1;
}
if ($request_uri ~* "/wp-admin/|/cart/|/checkout/|/my-account/") {
set $skip_cache 1;
}
ניקוי Cache: החלק שכולם שוכחים
cache סטטי לעמודים שימושי רק אם הוא נשאר רלוונטי. אם אתם מפרסמים פוסט חדש או מעדכנים עמוד, הגרסה השמורה ב-cache צריכה להיעלם כדי שהמבקר הבא יקבל את התוכן המעודכן, ולא HTML ישן משעה קודם.
זה מטופל בדרך כלל עם מודול ניקוי (כמו ngx_cache_purge) שמקושר להוקים של שמירה ב-WordPress, או באמצעות סקריפט קטן שמנקה מפתחות cache ספציפיים כשהתוכן משתנה. בלי החלק הזה, עורכי תוכן יתפלאו כל הזמן למה השינויים שלהם "לא מופיעים", כשבפועל העמוד הישן פשוט מוגש בשמחה.
זו אחת הסיבות ששווה לשקול הגדרה מנוהלת אם אתם לא רוצים לבנות ולתחזק את התהליך הזה בעצמכם. בפלטפורמה שלנו, התנהגות ה-page cache והניקוי מטופלת אוטומטית על ידי מייעל ה-WordPress, כך שפרסום פוסט מנקה את רשומות ה-cache הנכונות מבלי שאף אחד יצטרך לגעת בקובץ הגדרות.
FastCGI Cache מול תוספי Caching
תוספים כמו WP Super Cache או W3 Total Cache עושים דבר דומה מבחינה קונספטואלית, מייצרים HTML סטטי ומגישים אותו במקום להריץ PHP. אבל הם עושים את זה מתוך WordPress, כלומר PHP עדיין צריך לעלות, לטעון את התוסף, לבדוק אם קיימת גרסה שמורה, ואז להגיש אותה. זה מהיר יותר מרינדור מלא, אבל עדיין יותר איטי מלא לגעת ב-PHP בכלל.
FastCGI cache פועל שכבה אחת יותר עמוק, בשרת האינטרנט עצמו. Nginx מחליט אם להגיש מה-cache עוד לפני ש-PHP-FPM בכלל מעורב. זה היתרון האמיתי: אתם מסירים שכבה שלמה של תקורה במקום רק לקצר אותה.
יש גם היבט של יציבות. caching מבוסס תוספים מוסיף עוד קוד שיכול להתנגש עם התבנית שלכם, להישבר בזמן עדכון, או להתנהג בצורה מוזרה עם תוספים אחרים. caching בשכבת השרת נמצא כולו מחוץ ל-WordPress, כך שעדכון תוסף לא יכול לכבות אותו בטעות.
איפה לתוספים עדיין יש תפקיד
FastCGI cache מטפל היטב ב-caching של עמודי HTML שלמים, אבל הוא לא נוגע בדברים כמו caching של שאילתות מסד נתונים או object caching. כאן נכנס לתמונה משהו כמו Redis object cache, שפועל לצד caching של עמודים כדי להאיץ סשנים של משתמשים מחוברים, מסכי ניהול, ושאילתות דינמיות ש-page cache לא יכול לעזור בהן. שני הכלים עובדים טוב יחד ולא מחליפים אחד את השני.
מדידת ההשפעה האמיתית
אל תסתמכו רק על אמונה שההגדרה עובדת, בדקו זאת. תסתכלו על ה-response headers שלכם לחיפוש מחוון סטטוס cache (הרבה הגדרות מוסיפות header בשם X-FastCGI-Cache שמציג HIT או MISS). הריצו בדיקת עומס עם כלי כמו ab או wrk לפני ואחרי הפעלת ה-cache, ותראו את מספר הבקשות בשנייה עולה.
באתרים אמיתיים שמדדנו, עמוד בית של WordPress שטיפל ב-40-60 בקשות בשנייה כשהריצה עברה ב-PHP, יכול לזנק ל-2,000+ בקשות בשנייה כשהוא מוגש מ-FastCGI cache. זה סוג המרחב שיכול לעשות את ההבדל בין נפילה של האתר לבין התמודדות עם עלייה חדה בתנועה מפוסט וויראלי או קמפיין שיווקי.
כיסינו אסטרטגיית caching כללית בהרחבה רבה יותר באיך להגדיר Redis Caching על השרת שלכם מבלי לשבור שום דבר, ואם אתם עדיין עוברים על צד התוספים של מהירות WordPress, תיקוני המהירות ב-WordPress ששווים את הזמן שלכם הוא קריאה משלימה טובה.
לסיכום
כוונון ביצועי nginx באמצעות FastCGI cache נותן לכם מהירות בשכבת השרת בלי תוספים, שקשה להשיג עם כל תוסף WordPress, כי הוא מדלג על PHP באופן מלא בבקשות חוזרות. המחיר הוא שזה דורש הגדרה מדוקדקת, בעיקר בכל הנוגע לחוקי דילוג וניקוי, כדי להימנע מהגשת תוכן ישן או שגוי. אם אתם מרגישים בנוח לערוך הגדרות Nginx ולבדוק בקפידה, זה אחד השינויים בעלי ההשפעה הגבוהה ביותר שאפשר לעשות לביצועים של אתר WordPress. ואם אתם מעדיפים לא לנהל בעצמכם את לוגיקת הדילוג ואת הוקי הניקוי, זה בדיוק סוג הדבר ששווה להעביר לחברת אירוח מנוהלת שכבר כיוונה את כל זה.
