איך אנחנו הופכים את WordPress למהירים: LiteSpeed Enterprise, LSCache ו-Redis לכל אתר

LiteSpeed Enterprise + LSCache: שכבת העמוד המלא

כל אתר פועל על LiteSpeed Enterprise עם LSCache ברמת השרת. כאשר תגובת צד-לקוח ניתנת למימון מטמון, שרת האינטרנט מטביע עליה כותרות control-cache ו-tag של LiteSpeed, ו-LiteSpeed מגיש את העמוד השלם ישירות בפגיעה הבאה – ללא תהליך PHP שמופעל, וללא שאילתת MySQL שמונפקת. זהו המנוף המשמעותי ביותר עבור WordPress TTFB, משום שהוא מסיר את אתחול היישום כולו מנתיב הגישה המרכזי.

מכיוון ש-LSCache פועל בתוך שרת הבלוג ולא בתוך תוסף PHP, הוא מתחיל לפעול בשלב מוקדם יותר במחזור החיים של הבקשה ומחזיק עמודים בתבנית שהשרת יכול לרוקן באופן מיידי. זחלן מטמון (cache crawler) שומר על זמינותם של עמודים פופולריים, כך שהמבקר הראשון לאחר ניקוי המטמון אינו זה שמשלם את מחיר יצירת העמוד מחדש. התוצאה היא TTFB נמוך ועקבי באופן ניכר בהשוואה למטמון המבוסס על תוסף בלבד והורכב על גבי סביבת עבודה גנרית, שבה המטמון עדיין יושב מאחורי PHP.

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

מטמון אובייקטים Redis לכל אתר: עבור מה שלא יכול להיות עמוד מלא

לא כל בקשה יכולה להיות עמוד סטטי מלא. סשנים של משתמשים מחוברים, ממשק הניהול של WordPress, עגלות הקניות של WooCommerce, חיפוש, והקטעים הדינאמיים שנותנים ESI חייבים כולם לרוץ על PHP. עבור אלו, המטרה משתנה מ'דילוג על האפליקציה' ל'דילוג על מסד הנתונים'.

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

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

מה באמת מניע את Core Web Vitals

כדאי להיות מדויקים, כיוון שאחסון אתרים נמכר לרוב בהבטחות מוגזמות סביב Core Web Vitals. מדד ה-TTFB הוא החלק במשוואה השייך לשרת, ומערכת המטמון שמעליו היא זו שמצמצמת אותו — עמוד מלא המאוחסן במטמון ומוגש באמצעות HTTP/3 מן הקצה (edge) מגיע לערכי TTFB נמוכים ככל האפשר. מאחר ש-TTFB הוא נקודת הפתיחה של מדד ה-Largest Contentful Paint, מקור מהיר מעניק לכל מדד בהמשך הדרך יריית פתיחה בלתי ניתנת להשגה בכל דרך אחרת.

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

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

שאלות נפוצות