אחסון וביצועים
איך אנחנו הופכים את WordPress למהיר: LiteSpeed Enterprise, LSCache ו-Redis לכל אתר
בקשת ה-WordPress המהירה ביותר היא זו שלעולם אינה מתבצעת — הנה האופן שבו המערך שלנו מגיב למרבית הביקורים מהמטמון עוד לפני שנעשית פנייה כלשהי אל PHP או MySQL, ומה המשמעות של כך עבור Core Web Vitals.
הבקשה המהירה ביותר היא זו שלעולם אינה מתבצעת
בקשת WordPress סטנדרטית היא עתירת משאבים. שרת האינטרנט מעביר את הבקשה ל-PHP, PHP מפעיל את WordPress, מריץ את התוספים, שולח שאילתות ל-MySQL כמה עשרות פעמים, מרכיב את ה-HTML ורק אז מחזיר בתים (bytes). באתר עמוס, כל התהליך הזה מתרחש עבור כל מבקר ומבקר, ושם בדיוק מתבזבז כמעט כל הזמן עד קבלת הבית הראשון (time-to-first-byte) שלכם.
התשובה שלנו היא לוודא שעבור רוב הביקורים, שום דבר מזה לא יקרה כלל. בכל האתרים שאנו מארחים — למעלה מ-100,000 אתרי PBN ובנוסף WordPress מנוהל סטנדרטי — הרוב המכריע של צפיות הדפים בצד הלקוח (front-end) מוגש כדף מלא שעבר עיבוד מראש ישירות מהמטמון, מבלי להפעיל את PHP או לגשת למסד הנתונים. שאר הפוסט הזה עוסק באופן שבו השכבות שמאפשרות זאת משתלבות יחד, והיכן כל אחת מהן מצדיקה את מקומה.
ההקשר החשוב הוא שלא מדובר במטמונים מתחרים שעליכם לבחור ביניהם. מטמון עמוד מלא, מטמון אובייקטים וקצה ה-CDN קולטים כל אחד סוג שונה של בקשות, והערך האמיתי טמון באופן שבו הם מעבירים את הטיפול מאחד לשני.
LiteSpeed Enterprise + LSCache: שכבת הדף המלא
כל אתר פועל על גבי LiteSpeed Enterprise עם LSCache ברמת השרת. כאשר תגובת צד-לקוח (front-end) ניתנת לשמירה במטמון, שרת האינטרנט מחתים אותה בכותרות LiteSpeed cache-control ותגיות, ו-LiteSpeed מגיש את הדף המלא ישירות בבקשה הבאה — ללא הפעלת תהליך PHP וללא שליחת שאילתת MySQL. זהו המנוף הבודד המשמעותי ביותר ל-TTFB ב-WordPress, מכיוון שהוא מסיר לחלוטין את אתחול היישום מנתיב הביצוע הקריטי.
מכיוון ש-LSCache פועל ישירות בתוך שרת האינטרנט ולא בתוך תוסף PHP, הוא מתחיל לעבוד בשלב מוקדם יותר במחזור חיי הבקשה ושומר דפים במבנה שהשרת יכול לנקות באופן מיידי. סורק מטמון (cache crawler) שומר על דפים פופולריים זמינים ומוכנים, כך שהמבקר הראשון לאחר ריקון המטמון אינו זה שמשלם את מחיר הפקת הדף מחדש. התוצאה היא TTFB נמוך ועקבי במידה ניכרת בהשוואה למטמון מבוסס-תוסף בלבד המחובר למערך שרתים גנרי, שבו המטמון עדיין יושב מאחורי PHP.
תוסף המטמון שלנו ברמת מאגר מגיע מותקן מראש ומתעדכן אוטומטית בכל אתר, ומחבר את WordPress ל-LSCache בצורה נכונה ישר מהקופסה. במקור שאינו LiteSpeed, הוא פשוט אינו פולט כותרות של דף מלא ומפנה את הדרך, בעוד שמטמון האובייקטים וכללי ההחרגה ממשיכים לפעול — כך שאתר שהועבר לעולם אינו נשאר במצב מקולקל שמוגדר למחצה.
שמירה על מהירות מבלי להגיש תוכן מיושן: ESI וניקוי מטמון אוטומטי חכם
שמירה אגרסיבית של עמודים שלמים במטמון כוללת שני מצבי כשל קלאסיים: הגשת עמוד של מישהו אחר למשתמש מחובר, והגשת עמוד שהיה אמור להשתנות לכל משתמש שהוא. שניהם נפתרים בשכבת המטמון ולא על ידי הפחתת השימוש במטמון.
טכנולוגיית ESI (Edge Side Includes) מאפשרת לנו לשמור את הדף במטמון, תוך יצירת פתחים לחלקים שחייבים להישאר דינמיים. בחנות WooCommerce, דפי הקטלוג, המוצרים והקטגוריות מוגשים כמטמון דף מלא לקבלת ה-TTFB המהיר ביותר האפשרי, בעוד ש-ESI מרנדר את מקטע העגלה, סיכומי עגלת המיני ומצב החשבון בכל בקשה. עגלת הקניות, התשלום בקופה, החשבון שלי וכל דפי nonce או הפעלה מוחרגים כברירת מחדל. הקונים רואים תמיד את הסל שלהם ואת תהליך התשלום הפעיל; כולם עדיין מקבלים את חזית החנות ישירות מהמטמון.
העדכניות מנוהלת באמצעות ניקוי אוטומטי חכם. ווי ניקוי (purge hooks) מופעלים אוטומטית כאשר תוכן, מוצרים, מחירים או הזמנות משתנים, כך שהדפים הרלוונטיים שבמטמון מתרעננים מיד במקום להסתמך על טיימר, ובאפשרותכם גם לבצע ניקוי לפי דרישה מלוח הבקרה או מתוך WordPress. ניקוי מבוסס-תגיות פירושו שעריכת פוסט אחד מנקה את אותו פוסט ואת הארכיונים שלו — ולא את כל המטמון — כך שעריכה בודדת אינה גורמת להפעלה קרה (cold-start) של האתר כולו.
מטמון אובייקטים של Redis לכל אתר: עבור מה שלא יכול להיות עמוד שלם
לא כל בקשה יכולה להיות עמוד מלא וסטטי. הפעלות מחוברות, ניהול WordPress, עגלות WooCommerce, חיפוש והמקטעים הדינמיים ש-ESI משאיר פעילים חייבים כולם להריץ PHP. עבור אלה, המטרה עוברת מ'לדלג על היישום' ל'לדלג על מסד הנתונים'.
כל אתר מקבל מטמון אובייקטים ייעודי של Redis משלו. WordPress שומר בזיכרון המטמון את התוצאות של קריאות חוזרות ממסד הנתונים — אפשרויות, נתונים זמניים (transients), חיפושי פוסטים ומונחים, ונתוני מוצרים והפעלות של WooCommerce — בזיכרון, כך שאותה שאילתה אינה מופעלת מול MySQL בכל כניסה. ההשפעה בולטת ביותר בדיוק במקומות שבהם מטמון עמוד מלא אינו יכול לעזור: לוחות בקרה מהירים יותר, עגלות קניות מהירות יותר ועומס נמוך בהרבה על מסד הנתונים בעת תעבורה כבדה.
מטמון האובייקטים פועל ברמת האתר הבודד ואינו משותף, דבר בעל חשיבות הן לביצועים והן להפרדה. בשילוב עם הגבלת משאבי מסד הנתונים ברמת האתר, שאילתות כבדות או לקויות של אתר אחד אינן יכולות למנוע משאבי מסד נתונים מאתרים שכנים. תוכלו לקרוא עוד על האופן שבו כל המערך הרב-שכבתי פועל יחד בדף תכונות המטמון שלנו, ועל הגבולות בין הדיירים תחת נושא ההפרדה.
הקצה והתעבורה שמתחתיו
מטמון שנמצא בשרת המקור עדיין נדרש לחצות את הרשת. לפני השרת ניצב ה-CDN edge, כך שנכסים סטטיים ודפים הניתנים לשמירה במטמון מוגשים מנקודת נוכחות הקרובה למבקר, ושרת המקור נשאר פנוי גם תחת עומס. עבור קו האחסון נטול העקבות (footprint-free) שלנו, אותו edge הוא מאגר multi-CDN הפרוס על פני מספר ספקים, המשרת הן יעד של מניעת עקבות SEO והן יעד של ביצועים; במערכות WordPress רגילות זוהי פשוט שכבה מהירה ויעילה השומרת על שרתי המקור במצב סרק.
מתחת לפני השטח, לא חסכנו ביסודות. אתרים פועלים על גבי אחסון NVMe עם HTTP/3, כך שהבייטים שהמטמון שולח מגיעים באמצעות תעבורה מודרנית ומרובת-ערוצים (multiplexed) עם אחסון מהיר מאחורי כל החטאת מטמון (cache miss). אף אחת מהשכבות הללו אינה תוסף בתשלום: LiteSpeed, LSCache, שירות Redis לכל אתר, NVMe ו-HTTP/3 הם קו הבסיס בכל חבילה, ולא רמת שדרוג למכירה.
מה באמת משפיע על Core Web Vitals
ראוי לדייק, שכן לעיתים קרובות מגזימים בהבטחות לגבי אחסון אתרים בהקשר של Core Web Vitals. מדד ה-TTFB הוא החלק במשוואה שנמצא בשליטת השרת, ומערך המטמון שלעיל הוא שמוריד אותו — דף מלא שנשמר במטמון ומוגש באמצעות HTTP/3 מהקצה מציג בערך את הערך הנמוך ביותר ש-TTFB יכול להגיע אליו. מכיוון ש-TTFB הוא נקודת הפתיחה של Largest Contentful Paint, מקור מהיר מעניק לכל מדד בהמשך יתרון פתיחה שלא ניתן להשיג בשום דרך אחרת.
אך LCP, CLS ו-INP נקבעים בעיקר בדפדפן, על ידי הדף עצמו: תמונת ראשית (hero) לא מותאמת, קובצי CSS ו-JavaScript החוסמים רינדור, פריסה שזזה בעת טעינת גופנים ופרסומות, ועבודה כבדה של תוספים על ה-main-thread. שום כמות של שמירה במטמון בשרת (server caching) לא תתקן תמונת ראשית של 2 מגה-בייט או ערכת עיצוב שטוענת מגה-בייטים של JavaScript. אחסון הגון הופך את תרומת השרת לאפסית בפועל ועקבית, ולאחר מכן חובת האתר היא לשמור על ממשק משתמש (front end) קל משקל.
חלוקת עבודה זו היא המודל המחשבתי המועיל. אנו מבטיחים שהבקשה תגיע לדפדפן במהירות ותישאר מהירה גם תחת עומס תנועה; אתם שומרים על נפח נתונים (payload) קטן ויציב. המקום שבו השניים נפגשים — חימום המטמון, אספקה בקצה הרשת (edge delivery) ושמירה על מסד נתונים מהיר תגובה כדי שדפים דינמיים לא ייעצרו — הוא בדיוק המקום שבו המערך הטכנולוגי שלנו מכוונן, וזה מה שהופך WordPress מנוהל בפלטפורמה זו למהיר יותר מאשר אותו אתר באחסון גנרי.
שאלות נפוצות
האם אני עדיין צריך תוסף שמירה במטמון כמו WP Rocket?
לא. שמירת דפים שלמים במטמון מנוהלת בשרת האינטרנט על ידי LSCache של LiteSpeed, ותוסף המטמון שלנו — שמותקן מראש ומתעדכן אוטומטית — מחבר אליו את WordPress בצורה נכונה, בגיבוי מטמון אובייקטים של Redis לכל אתר. הוספת תוסף שני לשמירת דפים שלמים במטמון בדרך כלל מתנגשת עם המטמון ברמת השרת במקום לסייע, ולכן הדבר אינו נחוץ ואינו מומלץ.
האם שמירה במטמון תשבש את עגלת ה-WooCommerce שלי או דפים למשתמשים מחוברים?
לא. עגלת הקניות, התשלום, my-account וכל דפי ה-nonce או ההפעלות (sessions) מוחרגים מהמטמון כברירת מחדל, ו-ESI שומר על מקטע העגלה והסכומים הכוללים פעילים בדפים שאחרת נשמרים במטמון. הקונים רואים תמיד את הסל שלהם ואת דף התשלום הפעיל בזמן שחזית החנות עדיין נטענת מהמטמון.
כיצד המטמון נשאר מעודכן כאשר אני מפרסם או עורך?
ניקוי אוטומטי חכם מופעל בנקודות ה-hooks הרלוונטיות של WordPress, כך שפרסום, עריכת תוכן או שינוי של מוצר, מחיר או הזמנה מנקים רק את הדפים המושפעים ואת הארכיונים שלהם — ולא את כל זיכרון המטמון — וסורק מחמם אותם מחדש. תוכלו גם לבצע ניקוי לפי דרישה מלוח הבקרה או מתוך WordPress.
האם אחסון לבדו יכול להעניק לי Core Web Vitals מושלמים?
זה מעניק לכם את ה-TTFB הטוב ביותר שניתן, המהווה את חלקו של השרת ויתרון התחלתי עבור Largest Contentful Paint. אולם LCP, CLS ו-INP נקבעים במידה רבה על ידי הדף עצמו — גודלי תמונות, משאבים החוסמים עיבוד, יציבות הפריסה ו-JavaScript של ה-main-thread. התשתית שלנו הופכת את תרומת השרת למהירה ועקבית; שמירה על עומס נתונים רזה ב-front-end היא זו שסוגרת את יתרת הפער.
קשור
נסו זאת בחינם למשך 14 יום
הפעילו את האתרים הראשונים שלכם בחינם למשך 14 יום — ללא צורך בכרטיס אשראי. מעבירים רשת קיימת? ההעברות הן בחינם, ללא הגבלה.
התחל בחינם