מדריך להגדרת Swift Performance

למה דווקא Swift Performance

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

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

ההיכרות שלי עם Swift היתה אחרי שהתחלתי לחקור את נושאי שיפור מהירות אתרים ושיפור ביצועי אתר וורדפרס.

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

שימו לב: זהו תוסף אדיר אבל גם יחסית מורכב. אם אתם מעדיפים פשטות, לכו על WP Rocket. בשבילי Swift מעולה ונוח והיתרון הגדול, תוכלו להסתפק בגרסה החינמית כדי לקבל ביצועים מעולים! הרבה אנשים מתקינים אותו וטוענים שהוא הרס להם את האתר, בהרבה מקרים זה כי הם לא מספיק הבינו מה הם עושים. חוץ מההגדרות שתקראו פה, צריך לדעת אילו מנגנוני קאש אתם יכולים להפעיל במקביל. למשל Redis ו-Memcached לא היו נתמכים בעבר והיום למרות שנתמכים עדיין אני רואה פה ושם בעיות עם רדיס. ובכל זאת אני מעדיף את Swift על פני תוספים אחרים.

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

איך להגדיר נכון את Swift

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

שני כללים מקדימים לפני שאתם עוברים להגדרות.

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

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

General

• Purchase Key – (גרסת פרו) הכניסו את הרישיון פה. תוכלו למצוא אותו באתר תחת החשבון שלכם.
• Disable Cookies – אם אתם משתמשים ב Apache או GA ואתם נדרשים לעמוד ב-GDPR, תצטרכו להדליק את זה ולאפשר בעצמכם את הקוקיס מאוחר יותר.
• Hide Footprints – (גרסת פרו) דלוק. לא כזה משנה.
• Use Compute API – (גרסת פרו) דלוק. עוזר לתהליכי מיניפיקציה ו critical css \ fonts.
• Prebuild Booster – דלוק. כמו הסעיף הקודם, טוב לביצועים של מנגנון בניית הקאש.
• Clear Cache Role – מי יכול לנקות קאש.
• Disable Admin Notices – כבוי. הדליקו אם אתם רוצים.
• Beta Tester – (גרסת פרו) כבוי.
• Debug Log – כבוי. הדליקו רק אם יש בעיה ואתם צריכים להיעזר בקבצי לוג.

General – Tweaks

• Normalize Static Resources – דלוק. מוריד Query Strings מ- Static resources.
• Prefetch DNS – דלוק. מקצר את זמן הטעינה של העמוד על ידי פעולה מוקדמת של DNS resolve לקריאות לדומיינים של צד שלישי שנמצאות ב HTML ו CSS.
• Collect domains from scripts – פועל. תוספת לסעיף הקודם. מאפשר את אותו הדבר גם לקבצי JS.
• Exclude DNS Prefetch – אם יש לכם קריאה שלא תרצו שבאופן אוטומטי יעשו לה resolve, תוכלו להחריג אותה פה. אני לא הוספתי לזה משהו כרגע אבל יכול להיות שימושי אם יש לכם משהו שרוב הסיכויים שלא באמת תיגשו אליו או קריאה לאיזה API שאתם מעדיפים לא להשתמש באופן אוטומטי.
• Gravatar Cache – כבוי. אצלי זה ככה כי פשוט ביטלתי את gravatar באתר. אם אתם כן משתמשים, בכל מקרה תטענו אותם רק בסוף (הרי התגובות בכל מקרה בסוף העמוד) או תוכלו להוסיף את זה אם תראו שיפור. החסרון הוא קאש גדול יותר במקרה של הרבה תמונות gravater.
• Custom Htaccess – אצלי זה ריק. אם אני צריך להוסיף משהו, אני מוסיף ישירות ל htaccess.
• Background Requests – (גרסת פרו) מאפשר להריץ בקשות ברקע. הכוונה לפעולות ajax שהיוזר לא מצפה לתשובה מידית שלהם לכן אין צורך להמתין. הדוגמה הכללית היא "action=post_view_count" אבל יש עוד דוגמאות וכל אתר ושימושיו. אם אתם משתמשים ב ajax, בדקו בטאב network של כרום או באחד ה waterfals של אתרי בדיקת מהירות, באילו פעולות אתם משתמשים בכל עמוד ואם אלו פעולות שיכולות לרוץ ברקע, הוסיפו אותם להגדרה הזאת. את השם של ה- action תוכלו למצוא גם בטאב נטוורק או על ידי חיפוש בקוד או אם רוצים לחפש בצורה רוחבית אז עם תוסף כמו String Locator.

General – Heartbeat

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

• Disable heartbeat – פועל על Media, Menus, Users ו-Tools. אין כאן נכון ולא נכון. תפעילו מה שנראה לכם נכון לאתר שלכם או אל תפעילו בכלל. כמו שכתבתי קודם, לא זה מה שאמור לפגוע בכם.
• Heartbeat Frequency – בין 2 ל 5 דקות. אם תחליטו כן להשאיר אותו כמו שהוא אבל תרצו לשלוט על התזמון שלו, כאן תוכלו לבחור. מספר גבוה מדי יהיה יעיל יותר אך יהיה חשש שלא תראו את האדמין הכי מעודכן שלכם.

General – Cronjobs

• Limit WP Cron – (גרסת פרו) מוגבל אצלי ל 50 אחוז כרגע אבל אין מספר קסם, כל אתר והצורך לו. מאפשר להגביל הרצה של cronjobs של וורדפרס או לבטל לגמרי.
• Enable Remote Cron (גרסת פרו)  – כבוי. מאפשר להריץ cronjobs באמצעות Swift.

General – Google Analytics

• Bypass Google Analytics – כבוי. אני משתמש ב- Flying Analytics.
  אם תדליקו, יופיעו לכם עוד הגדרות.

Media

Media – Images

• Optimize Images on Upload – (גרסת פרו) אני משתמש בפתרון אחר אבל אם תפעילו, כל תמונה שתעלו תעבור אופטימיזציה.
• Serve WebP – אם תדליקו את האופציה של אופטימיזציה לתמונות, יפתחו לכם עוד אפשרויות שכולם ממש לא מסובכות. הדבר היחיד שכם קצת דורש תשומת לב הוא serve webp. האופציה הבטוחה יותר לשימוש היא עם תג picture. יכול להיות שתוכלו להשתמש ב rewrite אבל לא עם כל שרת. זה אמור גם לדאוג לכם לדפדפנים שלא תומכים ב webp כמו ספארי (שהים כבר כן תומך) ולטעון שם את קובץ התמונה המקורי.
  הערה כללית לגבי webp – שימו לב שבתמונות עם רזולוציה גבוהה, הרבה פעמים גרסת jpeg מכווצת שוקלת פחות מהמגבילה כ-webp! לעומת זאת בשאר המקרים, webp עדיף, מה גם ש page speed אוהב את זה.
• Inline Small Images – דלוק. מאפשר לתמונות להיות מובנות כטקסט בתוך ה-html במקום להוריד אותם כל פעם. זה נראה מעולה אבל צריך להיזהר עם זה מכמה סיבות:

1. אם אתם משתמשים ב CDN כדי לקבל את התמונות שלכם דחוסות וכ- webp, מן הסתם זה לא יעבוד על התמונות שתעשו inline.
2. המרה ל base64 (ככה עושים את הinline) מגדילה את גודל התמונה בבתים. כך שזה טוב בעיקר לתמונות קטנות, אחרת ה html שלכם יהיה בגודל לא רצוי.
3. בהמשך לסעיף הקודם, גם אם עושים רק לתמונות קטנות, צריך לשים לב שאין יותר מדי תמונות בגלל אותה סיבה.

סעיפים 2 ו 3 חשובים משום שאנחנו לא רוצים שגודל הבקשה הראשונה שלנו יהיה גדול יותר מ 14kb.

בנוסף לכל הסיבות האלה, אם התמונות שלכם בכל מקרה בסוף העמוד ואתם מאחרים את הטעינה שלהם, זה לא משנה שתטענו אותם בקריאה לתמונה במקום inline.

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

בימינו שהרבה שרתים תומכים ב http/2 (היום כבר ב 3) ובטח אתם משתמשים ב server push זה פחות נחוץ. לכן אין צורך מיוחד לעשות זאת ועדיין אם יש אייקון קטנטן בראש העמוד שתמיד נטען הגיוני לעשות את זה.

• File Size Limit – כ-1000 בתים. לשיקולכם אבל התחשבו במה שכתבתי למעלה.
• Exclude Images – תוכלו להוסיף תמונות ספציפיות להחריג.
• Lazyload – דלוק. עובד טוב. אם אתם מעדיפים םתרון אחר שהתרגלתם אליו, גם בסדר רק אל תשתמשו בשני תוספים לאותה משימה.
• Respect Lazyload Standards – דלוק. תומך בהתעלמות מתמונות שמסומנות כלא לייזי.
• Preload Sensitivity – כמה פיקסלים לפני שמגיעים לאזור לטעון את התמונה. כדאי מינימום 50, אפשר קצת יותר.
• Load Images on User Interaction – עוד אפשרות מעניינת אבל לא תמיד מתאים. לשיקולכם.
• Force Responsive Images – כבוי. אין צורך בזה אם אין לכם תוסף או תבנית שעושה שימוש לא נכון בגדלי תמונות. אם כן יש לכם בעיה כזאת, תפעילו.
• Lazyload Background Images – אופציה מעניינת מאוד שלא כולם תומכים בה. אם אתם משתמשים ב background images, שווה לנסות.

Media – Embeds

• Youtube Smart Embed – (גרסת פרו) דלוק. פתרון מעולה לטעינת סרטונים מיוטיוב רק בעת אינטרקציה של היוזר.
• Exclude Youtube Videos – (גרסת פרו) החרגת סרטוני יוטיוב.
• Preload Sensitivity – (גרסת פרו) כמה פיקסלים לפני שהסרטון יהיה נראה למשתמש במובייל, הסרטון יטען.
• Lazy Load Iframes – דלוק. חשוב מאוד לא לטעון אותם ללא צורך.
• Exclude Iframes – אם יש לכם embedded iframes שאתם כן רוצים שיטענו מיד בעליית העמוד, החריגו אותם פה.
• Respect Lazyload Standards – אם בחרתם ב-lazyload iframes זה יתחשב בiframes שבחרו ב skip lazyload.
• Preload Sensitivity – כמה פיקסלים לפני שה-iframe נראה הוא יטען.
• Load Iframes on User Interaction – כבוי. אם אתם רוצים להיות עוד יותר חסכנים מאשר lazyload, תוכלו לטעון iframes רק כשהיוזר יבצע אינטרקציה כלשהי איתם.

Optimization

Optimization – General

• Merge Assets for Logged in Users – כבוי. אין לי הרבה משתמשים מחוברים באתר אז לא רלוונטי. אם אתם מאפשרים, בדקו שהכל עובד תקין.
• Enable Server Push – (גרסת פרו) דלוק. מאפשר לנצל את יכולת server push של http/2 ולשלוח משאבים לפני שהקליינט ביקש. אם אחרי בדיקה נראה לכם שזה מזיק לעליית הדף, כבו.
• Optimize Prebuild Only – דלוק. העניין הוא שאופטימיזציה יכולה לקחת זמן בדפים מסוימים ולכן מבקר שנכנס פעם ראשונה לדף שעדיין לא במטמון יצטרך לחכות לאופטימיזציה. אם תאפשרו את זה, האופטימיזציה תתרחש רק בעת הבניה מראש של הקאש.
• Optimize in Background – דלוק. אולי מיתר את הסעיף הקודם. שחקו עם זה ובדקו מה נכון לכם.
• Prebuild Booster – כבוי אצלי אבל יכול לעזור אם יש בעיה בזמנים של בניית הקאש.
• Fix Invalid HTML – כבוי. אם תפעילו, זה יאפשר ל Swift לתקן html שגוי כמו ש Chrome לדוגמה יודע להתמודד עם זה. העניין הוא שכל פעולה שנוסיף לתהליך הקאשינג, עלול להאט אותה אז אם נתקלתם בצורך, תפעילו, אחרת, תשאירו כבוי.  אם אתם משתמשים בתבנית אמינה ותופסים איכותיים, לא אמורה להיות לכם בעיה.
• Minify HTML – דלוק. ניתן להפעיל ב Cloudflare ולכבות פה. אבל אני מעדיף הפוך.
• Disable Emojis – דלוק. זוהי יכולת מובנית בוורדפרס שאין לי צורך בה.
• Limit Simultaneous Threads – דלוק. לא חייבים להפעיל אבל בגלל שאני בשרת משותף אני חושש מצריכת משאבים גבוהה בשרת. אם האתר לא גדול (לא יודע מספר מדויק וגם תלוי בשרת שלכם אבל נניח אתר עם לא יותר מכמה עשרות דפים), אין צורך.
• Maximum Threads – אם אתם בשרת משותף הגדירו 1 או 2. המשך לסעיף הקודם.
• DOM Parser Max Buffer – ברירית מחדל. המקסימום של גודל הבאפר בבתים ש Swift יפרסר. בגלל שאני לא יודע מה המספר האמיתי שכדאי לתת לו, אני פשוט סומך על מה שהם רשמו בברירת המחדל. הרציונל הוא שאם יש לכם DOM גדול מדי, Swift יוותר על יצירת קאש בשביל אותו דף.

Optimization – Scripts

כמה מילים לפני שנדבר על ההגדרות הבאות. מה זה merge scripts\styles והאם זה כדאי?

הכוונה ב merge היא איחוד של סקריפטים או סטיילים כדי להרוויח שני דברים:

1. קריאה אחת במקום מספר קריאות.
2. יתכן חיסכון בסה"כ גודל הנכס.

במחשבה ראשונה זה נראה רק טוב כי בשורה תחתונה בתאוריה האתר יעלה מהר יותר.

למה בכל זאת לא בטוח שיש צורך?

1. בעולם ה HTTP/2 קריאות מרובות כבר לא כל כך בעייתיות כמו בעבר.
2. מספר סה"כ הבתים אולי יירד קצת אבל צריך לשים לב לשני פרמטרים חשובים:
   1. האם הגדלים המקוריים כל כך גדולים שהכיווץ שמרוויחים באיחוד באמת יעזור?
   2. האם הקובץ המאוחד יהיה כל כך גדול שאמנם תחסכו קריאות אבל תצטרכו לטעון קובץ אחד בשלמותו מיד בעליה מה שיגרום בסופו של דבר להאטה בעליית האתר.

אז למה בכל זאת לעשות את זה? כי לבעיות שהעלתי יש פתרונות. ל- CSS יש פתרון של Critical CSS ל- JS יש פתרון של העברה ל- footer ו- defer\async.
אז לכאורה אפשר להרוויח מכל העולמות, גם לאחד וגם להימנע מהבעיות שציינתי. אז מה הבעיה?

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

אז זהו עכשיו זה כבר כן בסדר? יכול להיות שכן. אבל גם יכול להיות שפתרון ה critical css שלכם יגרום לבעיית דומה ל- FOUT – Flash of Unstyles Text, כלומר תצוגת האתר לא תהיה עם הסטייל הנכון לזמן מסויים ואז תעדכן. זה יכול להיות לזמן קצר מאוד, כמה מאות מילי שניה אולי פחות אבל יש כאלה שיגידו שזה מציק.

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

כמו שאתם רואים הנושא מסובך ומצריך הרבה מחשבה.

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

אגב, אם לא עושים את זה, זה לא אומר שאנחנו טוענים את כל הסטיילים והסקריפטים מיד והכל רץ מיד כי מצב כזה ברור שהוא לא מומלץ. עדיין אפשר וצריך לטפל (כמעט) בכל הסקריפטים וב- iframes שיטענו רק בפוטר וחלקם אף לאחר idle של כמה שניות או באינטרקציה של המשתמש.

ולגבי CSS להשתמש ב- Asset Cleanup (או perfmatter ואחרים) כמו שנראה בהמשך. או אם אתם רוצים עוד יותר לשפר, תוכלו להסיר unused css (שזו תורה בפני עצמה וגם בזה אני אישית מעדיף לא לגעת בדרך כלל אבל תוכלו להשתמש בכלים שעושים את זה).

• Merge Scripts – הסברתי על זה. זה יכול לשפר את זמן טעינת העמוד אבל זה גם עלול לשבור דברים בעמוד.
  אם החלטתם להפעיל את זה, תעברו על כל ההגדרות שיפתחו לכם ותעבדו על פי הנושאים שרשמתי בתחילת הסעיף הזה. אתם יכולים קודם פשוט להפעיל ולראות מה נשבר ואז לנסות להחריג דברים. אם אתם משתמשים בתבנית "שמנה" או בבונה אתרים הסיכוי שמשהו ישבר גבוה מאוד.

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

1. באמעצות Lazy load scripts של Swift או על ידי שימוש ב Flying Scripts שאזכיר בהמשך (בו תוכלו לטעון סקריפטים ב user interaction או אחרי timeout מסוים במקרה ולא היתה אינטרקציה).
2. באמצעות קוד פשוט ב php. שימו לב שאפשרי לעשות זאת בצורה רוחבית או לפי ה-handle הספציפי של הסקריפט. פה תוכלו לראות דוגמה איך לעשות defer לסקריפטים.

• Async Execute – ייחודי לSwift. יכול לעזור לזמן רנדור על ידי הרצה אסינכרונית של סקריפטים מתוך ה merged scripts. אבל כמובן בדקו טוב שלא שבר כלום.
• Delay Async Scripts – עוד אופציה ייחודית, אם אתם עושים איחוד שווה לכם ממש לבדוק את האופציה הזאת! זה יאחר את הטעינה של הסקריפט לאינטרקציה של הגולש.
• Exclude 3rd Party Scripts – תלוי בכל אתר. זה יכול להועיל שיהיה כבוי ומצד שני הפוך. תלוי בכמה סקריפטים כאלה יש לכם ומאיפה נטענים. אם אתם לא בטוחים, תדליקו את האפשרות הזאת.
• Exclude Scripts – עשיתם merge ויש בעיות? כאן תתקנו את זה.
• Footer Scripts – החריגו מהאיחוד והעבירו ל footer. טיפול פרטני לסקריפטים.
• Deferred Scripts – החריגו מאיחוד והוסיפו defer. טיפול פרטני לסקריפטים.
• Exclude Inline Scripts – החרגה של inlined scripts.
• Footer Inline Scripts – כמו הסעיף הקודם אבל העבירו ל footer.
• Exclude Script Localizations – האמת אני לא זוכר מה זה עושה אבל Swift ממליצים להדליק אז שיהיה.
• Minify Javascripts – דלוק (אם דלוק ב Cloudflare, כבו פה).
• Minify with API – חושב שזה רק בגרסת פרו. הדליקו רק אם יש שגיאות js אחרי המיניפי הרגיל.
• Proxy 3rd Party Assets – צריך לראות איך זה ישפיע לכם על סקריפטים של צד שלישי ולכן אם לא רוצים להסתבך כבו את זה אבל זה כן יכול לעזור לכל מיני סקריפטים צד שלישי שאתם לא שולטים בקאש שלהם.
• Separate Scripts – יכול לעזור אם יש בעיות ב merge. יצור לכם merge לכל דף בנפרד.
• Print merged scripts inline – אם יש קובץ מאוחד קטן, יחסוך את הקריאה הנוספת וכל ה js יהיה בפוטר.
• Lazy Load Scripts – טעינה של סקריפטים רק באינטרקציה של היוזר. יכול להיות שימושי מאוד במקרים רבים ויחסוך זמן רנדור.
• Include Scripts – אם יש סקריפטים שנקראים מתוך סקריפטים שהם excluded תוכלו להוסיף אותם כאן במפורש.

• Disable jQuery Migrate – דלוק. רוב הסיכויים שאתם לא צריכים את זה (ואם כן, כבו את האופציה או החליפו תבנית / תוסף שדורש את זה).
• Preload Scripts – הוסיפו סקריפטים שאתם רוצים שיוגדרו עם preload.
• Custom Inline JavaScript – הוספה של סקריפטים inline נוספים.

Optimization – Styles

• Merge Styles – דלוק. ראו סעיף קודם. במקרה של סטיילים יש יתרון נוסף של critical css אבל גם פה יכולות להיות בעיות. אתם בטוח תחסכו קריאות אבל לא בטוח תקבלו מהירות טובה יותר + יש סיכוי (לא גדול אבל קיים) שמשהו ישבר. אם תחליטו בכל זאת להפעיל, בדקו טוב שהכל עובד. אם תחליטו להפעיל ותצטרכו עזרה בהגדרות, פנו אלי. גם ככה הפוסט מאוד ארוך ואני מעדיף לא לפרט יותר מדי.
  הדברים החשובים הם באיזו שיטה לייצר critical css והאם להוסיף css נוף לcritical או להחריג דברים מהcritical.
  לגבי השיטה יש 2 אופציות, לפי unused css או לפי viewport. תוכלו גם לבחור האם לטעון את שאר ה css רק לאחר גלילה (ייחודי ל Swift).
• Generate Critical CSS – כמו שהשם אומר, יצירת critical css. אם אתם לא בטוחים מה זה, קראו את הפוסט שלי על הנושא.
• Critical CSS method – באיזו שיטה ליצור את ה critical. או unused או viewport. הראשון מנסה להבין איזה css לא צריך והשני מנסה להבין מה צריך ל viewport (או above the fold). בשיטה השניה הקובץ הסופי כנראה יהיה קטן יותר.
• Extra CSS \ Critical CSS -הוספת css נוסף ל critical או ל merge הכללי.
• Load Full CSS On Scroll – אם טענת critical בשביל above the fold תוכלו לא לטעון את כל השאר עד שהיוזר יתחיל לגלול. כרגיל, בדקו טוב אם לא שובר משהו.
• Print critical CSS inline – עדיף לעשות את זה. (אם הקריטיקל שלכם ענק זה אולי יגרום לבעיה אבל אז הבעיה שלכם בלי קשר גדולה למה יש לכם כזה קריטיקל גדול?).
• Print full CSS inline – כמו באפשרות שראינו לגבי סקריפטים. בקשה אחת פחות וטעינה של ה css בפוטר. גם בסקריפטים וגם פה אני מעדיף שלא לעשות את זה (אלא אם כן מדובר באמת בקבצים ממש קטנים).
• Separate Styles – אם יש בעיות ב merge אם יש לכם סיבה אחרת כמו הבדלי css מטורפים בין דפים.
• Minify CSS – אם לא עושים במקום אחר (כמו ב Cloudflare) תוכלו לבחור בין basic ל full.
• Bypass CSS Import – לכלול css imports באיחוד.
• Exclude למיניו – אפשרויות החרגה שונות. טיפול פרטני.
• Perload Styles – (גרסת פרו) כמו הסעיף על סקריפטים. הוסיפו סטיילים שצריכים להיות עם preload.

Optimization – Fonts

• Manual Preload Fonts – (גרסת פרו) דלוק. פרילאוד לפונטים. בלי קשר כדאי לעשות טעינה לוקאלית.

Caching

Caching – General

• Enable Caching – ברור שדלוק. 
• Caching Mode – על Disk Cache with Rewrite. הכי מהר מבין האפשרויות. וזה גם מה ש-Swift ממליצים. בנוסף, לטענתם אם אתם בוחרים בשיטה הזאת אין צורך בobject cache כמו Redis.
• Early Loader – דלוק. Swift ממליצים להפעיל אם בחרתם בסעיף הקודם לבצע קאש עם PHP. אני לא בטוח שיש עניין להפעיל אם בחרת ב Disk. אם תפעילו, זה יחייב שימוש בתוסף אחר (לא תצטרכו להתקין משהו, Swift עושה את זה אוטומטית).
• Cache Path – תיקיית הקאש שלכם בסרבר.
• Cache Expiry Mode – אצלי Action Based. אם האתר שלכם מתעדכן, כדאי לבחור את זה כדי ש-Swift ידאג לנקות את הקאש אחרי עדכון פוסט למשל. אם האתר לא מתעדכן תוכלו לבחור Time Based. אם אתם לא בטוחים, עדיף שתבחרו Action Based.
• Clear Cache on Update Post by Page – ריק. אם בחרתם Action Based אין צורך להכניס פה כלום.
• Clear Cache on Update Post by URL – כמו הסעיף הקודם.
• Enable Caching for logged in users – כבוי. אין לי צורך בזה באתר שלי.
• Separate Mobile Device Cache – כבוי. אולי אדליק בהמשך אם אחליט שהבלוג יפעל במובייל רק באמצעות AMP.
• Enable Browser Cache – דלוק. זה ישכתב לכם את ה htaccess כדי לתמוך בקאש בדפדפן.
• Enable Gzip – דלוק.
• Send 304 Header – כבוי. זה אומר ש Swift תכניס בהדר הודעה שהתוכן לא השתנה אבל זה נצרך רק אם לא בחרתם ב-rewriters בהגדרה של caching mode.
• Cache 404 pages – כבוי. אם אתם רואים שמגיעים אצלכם הרבה פעמים ל 404 מאותו url אפשר להפעיל אבל אם תראו בגלל זה המון כתובות לא קשורות בטבלת הקאש כבו את זה להמעיט עומס.
• Enable Dynamic Caching – דלוק. עוד משהו ייחודי ל Swift. הרעיון הוא לאפשר קאש לשאילתות דינאמיות. למשל, לשאילתת חיפוש או אם שאילתה שמחזירה מזג אוויר (אלו באמת סתם דוגמאות שכרגע עלו לי בלי לחשוב הרבה, כל אחד יחוב מה רלוונטי לאתר שלו). קאש רגיל מדלג על דפים אלה אבל אם תאפשרו ואז בשדה Cachable Dynamic Requests תוסיפו לדומה s במקרה של שאילתת חיפוש, יתבצע קאש לכל בקשה של חיפוש על פי הפרמטרים שהתקבלו. זה כדאי? תלוי. אם נמשיך עם הדוגמה של חיפוש, האם מחפשים אצלכם הרבה באתר? האם חשוב לכם שתוצאות החיפוש יופיעו מיד? האם זה שווה את העומס על הקאש (זכרו שלכל שאילתא – קאש) ושוב עזבו חיפוש, זוהי רק דוגמה. אם האתר שלכם לא מאוד דינאמי, נניח בלוג שיש בו רק פוסטים ותמונות, אין כל כך צורך בזה. אם יש לכם הרבה נתונים דינמאיים, שווה ניסיון.
• Cacheable AJAX Actions – דלוק. אם יש לכם ajax וחוששים שמאט אתכם, אפשר לנסות להדליק. תצטרכו להוסיף את שם ה action של ה ajax (את השם של ה- action תוכלו למצוא גם בטאב נטוורק או על ידי חיפוש בקוד או אם רוצים לחפש בצורה רוחבית אז עם תוסף כמו String Locator). אם הפעלתם, וודאו שהפעולה עובדת טוב אחרי הקאש.

Caching – Tweaks

כל מה שתחת הסעיף הזה הוא לגרסת הפרו בלבד.

• Enable Proxy Cache – דלוק. מאפשר להשתמש ב Cloudflare (לדוגמה בגלל ש Cloadflare זה בעצם סוג של reverse proxy) בתצורה של cache everything. כמו דברים נוספים שהזכרנו זה יותר לכאלה שרוצים לנסות דברים. צריך לוודא שכלום לא נהרס, שניקוי קאש באמת עושה את העבודה ושאין לכם אתר ממברשיפ
• Ignore GET parameters – תוכלו להוסיף פה בקשות שאתם רוצים להתעלם מהפרמטרים שלהם כדי שהקאש יעבוד עליהם (אחרת אין קאש לבקשה שכוללת getים). ישנם כאלה שבדיפולט Swift מתעלם מהם כמו fbclid, gclid, ga, utm ועוד ידועים אבל פה תוכלו להוסיף דברים ספציפיים לאתר שלכם.
• שאר הדברים בסעיף זה הם כולם לשיקולכם. אם צריכים עזרה בהגדרות, פנו אלי. אני אוותר על פירוט היתר במקרה זה.

מי שמעוניין בפתרון אחר ל cloudflare cache everything יכול לנסות את התוסף Cloudflare Super Cache. יש עוד כמה תוספים דומים שמתיימרים לעשות את זה. אני אישית עוד לא בדקתי אותם. היום גם יש ל Cloudflare פתרון מובנה לזה אבל עוד לא ניסיתי את זה כי עובד לי מעולה עם Swift.

Caching – Exceptions

קאש זה מעולה אבל תמיד יש תוכן שלא נרצה אותו בקאש, בדיוק בשביל זה יש ב Swift את כל סוגי ההחרגות שתוכלו לבקש.

• Exclude Post Types – הוסיפו פה את כל סוגי הפוסטים שאין לכם צורך שיהיו בקאש. שימו לב, אין הכוונה לפוסטים מסויימים אלא לסוגי פוסטים מסויימים. זה לא נוגע רק למי שיצר Custom Post Types אלא לכל אחד משום שהרבה תוספים יוצרים עבורכם כאלה.
• Exclude Pages – החריגו דפים מהקאש לפי הצורך.
• Exclude URLs – הוסיפו URL’s מסויימים להחרגה. דברים שאפשר להוסיף למשל אלו דפי preview. חשבו על כל הכתובות הספציפיות שאתם לא רוצים שישמרו בקאש. שימו לב, אלו לא בהכרח כתובות של דפים או פוסטים שיצרתם אלא דברים כמו שכתבתי, preview, sitemap, autosave ועוד. אם תרצו להוסיף regex הוסיפו # בהתחלה ובסוף.
• Exclude Content Parts – החריגו דפים על פי תוכן שקיים בהם. אצלי ריק אבל אם יש לכם תוכן מסוים בדף שהוא אינדקציה בשבילכם כדי לא להישמר בקאש, השתמשו בזה.
• Exclude User Agents – לא רלוונטי בשבילי. נותן להחריג דפים על בסיס משתמש מחובר מסוים.
• Exclude Crawlers – כבוי. אם תפעילו, רובוטים שסורקים את האתר יקבלו תמיד את הגרסה האחרונה לא מהקאש.
• Exclude Author Pages – דלוק. לא חושב שיש אנשים שנכנסים לדף הזה…
• Exclude Archive – כבוי. ארכיון דווקא כן נכנסים לפעמים אז שישמר.
• Exclude REST URLs – דלוק. בכל מקרה אין אצלי שימוש בזה.
• Exclude Feed – דלוק. בכל מקרה אין אצלי שימוש בזה.

Caching – Warmup

• Prebuild Cache Automatically – דלוק. יבנה לכם את הקאש אוטומטית לאחר ניקוי (Clear).
• Discover New Pages – מאפשר לגלות דפים חדשים בשביל קאש. למשל דפים שפלאגינים יוצרים לכם. זה יכול להיות נחמד אבל אם מדליקים, וודאו בטבלה שאין לכם מלא דפים לא קשורים. אם יש בודדים כאלה פשוט תעשו להם החרגה אבל אם זה הוסיף מלא זבל, בטלו את האופציה.
• Warmup Table Source – עדיף לבחור Auto ורק אם רואים בעיה (דפים מיותרים או חסרים בטבלת קאש) לשנות למשהו אחר. אם לא בא לכם לשחק עם זה, בחרו sitemap.
• Prebuild Speed – Slow. מומלץ על ידי Swift להגדיר כאיטי בשרתים משותפים.
• Prebuild Author Pages – כבוי. לא בקאש אצלי.
• Prebuild Archive – דלוק.
• Prebuild REST URLs – כבוי. לא בקאש אצלי.
• Prebuild Feed –  כבוי. לא בקאש אצלי.

Caching – Varnish

אני לא משתמש ב-Varnish (חברת האחסון שלי-  SiteGround משתמשת ב-NGINX כ-reverse proxy) אז לא רלוונטי לי. מדובר במנגנון קאש מהיר שיושב בשרת. היכנסו  Varnish Intro כדי לראות יותר עליו או לפוסט שכתבתי על סוגי קאש.

Caching – Appcache

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

Plugins

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

Lazyload Youtube Background – דלוק.

CDN

• Enable CDN – דלוק. שימו לב, הפעילו את זה רק אם מדובר ב CDN אמיתי ולא ב Cloudflare!
• CDN Hostname – תלוי כמובן ב CDN שלכם.
• CDN Hostname for Javascript – ריק. קבצי ה JS שלי לא מגיעים מה CDN שאני משתמש בו.
• Enable CDN on SSL – כבוי. הפעילו רק אם יש לכם hostname אחר ל SSL.

CDN – Cloudflare

• Enable Auto Purge – דלוק. אם אתם משתמשים ב Cloudflare מומלץ להפעיל כדי ש Swift ידע לנקות את הקאש גם שם כשצריך. (בכל מקרה אם נתקלים בבעיה, גשו ונקו בעצמכם)
• Email, API, Host – מלאו לפי הפרטים שלכם.

ב- Cloudflare בשונה מ CDN רגיל, ה- Host יהיה פשוט שם האתר שלכם.

Image Optimizer

אני משתמש ב ShortPixel מדובר באחד הנושאים החשובים ביותר לשיפור מהירות האתר. גם Webp Express מעולה.

DB optimizer

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

Critical Font

רלוונטי רק לגרסה 4 של FA. מאפשר לטעון רק את האייקונים שאתם משתמשים במקום קובץ ענק של פונטים שברובם אתם לא משתמשים. חשוב מאוד. אם אתם משתמשים באלמטור (או תבנית אחרת שטוענת Font Awesome) תצטרכו לחסום את הטעינה. באלמטור תוכלו לעשות את זה כך. וכדי להשתמש ב Critical Fonts תצטרכו להוסיף wp_enqueue_style  עם הנתיב fonts/ swift-performance/ fontawesome/ webfont.css.

עדכון אוגוסט 2020 – האפשרות לא זמינה בגרסאות החדשות.

Plugin Originizaer

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

בעיות ידועות

• ישנה בעיה שהולכת וחוזרת עם URL בעברית. עם האתר שלכם ברובו כזה, עדיף להשתמש בתוסף אחר. זה יכול לעבוד אבל הסיכוי לבעיה גדול יותר.
• מגרסה 3.1 של אלמנטור ישנה התנגשות עם Swift. לא בטוח שההתנגשות תשפיע על האתר כי היא קוראת במקרים מסוימים. בכל מקרה יש פתרון זמני ו Swift מודעים לעניין.

רוצים לשפר עוד יותר?

יש לי באתר הרבה סניפטים שמיועדים לעבוד עם Swift באמצעות קוד (hooks/actions) חפשו אותם.

סיכום

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

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

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

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

השתכנעתם שכדאי לכם להשתמש בתוסף?
שדרגו את מהירות האתר עוד יותר על ידי שימוש בגרסת הפרו!

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