מדריך WPO לאופטימיזציית מהירות האתר שלך

מה זה WPO?

Web Performance Optimization, שאנחנו מכנים WPO, הוא פשוט האופטימיזציה של התהליכים השונים שמשפיעים על איך אתר נטען.

איך למדוד את מהירות הטעינה של אתר?

יש המון כלים למדידת מהירות טעינה. הפופולריים ביותר הם:

• ›

  Google Page Speed

• ›

  Lighthouse

• ›

  GTMetrix

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

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

• ›

  משקל אתר (MB)

• ›

  בקשות

• ›

  זמן תגובת שרת

אם נשפר 3 אזורים אלה, מהירות הטעינה תשתפר ללא תלות במיקום של המשתמש.

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

Google Developer Tools

לפני שנתחיל, אני רוצה להסביר כמה אפשרויות ש-Google מציעה דרך כלי המפתחים שלה. הכלי הזה הוא אחד מהחשובים ביותר לניתוח איך אתר עובד. לחץ קליק ימני על הדף שהדפדפן פתוח ויופיע פאנל עם אפשרויות שונות. נלך ל-Inspect (Ctrl + Shift + I).

ברגע שהכלי הזה פתוח, נלך לאפשרות NETWORK שתמצא בראש. אם נלחץ ENTER שוב בדפדפן, הכלי יראה את הטעינה של המשאבים השונים.

בתחתית התמונה, נוכל לראות את הנתונים שמעניינים אותנו לתצוגה כללית של איך האתר נטען.

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

• ›

  Name: השם של המשאב.

• ›

  Status: קוד התגובה של המשאב (200, 301, 404...)

• ›

  Type: סוג המשאב (script, font, png, jpg, stylesheet...)

• ›

  Initiator: איזה משאב מפעיל את הבקשה.

• ›

  Time: כמה זמן הבקשה לקחה.

• ›

  Waterfall: ייצוג גרפי של זמני הטעינה של משאב.

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

הפעלת רכיבי מידע נוספים כמו Domain, Scheme או Cookies יכולה לעזור במקרים ספציפיים לאתר משאבים שעלולים לגרום לנו לסוג של בעיה, אבל בנקודה הזו נישאר עם אלה שמגיעים מוגדרים מראש.

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

איך לדעת את המשקל של URL ואיך להפחית אותו?

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

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

נתמקד בנתונים בעמודה הימנית, זו שמתייחסת ל-(Page Details), במיוחד ה-Total Page Size.

במבט ראשון, המשקל של האתר הזה הרבה מעל הממוצע, אבל זכור שמה שחשוב זה לא המשקל הכולל של האתר אלא כמה זמן המשקל הזה לוקח להיטען, כי יש משהו שנקרא Lazy Load, תכונה שמעכבת טעינה עד שהמשתמש צריך את המשאב. נדבר על זה בהמשך.

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

אם תסתכל בתחתית, גם 7.5 MB וגם 215 הבקשות מאוד מתקרבים למספרים שדווחו על ידי GTMETRIX. חשוב שתדע מאיפה GTMETRIX מקבל את המידע שלו במקרה שאי פעם תרצה להשתמש בכלי אחר.

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

ה-אפשרות Waterfall מציעה מבט ויזואלי על איך משאבים נטענים, מציגה את ה-URL של המשאב, סטטוס, דומיין ועמודת הגודל. אם נלחץ על העמודה האחרונה הזו זה ממיין משקלים מהגדול לקטן ומהקטן לגדול.

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

אין מפרט רשמי למשקל המקסימלי שתמונה צריכה שיהיה לה, אבל אנחנו ממליצים לא יותר מ-100 KB ואם יש לך את האפשרות (אם אתה משתמש ב-Photoshop יש לך), הגדר את התמונות להיטען בהדרגה כ-JPG והימנע מ-PNG בכל פעם שאתה לא צריך ערוץ Alpha (שקיפות).

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

• ›

  https://imagecompressor.io/compress

• ›

  https://kraken.io/web-interface

גם GTMetrix וגם הכלי של Google מאפשרים לנו לצפות במשאבים לפי סוג, כלומר, רק תמונות, סקריפטים, CSS...

זה שימושי למבט רחב יותר על איפה לעבוד. ב-URL הזה, תמונות מהוות 4 MB מתוך 7.2 MB, אז חלק גדול מבעיית המשקל נמצא שם. עם זאת, יש משאבים אחרים שבולטים ככבדים מאוד עבור הסוג שלהם, כמו קובץ CSS מעל 700 KB וסקריפט מעל 300 KB.

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

במקרה הזה אנחנו רואים קובץ CSS מאוד גדול. אם המעצב יצר CSS מעל 700 KB, אופטימיזציה של אותו קובץ ספציפי תהיה קשה.

מה אנחנו יכולים לעשות כדי להפחית את המשקל של הקבצים האלה?

Minify (CSS, JS ו-HTML)

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

כלים למיניפוק קבצים

• ›

  HTML Minifier http://kangax.github.io/html-minifier/

• ›

  CSS Nano https://cssnano.co/

• ›

  Uglify http://lisperator.net/uglifyjs/

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

אישית אני אוהב להשתמש באחד חינמי לחלוטין, Autoptimize ובאחד בתשלום, WP Rocket.

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

מיניפוק עם WP Rocket

החלק הזה לא מורכב. אנחנו פשוט הולכים לטאב אופטימיזציית הקבצים ומסמנים את הקופסה למניפוק HTML. ב-WP Rocket האפשרות הזו חוזרת למטה לקבצי CSS ו-JS. עדיין, אני ממליץ להפעיל את הקופסה הזו ולבדוק. חזור על האפשרות הזו אחת אחרי השנייה, מכיוון שאם משהו נכשל יהיה קל יותר לאתר את הבעיה.

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

איך לנקות את מטמון הדפדפן?

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

דרך נוספת היא דרך הדפדפן, ברגע ש-Google Developer Tools מופעל (Ctrl + Shift + I).

לחץ קליק ימני על החץ "טעינת דף מחדש" ובחר "ריקון מטמון וטעינה מחדש קשה".

מיניפוק עם Autoptimize

עם Autoptimize, פעולת optimize היא מה שמבצע מיניפיקציה, עם המוזרות של הצעת אפשרות לשמור על תגובות HTML. התגובות האלה בדרך כלל מתווספות על ידי מפתחים כדי לשמור מידע שעשוי להיות שימושי בעתיד.

כדי לבדוק שהאופטימיזציה הזו נכנסה לתוקף, נלך לקוד המקור של ה-URL וצריכים לראות משהו כזה:

הקוד הופך לבלתי קריא אבל הפונקציונליות שלו זהה.

האפשרויות האלה חוזרות באותה דרך ב-WP Rocket וב-Autoptimize לקבצי CSS ו-JS. כפי שציינתי קודם, אני לא ממליץ לבצע אופטימיזציה לכול בבת אחת, אלא 1 על 1. התוספים האלה שומרים עותקים של הקבצים הממוניפקים, אז ניתן לחזור למקור על ידי ביטול סימון התיבה המתאימה.

כדי להמשיך להפחית את משקל הדף יש לנו 2 אפשרויות נוספות:

• ›

  הסר או הפחת תוספים שמוסיפים CSS או JS לטעינה.

• ›

  הסר או חתוך קוד לא בשימוש מקובץ ה-CSS.

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

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

זמן טעינה לעומת זמן תגובה

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

אבל בוא נלך צעד אחר צעד.

מה זה בקשה?

בקשה, או HTTP Request, היא קריאה שמבוצעת מהלקוח לשרת לבקש משאב נתון. בקשות יכולות לפגוע בשרתים שונים.

בקשות יכולות להיות או HTTP או HTTPS. אם נסתכל על המבנה של בקשה, נוכל לנתח איפה העיכוב בזמן קורה.

ניתוח של זמן בקשת HTTP

בוא נפרק את מה שאנחנו רואים בתרשים התזמון הזה.

• ›

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

• ›

  DNS Lookup: הדפדפן מפענח את כתובת ה-IP של הבקשה.

• ›

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

• ›

  שליחה: בקשת המשאב נשלחת.

• ›

  המתנה: זה הזמן שהשרת לוקח לפענח בקשה ולשלוח תגובה; אם זה ארוך, יש בעיה בשרת.

• ›

  קבלה: קבלת המשאב.

בקשת HTTPS מוסיפה עוד שלב אחד, מוצג כאן.

שני צילומי המסך האלה שייכים לשני אתרים שונים, אחד לא מותאם (HTTP Request) ואחד מותאם (HTTPS Request).

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

בקשות שרת: איך נוכל להפחית אותן?

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

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

שילוב CSS ו-JS

פעולה פופולרית נוספת בעת אופטימיזציה לדף אינטרנט היא שילוב משאבי CSS ו-JS, אבל מה זה אומר?

המטרה של השילוב היא להפחית בקשות במחיר של הגדלת משקל הקובץ. שילוב אומר איחוד של משאבי ה-CSS או JS השונים לתוך אחד יחיד.

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

האידיאל הוא לשלב תוך החזקת שרת טוב, אז אנחנו מנצחים בשני הצדדים.

שילוב משאבים עם WP Rocket ו-Autoptimize

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

ב-WP Rocket האפשרויות לשילוב CSS ו-JS זהות; הפאנלים כמעט זהים. כפי שאנחנו רואים בתמונה, יש קופסה להוספת הנתיב של הקבצים שאנחנו לא רוצים לשלב.

מתחת לתיבת הסימון, אנחנו גם רואים הערה על אי שימוש באפשרות השילוב אם אנחנו משתמשים ב-HTTP/2. המאמר הזה מסביר עוד על HTTP/2.

Autoptimize מציע יותר אפשרויות לעבוד עם CSS ולהפחית בקשות. באפשרות שאני מסמן, הוא משלב ונותן לך אזהרה על ההשפעה שזה עשוי להיות לזה, אבל בסופו של דבר זה תמיד יחסי.

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

קונפיגורציית מטמון

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

Autoptimize ו-WP Rocket מבצעים פעולות מטמון, אבל WP Rocket נותן לך עוד כמה אפשרויות. ראוי לציין שתוספים הפכו את האופטימיזציה הזו למשהו פשוט יותר: בקושי יש לך כמה אפשרויות והתהליך מהיר ולא כואב.

כפי שאתה רואה, WP Rocket מאפשר לך לעבוד על 4 דברים:

• ›

  אפשר caching למכשירי מובייל.

• ›

  שמור קבצים בנפרד למכשירי מובייל.

• ›

  אפשר caching למשתמשים מחוברים.

• ›

  ציין את הזמן לניקוי המטמון.

זה תלוי בכל פרויקט איזו אפשרות לבחור, אבל עם כל זה בחשבון העצה שלי היא:

• ›

  מטמון מובייל תמיד, מכיוון שלמרות שרוב האתרים responsive, יש תוכן שאולי יש לך במובייל אבל לא בדסקטופ.

• ›

  קבצים בנפרד.

• ›

  אין מטמון למשתמשים מחוברים, מעל הכול כי אם אני עושה עריכות אני לא רוצה caching.

• ›

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

Lazyload

תכונת lazyload עוזרת להציג משאבים (תמונות ו-Iframes) כשהמשתמש צריך אותם; כלומר, הדפדפן לא טוען את המשאבים האלה עד שהמשתמש גולל אליהם. התכונה הזו מיושמת בהרבה תוספים ואפילו מגיעה מקונפגת מראש בכמה ערכות נושא של WordPress. מגרסת Chrome 76 ואילך, היא אפילו מגיעה באופן מקורי בדפדפן.

זה אומר שעל ידי הוספת תכונת loading="lazy", הדפדפן כבר מפרש את הטעינה העצלנית של התמונה, אבל כמובן לא כל דפדפן יפרש את זה, אז אני ממליץ להמשיך להשתמש בתוסף. הנה וידאו שנמשך מ-web.dev שמראה דוגמה למה זה lazy loading של תמונות.

אופטימיזציית Iframe

אם אנחנו משתמשים ב-iframes להטמיע תוכן מאתרים אחרים, יש לנו שתי פעולות שאנחנו יכולים להשתמש בהן כדי לשפר את הטעינה שלנו.

• ›

  טעינה עצלנית דרך פונקציית lazyload

• ›

  או החלפת ה-iframe בתמונה עד שהמשתמש לוחץ עליו.

גם האפשרות הראשונה וגם השנייה ניתנות להפעלה דרך, שוב, התוסף שלנו לעבודה WP Rocket.

ל-Autoptimize אין את החלק הזה אבל מציע התקנה של תוסף משלים לעשות את זה https://wordpress.org/plugins/wp-youtube-lyte/

טעינה מושהית של קבצי JS עם Defer או Async

קבצי JS הם אחד מאשמי מה שביקורות מהירות מכנות render blocking של דף. זה קורה כש, בזמן rendering, הדפדפן עוצר להוריד קובץ JS ולהפעיל אותו. המטרה של אופטימיזציית WPO היא לספק מידע למשתמש בהקדם האפשרי, ולכן זה נחשב לחסימה, כי כלום לא מוצג עד שה-JS שהורד מבצע.

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

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

ב-SEO Alive אנחנו משתמשים בתוסף Pre Party Resource Hints, שמאפשר לך לבחור אילו קבצים ואיזו שיטת טעינה אתה רוצה להחיל. נפלא!

מה ההבדל בין Defer ל-Async?

למרות ששתי התכונות יש להן מטרה דומה, מניעת ה-DOM HTML interpretation מלהיעצר על ידי ה-JS, יש הבדל בולט בין השתיים.

עם תכונת Async המשאב מורד מבלי לעצור טעינת HTML, אבל ברגע שהורד, טעינת HTML מושהית כדי לבצע את ה-JS; עם תכונת defer המשאב גם מורד במקביל לטעינת HTML, אבל הוא רץ כשהטעינה מסיימת, אז אין חסימה על ידי הסקריפט.

בעניין הזה יש הבדלים בין WP Rocket ו-Autoptimize. WP Rocket עושה החלטות הרבה יותר קלות עבורך ופועל בדרך חצי-אוטומטית כדי לשמור על JS מלחסום rendering; ב-Autoptimize, מצד שני, אתה יכול רק להחליף את אפשרות ה-Async.

ב-Autoptimize, תחת הטאב נוסף יש לנו את האפשרות הזו להוסיף את קבצי ה-JS שאנחנו רוצים לטעון עם Async, אבל לגמישות גדולה יותר הם ממליצים על תוסף משלים אחר, "Async Javascript".

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

האפשרות הזו נמצאת באותו טאב אופטימיזציית קבצים.

מה זה CDN ואיך זה יכול לעזור לנו?

CDN הוא מה שמוכר כ-content delivery network. ה-CDN אחראי על שמירת חלק מהמידע והמשאבים כדי להקל על עומס השרת על המשאבים האלה ולהגיב טוב יותר לטעינה. ל-CDNs יש גם פונקציית עותק גיאוגרפי, כדי לשמור את המשאב זמין בנקודות שונות ולהגיש אותו למשתמש ללא תלות מאיפה הוא מתחבר. בדרך כלל הסוג הזה של שירות משמש לקבצים כבדים כמו תמונות וסרטונים.

הרשמה לשירות הזה חשובה כשיש לנו אתרים עם הרבה תעבורה, אם כי לא צריך לבטל אותה לאתרים עם מעט תעבורה.

פעולות אחרות שיביאו לנו עוד קצת שיפור

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

אופטימיזציית פונט

אופטימיזציית פונט ניתנת לביצוע דרך תוספים או ידנית על ידי עריכה ואופטימיזציה של ה-CSS. האידיאל יהיה רק לקרוא לפונט שאתה הולך להשתמש ולא, כפי שקורה בהרבה מקרים, להוריד קובץ עם כל ה-Google Fonts.

ל-Autoptimize יש אפשרות לעבוד על פונטים.

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

כפי שאתה רואה, ממש אחרי אפשרויות Google Fonts יש לנו "הסר Emoji", שיחסוך לנו בקשה לשרת. הפונקציה שלו היא פשוט להמיר סמלים שמייצגים אמוג'י לאייקון.

WP Rocket גם מאפשר לנו לכבות את האמוג'ים האלה וגם מציע את האפשרות למנוע מתוכן להיות מוטמע באתרי צד שלישי.

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

אני מקווה שמדריך אופטימיזציית WPO זה מועיל ושתוכל ליישם אותו לפרויקטים שלך או ללקוחות שלך.