מאז ש־WPML הפך למסחרי, wpml.org מתמודד עם תעבורה רבה הרבה יותר. לפני שבועיים, השרת שלנו פעל בעומס של 95% וזמן התגובה היה מעל ל־10 שניות. עם W3TC, העומס שלנו חזר ל־5% וזמן התגובה הוא סביב 300 ms.
אם אינך מכיר אותו, W3TC הוא תוסף לביצועי אתר. הוא כולל מטמון דפים, אבל זו רק ההתחלה. מעבר למטמון הדפים הבסיסי, הוא גם מצמצם (minifies) קובצי JS ו־CSS, דוחס הכל ומפעיל CDN (רשת אספקת תוכן). יחד, הפונקציות הללו יכולות להאיץ אתר במידה ניכרת, ולאפשר לאתרי WordPress מורכבים להתמודד עם תעבורה בהיקף גבוה.
למה זה כל כך חשוב לאתרי WordPress?
תמונה שווה אלף מילים. כך האתר שלנו נטען ללא מטמון כלשהו (הופק על ידי Pingdom Tools):
אם אתה חושב שזה מפחיד, זכור שבמציאות זה היה גרוע יותר. תרשים זמן טעינה זה צולם כאשר השרת שלנו פעל למעשה בעומס של 5%. כאשר הוא באמת פעל ללא מטמון, השרת "התבשל" בעומס של 95% וזמן העיבוד היה ארוך הרבה יותר. לבית הראשון לקח 5 שניות לצאת ולא 1/2 שנייה כפי שאתה רואה בתרשים זה.
כדי להציג במלואו את דף הבית שלנו, השרת שלנו נאלץ לשלוח 77 קבצים. אפילו תרשים זה, שרץ בעומס שרת של 5%, מסתיים בפסק זמן (timeout) ב־30 שניות (ראה את הקווים האדומים).
האם זה בגלל תכנות מרושל ושיטות עיצוב גרועות? לא.
הכוח של WordPress נובע מהמודולריות. אתה יכול לבחור כל ערכת עיצוב שתרצה, עם כל שילוב של תוספים. המשמעות היא שכל אחד מאלה מפותח באופן עצמאי ופועל עם המשאבים שלו. רוב התוספים שאתה מפעיל כוללים מספר קובצי CSS ו־Javascript ותורמים למאמצי העיבוד של PHP ו־MySQL. היית יכול לבצע אופטימיזציה באופן ידני, אבל אז היית מאבד את כל המודולריות הנהדרת הזו והיינו חוזרים לנקודת ההתחלה.
העבר את האתר שלך דרך הכלים של Pingdom, או כלי אחר למדידת זמן טעינת דפים (יש תוסף ל־Firefox עבור זה). בדוק אילו קבצים נטענים ואת הסדר שלהם. אתה תבחין שקובצי CSS טוענים תמונות ו־CSS אחר, ושיש ערימות של קובצי Javascript שנטענים עבור כל דף.
כדי לעורר לך את התיאבון, הנה מה שהשגנו באמצעות כל התכונות והאפשרויות של W3TC:
המספרים שאתה רואה כאן נכונים. בסך הכל מאוחזרים 28 קבצים כדי להציג את הדף. 5 קבצים מגיעים מ־wpml.org (השרת שלנו) והשאר מגיעים מ־CDN (רשת אספקת תוכן). PHP כמעט ולא צריך לעשות דבר כדי להגיש דף זה, למעט בדיקה שהוא נמצא במטמון ועוד כמה בדיקות קטנות.
הדף כולו נטען בפחות מ־2 שניות וגורם לעומס שבקושי ניתן למדוד בשרת. אנחנו שמחים, המבקרים שמחים ואפילו Google שמח.
שלב 1) מטמון דפים
הדבר הראשון והבסיסי ביותר שתרצה לעשות הוא להפעיל מטמון דפים. עבור אל Performance, הפעל את W3TC והגדר את הקטע Page Caching.
עבור מטמון דפים, נשארנו עם ההגדרות הבסיסיות. דבר אחד שהוספנו היה להחריג את אזורי חשבון הלקוח וההורדות ממטמון הדפים, כך ש־W3TC לא יפריע לחשבונות הלקוחות של WPML ולהורדות של WPML.
אם אתה משתמש במטמון opcode, W3TC ינצל זאת כדי להאיץ את האתר שלך עוד יותר. אנחנו לא משתמשים בזה, אבל זה כדאי אם אתה מפעיל עיבוד PHP מורכב שאינו מאוחסן במטמון.
שלב 2) Minify – אריזה ודחיסה של CSS ו־JavaScript
זוכר את כל קובצי ה־CSS וה־JS שערכת העיצוב והתוספים מוסיפים? עכשיו זה הזמן לתקן את העומס שהם גורמים.
התכונה Minify אוספת מספר קובצי משאבים, אורזת אותם לקובץ בודד ודוחסת אותו. התוצאה היא קובץ אחד גדול יותר במקום עשרות קבצים זעירים.
למרות שהגודל הכולל עשוי להתכווץ ב־50% בלבד, העומס שזה חוסך הוא עצום. במקום שהדפדפן יצטרך להנפיק בקשות HTTP מרובות ולקבל קבצים זעירים רבים, הוא מנפיק בקשה בודדת ומקבל את כולם יחד. שינוי זה הוא כנראה התורם הגדול ביותר לשיפור מהירות התגובה של האתר שלך – במיוחד עבור מבקרים חדשים (שקובצי ה־CSS וה־JS שלך עדיין לא שמורים אצלם במטמון).
לחץ על הלחצן Help בראש הדף. W3TC יסרוק את כל האתר שלך ויחפש קובצי משאבים. לאחר מכן, הוא מאפשר לך לבחור אילו מהם לשלב. בדרך כלל, אתה יכול לבחור הכל, אבל אתה צריך לשים לב למה שאתה עושה, מכיוון שזה יכול לשנות את סדר הטעינה.
לאחר שבחרת את קובצי ה־CSS וה־JS לצמצום, עליך לוודא שהסדר שלהם נכון.
עבור קובצי CSS, גרור קבצים למעלה ולמטה ברשימה.
הסדר שאתה רואה ברשימה זו צריך להתאים לסדר שבו נטענים קובצי CSS ללא Minify. אתה יכול לראות זאת בקוד המקור של דף ה־HTML שלך.
קובצי Javascript הם קצת יותר מסובכים. כאן, סדר הטעינה קריטי עוד יותר, מכיוון שסדר שגוי יגרום לשגיאות JS ולפונקציונליות שבורה.
W3TC מאפשר לך לבחור אילו קובצי JS יעברו לאזור הכותרת (header) ואילו יעברו לגוף הדף (body). לדוגמה, הסקריפטים של Google Analytics ימוקמו ממש לפני , בעוד ש־jQuery נכנס לכותרת, מכיוון שהוא צריך לרוץ ראשון (ומחוץ לרשימת הצמצום).
שלב 3) רשת אספקת תוכן (CDN)
עבורנו, הדובדבן שבקצפת מגיע בצורה של CDN פונקציונלי להפליא.
הגדרה והפעלה של CDN חורגות מהיקף פוסט זה, מכיוון שהן דורשות הגדרת חשבון בשירות צד שלישי.
עבור האתרים שלנו, אנו משתמשים ב־Amazon S3 לאחסון וב־CloudFront לאספקה. ישנן אפשרויות מצוינות אחרות בחוץ שתוכל לחקור ולהשוות.
לאחר שחשבון ה־CDN שלך מוגדר, W3TC שולח את הקבצים המקומיים שלך ל־CDN ומחליף קישורים מהשרת שלך לקבצים ב־CDN. לאחר מכן, השרת שלך שולח רק את קובצי ה־HTML וה־CDN דואג לשאר.
בעוד שהשרת שלך הוא מכונה בודדת, ה־CDN הוא למעשה רשת של שרתים. הוא ישלח את הקבצים מהשרת הקרוב ביותר לכל מבקר. רשתות CDN יכולות להגיש קבצים סטטיים הרבה יותר מהר מכל שרת בודד. על ידי שימוש ב־CDN, אתה משפר את חוויית המבקרים שלך ומפחית באופן דרסטי את ניצול רוחב הפס והרשת של השרת שלך.
עליך לעקוב אחר אשף הגדרת ה־CDN ב־W3TC. הוא יעזור לך להעביר את ספריית המדיה, ומשאבי ערכת העיצוב והתוספים ל־CDN.
נהנה מאופטימיזציה של ביצועי האתר? ספר לנו על ידי השארת תגובה כאן!
