איך לשפר ביצועים בוורדפרס – אופטימיזציית אתר וורדפרס

איך לגרום לאתר איטי, להיות מהיר כמו טיל. שיפור ביצועים בוורדפרס יעזור ל CRO וגם יהיה גורם משפר לדירוג בגוגל - SERP. במאמר זה תקראו כל מה שצריך לדעת על אופטימיזציית אתר וורדפרס.
Optimize Performance of Wordpress Website

תוכן עניינים

שיפור ביצועים בוורדפרס – ההתחלה

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

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

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

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

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

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

האם מהירות באמת חשובה

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

ראשית, אם לכם זה חשוב, פשוט תעשו את זה. אבל הכוונה בשאלה היתה האם לגוגל זה חשוב? יש כאלה שיגידו לכם "ברור! אם האתר שלכם יהיה איטי זה יפגע לכם בדירוג החיפוש של גוגל (SERP)." גוגל בעצמם הודיעו שהם אכן מתחשבים במהירות. אבל האמת היא שזה לא כזה משמעותי.

אני רוצה להדגיש, אם מהירות לא הייתה חשובה לי, לא הייתי עובד על זה קשה ולא כותב את המאמר הזה. העניין הוא שלגוגל זה חשוב, נניח כמו שחשוב להם שהאתר שלכם יהיה HTTPS. בטח חלקכם יגידו כאן, "נכון, גם זה חשוב להם זה ידוע! בלי SSL ה SERP יפגע", ואני אענה, כן זה חשוב, בערך כמו שביצועי האתר שלכם חשובים להם. 

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

וכדי שלא תחשבו שסתם הבאתי את שתי הדוגמאות האלה, הנה ציוץ של Gary Illyes מגוגל שאומר בדיוק את זה בהקשר של חשיבות מהירות האתר.

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

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

Gary Illyes Twitter
Gary Illyes מתייחס לחשיבות המהירות על SERP

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

למה מהירות בכל זאת חשובה

במילה אחת –  CRO. ראשי תיבות של Conversion Rate Optimization.

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

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

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

יש גם כלי נחמד מאוד של גוגל שיגיד לכם כמה תרוויחו אם תגרמו לאתר שלכם להיות מהיר יותר. ממליץ מאוד לעשות את הסימולציה.

מבחינתי? אני פשוט רוצה אתר מהיר, בשבילי. אני בונה משהו, אני רוצה שהוא יהיה טוב. גם בלי קשר ל CRO או SERP.

איך מודדים אם אתר מהיר

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

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

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

בקרוב אסיים לכתוב מדריכים מפורטים על GTmetrix , Google Page Speed ו- WebpageTest ועוד כלים שיסבירו בדיוק איך ומה לבדוק.

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

בגלל שאנחנו בכל זאת צריכים מדד כלשהו כדי לדעת אם באמת שיפרנו את המהירות, אנחנו נסתכל על שני מדדים. האחד נקרא TTFB שזהו Time to First Byte – כלומר כמה זמן לקח עד שהבית הראשון הגיע. זה כולל את כל שלבי ההתחברות לשרת שלנו, את עבודת הבקאנד, ושליחת הבתים אלינו. זכרו טוב שזה הפרמטר הכי חשוב מבחינתנו לשפר. והשני הוא DOM Loaded (לפעמים משתמשים גם בשמות אחרים) – כלומר, כמה זמן לקח אז שהדפדפן גמר לרנדר את הדף והוא מוכן לאינטרקציה. שימו לב שהפרמטר השני הוא לא Fully Loaded ואני בכוונה לא מתייחס אליו. מכיוון שברגע שהגולש יכול לבצע אינטרקציה עם הדף ואנחנו ברקע עושים עוד דברים, מבחינתנו זה בסדר, גם אם מבחינת ציון של אתר זה משפיע.

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

הוראות לקריאת המדריך

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

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

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

מה חשוב לשיפור מהירות האתר

חברת אחסון

אחת ההחלטות הראשונות שקשורות לביצועי האתר שלכם צריכה להיות בחירת חברת אחסון נכונה. דבר זה ישפיע על מדד ה TTFB – Time to First Byte, ועל ביצועי האתר שלכם במיוחד בעומס אבל לא רק. חוב במיוחד בשרת משותף.

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

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

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

Web Server – לא תמיד זה משהו שתוכלו לשנות (שרת משותף) לרוב זה יהיה Nginx, Lite Speed או Apache. מבדיקות רבות שעשו Apache במקום האחרון מבין השלושה כשבין LiteSpeed ל NGINX יש תחרות וכתלות בסוג האתר אחד מהם יהיה טוב יותר. אם תוכלו לבחור, ממליץ על LiteSpeed.
ב-SiteGround, שם האתר שלי מאוחסן, השרת הוא Apache וניתן להשתמש ב-Nginx כ- reverse proxy.

גרסת PHP – חשוב מאוד, וודאו שהחברה עובדת עם הגרסה היציבה העדכנית ביותר.

מטמון – בדקו אם החברה מציעה מטמון ברמת השרת ואלו סוגי מטמון.

דחיסה – חשוב מאוד, וודאו שיש דחיסת Brotli או לפחות Gzip

תמיכה בפרוטוקולי HTTP – חשוב מאוד, וודאו שיש תמיכה ב HTTP/2 או HTTP/3 כשיכנס כסטנדרט.

כמה חברות אחסון מומלצות לדוגמה

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

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

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

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

אילו חברות לא מומלצות?

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

תבנית ו- Page Builder

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

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

תבניות שיש להן גרסה חינמית מומלצת:

OceanWP, ,AstraGeneratePress

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

Page Builders:

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

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

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

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

ניתן לקרוא על השוואת ביצועים עשיתי לרוב ה Page Builders הקיימים.

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

תוספים

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

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

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

  1. העדיפו תוסף שעושה רק את העבודה שאתם צריכים ממנו ואל תתפתו לתוספים עם הרבה אפשרויות.
  2. בחרו רק תוספים עם ביקורות טובות גם בריפו הרשמי של וורדפרס וגם בפורומים/פייסבוק.
  3. אם יש לכם תוספים לא בשימוש, מחקו אותם.
  4. תוספים שמאפשרים לכבות פיצ'רים לא בשימוש, כבו אותם. השתמשו רק במה שנדרש לכם.
  5. בדקו לפני שתבחרו תוסף מסוים. קראו סקירות, בדקו ברדיט, בקבוצות פייסבוק, אם יש גיטאהב מה טוב.
  6. התקנתם? עכשיו בדקו ב Chrome Developer Tools וב Query Monitor מה התוסף שלכם עושה.
  7. הזהרו מתוספים שטוענים את עצמם בצורה רחבה בכל האתר. יתכן והתקנת פלאגין לצורך מאוד מסוים בדף אחד באתר, אך הוא טוען את עצמו בכל דף באתר!

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

תמונות – אחד הדברים הכי חשובים. דחסו, העדיפו שימוש ב webp ברוב המקרים והתאימו מידות. במקרה שיש לכם תמונות שלא מוצגות ב viewport, שקלו להשתמש ב"טעינה מאוחרת" (Lazy Load) אבל עשו זאת בצורה שלא תגרע מנוחות המשתמש (אתם מכירים בטח אתרים שהתמונה מוצגת בצורה מטושטשת גם אחרי שכבר גללנו אליה).

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

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

Font Awesome – צמצמו מאוד את גודל הטעינה וטענו לוקאלית רק את הפונטים שאתם משתמשים בהם.

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

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

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

סקריפטים – השתמשו ב defer או async או העבירו לfooter. אם אפשר טענו באיחור (אחרי כמה שניות של של Idle). אם אתם לא בטוחים מה הכי טוב לכם פשוט השתמשו ב defer והשאירו את הסקירפט בהדר. ככה זה גם לא יחסום רינדור וגם יעשה fetch ברקע בעת הרינדור.

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

שימו לב לתוספים מועדים לעיכובים כמו תוספי social share למיניהם, מסנג'ר, iframes כמו גוגל מאפ ועוד. אם אתם לא חייבים כמובן כדאי לא להתקין. במקרה שכן, דאגו לטעון באיחור.

Prefecth – לפעמים שווה לעשות את זה לכתובות שאתם יודעים שתצטרכו. זה יעשה DNS resolve ויחסוך את הזמן רשת. זה ממש לא הרבה וזו לא תהיה הבעיה העיקרית שלכם אבל זה יקרה ברקע אז אם עוזר, למה לא?

Preconect – שלב אחד מעבר ל-Prefecth. כלומר לא רק resolve אלא התחברות. יכול להיות יעיל למשל לפונטים או גוגל אנליטיקס.

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

(יכולים להיות שמות אחרים לשלושת הסעיפים האלה אבל הכוונה היא זהה).

ביטול יכולות מובנות של וורדפרס שלא בשימוש – RSS, Gravatar, Pingback ועוד. קראו את הפוסט שלי על ביטול יכולות וורדפרס.

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

שינוי קבצי CSS או JS – הכוונה לכל אחד מהשיטות שמשנות קבצים אלו critical css, inline, merge, minify– זה יכול לעזור אבל אל תתפתו להגזים עם זה. minify לכל הקבצים או inline לדברים מסוימים אין בעיה. אבל merge ו-critical css יכולים לפעמים לשבור לכם את האתר. לכן קודם תראו אם יש לכם בעיה בכלל ורק במקרים שממש חייב עשו זאת בזהירות ובדקו את כל הדפים באתר שלכם (אחרי שניקיתם קאש כמובן) לוודא שתקינים.

מה שכן מומלץ זה להבין באלו משאבים לא משתמשים והם סתם נטענים או כאלה שמשתמשים אבל טוענים 30 ק"ב בשביל שורת css (תוכלו לעשות זאת באמצעות לשונית cover בכרום) ואז אותם לא לטעון בעמודים הרלוונטים ואם יש צורך בחלק מה css הכניסו אותו בצורה אחרת.

אם אתם רוצים לעשות את זה בצורה רוחבית לכל האתר, יש שירותים שעושים את זה בתשלום, חפשו ברשת remove unused css.
ישנו תוסף קאש וביצועים חדש בשם Flying Press שהושק בתחילת אוגוסט 2020 והוא מתיימר לעשות את העבודה, שווה לנסות אותו. (המפתח הוא אותו בחור של שאר תוספי ה Flying שהזכרתי במאמר הזה).

בכל מקרה שתדעו שאם האתר שלכם בנוי עם Page builder ויש בו שימוש במגוון תוספים, אז בלי עבודה אינטנסיבית על critical css ועל קבצי js שחוסמים רינדור, אין לכם סיכוי לקבל ציון טוב מאוד ב google page speed במובייל כי זאת הבעיה הכי גדולה מה שאתם מכירים כ eliminate render-blocking resources.

CDN – אני משתמש רק ב- Cloudflre בגלל שהוא חינמי ותכלס מספיק לי. אבל יש היגיון בשימוש באחד נוסף כמו BunnyCDN או Stack Path. תלוי בצרכים שלכם, איפה אתם מאוחסנים ואיך אתם מאפטמים את מנגנוני הקאש שלכם.

Cloudflre הוא לא בדיוק CDN במובן הרגיל אבל הוא משמש כ-reverse proxy ולכן אם זה מיותר לכם תוכלו להשתמש רק בשביל DNS ותוספת אבטחה לאתר אבל אם תרצו תוכלו גם לנצל את היותו פרוקסי ולהשתמש אפילו ב- full page cache.

Page Cache – מה שצריך להיות במטמון וודאו ששם. דפים שאין צורך אל תכניסו, זה סתם יגרום לתהליך בניית הקאש להיות ארוך יותר וינצל יותר משאבים.
ניתן לעשות קאש לכל הדף ממש כולל HTML ולהחזירו מ- Cloudflare. אם האתר שלכם לא ממש סטטי זה מסוכן. אם הוא כן, נסו לעשות זאת, זה ישפר מהירות מאוד. אני מעדיף לעשות הכל ללא תוספים מיותרים אבל ספציפית לזה יש תוסף מעניין שיכול לעזור. WP Cloudflare Super Page Cache. או השתמשו ב- Swift Performnce Pro עם הגדרה של Proxy.

מטמון – קאש

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

  1. Swift Performance – גרסת חינמית מעולה וגרסה בתשלום הוגן ממש עוד יותר מעולה.
  2. WP Rocket – בתשלום יחסית גבוה אבל עושה את העבודה.

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

אם אתם משתמשים ב-Swift, לא מומלץ להשתמש במקביל בקאשים של ה reverse proxy של SiteGround. הם משתמשים ב NGINX ויש להם גם  Memcached אבל לפחות עד גרסה 2.1.6 של Swift התמיכה לא רשמית ולכן יכולות להיגרם תקלות. מה שאומר תכלס אם משתמשים ב- Swift צריך לבטל את כל הקאש של SiteGround. מניסיון, זה בסדר, אתם תקבלו ביצועים מעולים (לפחות במקרה של האתר שלי, אני לא יכול להתחייב מה יהיה באתר אחר אבל מאמין שהתוצאה תהיה זהה).

קאש דינאמי – אם יש לכם אפשרות השתמשו בקאש גם בשביל שאילתות דינאמיות וקריאות ajax (עם Swift זה קל).

ניקוי נכסים

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

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

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

מה שכן חייבים זה לנקות שורות מיותרות ב- option table שמוגדרות כ autoloads.

חשוב לגבות את ה-DB לפני עבודה עליו!


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

איך תגרמו לאתר שלכם להיות מהיר

שרת

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

הגדרות שרת – לא משהו מיוחד כי זה שרת שיתופי. הפעלת SSL, הפעלת CDN (לא דרך Site Ground) וביטול הקאש שלהם. והגדרות htaccess שונות. כתלות בשרת שלכם, תוכלו אולי להפעיל דברים כמו memcached, redis ועוד מודולים שונים שעוזרים לאופטימיזציה.

CDN

משתמש ב Cloudflare בתוכנית החינמית. יש לו אינטגרציה בתוך SiteGround. זה מצד אחד נוח במיוחד לכאלה שלא טכניים מדי אבל מצד שני מגביל כאלה שרוצים לשנות הגדרות ה-DNS נשלטות מתוך SiteGround ולא מתוך Cloudflre. לכן מומלץ להתחבר ל cloudflare לא דרך siteground.

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

היכנסו כדי לקרוא איך להגדיר את Cloudflare באופן אופטימאלי.

CDN אחר (או בנוסף) ששווה לשקול הוא Bunny CDN. יש כמובן עוד וחלקם אולי טובים יותר אבל יקרים. היתרון של Bunny חוץ מזה שהוא טוב, שהוא גם ממש זול. תוכלו להשתמש ב Bunny בנוסף ל Cloudflare כך שממנו תשיגו את המטרה הרגילה של CDN – מהירות גישה וקאש – ומ- Cloudflare את הדברים האחרים.

אם תשתמשו ב-Cloudflare גם כ reverse proxy תוכלו להינות מ full page cache ברמת cloudflare. פחות מומלץ לאתרי ווקומרס לפחות כל עוד אתם בתוכנית החינמית של cloudflare.

תוספים לשיפור ביצועים

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

Swift Performance Lite

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

אני ממליץ על Swift Performance Pro אבל גם הגרסה החינמית תתן לכם שיפור מדהים.

Asset Cleanup

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

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

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

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

את השינויים הגורפים תוכלו לראות ב- BULK CHANGES שבהגדרות התוסף.

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

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

כדי לדעת בטוח אם באמת צריך אותו או לא, כנסו ל Developer Tools ב Chrome ושם לחצו על השלוש נקודות בצד ימין למעלה ולחצו על More Tools -> Coverage. כעת לחצו על כפתור הריענון וחכו לדוח. תראו שליד כל CSS או JS שנטען יש את גודלו וכמה ממנו באמת היה בשימוש. כל שורה שרואים ש-100 אחוז ממנה לא היה בשימוש, ניתן להסיר.

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

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

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

בנוסף לבדיקה בעיניים שהכל תקין, בדקו גם פונקציונאליות (חיפוש, pageination) וגם שגיאות ב developer tools.

ניתן לעבוד עם Asset Cleanup במצב Test כך שינויים שלכם לא יגיעו למשתמשים הרגילים אלא רק לכם שמחוברים כאדמין.

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

לסיכום

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

ShortPixel Adaptive Images

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

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

התוסף הזה משלב את כל יכולות הכיווץ תמונה + שירות CDN לשליחת התמונות + תמיכה בשליחת webp + Lazyloading שעובד לא רע + התאמת גודל תמונות + תמיכה בתמונות רקע (רוב התוספים לא תומכים בזה). בקיצור התוסף המושלם לכל מה שצריך בענייני תמונות.

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

קראו מה לעשות במקרה שלפני זה השתמשתם בתוסף השני שלהם (SPIO) או אם התמונות שלכם כבר מכווצות  כ lossy. 
I already used SPIO for image optimization, what settings should I use with SPAI?

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

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

סיכום

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

תוספים נוספים לשיפור ביצועים

Flying Scripts – תוסף שמאפשר לאחר טעינה של JS בצורה חכמה כולל timeout. הוסיפו את הסקריפטים בהגדרות התוסף ותהנו.

Flying Images – אם תשתמשו ב SPAI אז אין צורך בו אבל אם הייתי צריך Lazyloading לתמונות ובחינם, הייתי משתמש בו.

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

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

WP Sweep – חשוב לגבה את ה DB לפני שנוגעים. אל תמחקו דברים שאתם לא יודעים מהם.

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

Google Fonts – ביטול טעינת גוגל פונטס וטעינת פונטים מקומית במקום משרתי גוגל.

Font Awesome – גם פה יש אפשרות לבטל את הטעינה של כל הספריה ולטעון לוקלאית רק מה שצריך.  כתבתי מדריך איך לעשות את זה. אם אתם משתמשים ב Swift וב FA גרסה 4, תוכלו לעשות את זה דרכו. תצטרכו לבטל את הטעינה של FA של אלמנטור.

ביטול יכולות מובנות של אלמנטור –  מומלץ מאוד לעבור על המדריך המלא שכתבתי בבלוג לשיפור מהירות של אלמנטור.

DB – חוץ ממה שכבר הזכרתי עם WP Sweep, תהיו חייבים פעם אחת לעשות עבודה קצת ידנית כדי לנקות את wp_option מכל ה autoload המיותרים. אם אתם פוחדים לגעת ב DB שלכם, דלגו על הסעיף הזה. אחרת, גבו את ה DB, כנסו לאתר של wpjohnny למדריך קצר ופשוט על איך לעשות את זה.

מה עוד אפשר לעשות? כולל שימוש בקוד

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

טעינת נכסים עם תנאי – כבר הזכרנו שיש תוספים ממש לא יעילים שטוענים את עצמם בכל מקום ללא צורך. לפעמים אתם לא רוצים לבטל את הטעינה שלהם לגמרי עם Asset Cleanup אלא לטעון אותם רק במקרה מסוים. בשביל זה אתם יכולים לשנות את קוד התוסף עצמו (רעיון לא טוב אם תעדכנו אותן בהמשך) או לכתוב קוד בקובץ functions.php של התבנית שלכם.

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

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

טעינת סקריפטים בפוטר – אם רוצים להעביר סקריפט מסוים לפוטר, אפשר למצוא את ההוספה שלו ולהעביר true בפרמטר של הפוטר. אופציה אחרת היא להעביר את כל הסקריפטים מהheader ל footer. שימו לב שדבר זה יכול לשבור דברים באתר.

defer\async scripts – באמצעות פילטר תוכלו להגדיר על כל סקריפט (או באופן רוחבי) אם לטעון אותו בתוספת המילה defer (עיכוב בהרצה) או async (הרצה אסינכרונית). ההבדל ש defer לא יחסום פרסינג כי יתבצע בסוף והוא יתבצע לפי סדר הסקריפטים בhtml לעומת async שאמנם לא חוסם רינדור אבל יכול להתבצע בעת הפרסינג ואין סדר מובטח.

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

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

כלים לבדיקות הביצועים

בהמשך אעלה פוסט מסודר על כל הכלים שרשומים פה ועל עוד הרבה.

  1. WebpageTest, GTmetrixSitespeed bot
  2. Chrome Developer Tools
  3. Query Monitor
  4. KeyCDN Performance Tools
  5. DNS perf

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

שיפורי מהירות באמצעות קוד

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

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

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

סיכום

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

שיפור מהירות וביצועים של אתרים באינטרנט

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

0 0 דירוגים
דרג את הפוסט

תוכן עניינים

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

הרשמה
Notify of
6 תגובות
חדש ביותר
הישן ביותר הכי הרבה דירוגים
Inline Feedbacks
הצג את כל התגובות

גם הפוסטים הבאים יעניינו אותך

6
0
אשמח לשמוע את דעתכם, מוזמנים להשאיר תגובהx