קידום אתרים » קידום אתרים בגוגל » אופטימיזציה לקוד האתר – איך ליצור עמודים סופר מהירים?
שיפור זמן טעינת עמודים

אופטימיזציה לקוד האתר – איך ליצור עמודים סופר מהירים?

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

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

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

  1. הגורמים לזמני טעינה ארוכים
    1. מספר קריאות HTTP רב יותר ממה שהעמוד אמור לבקש
      1. צמצום מספר הקבצים המוטמעים בדף
      2. שימוש בטכניקות CSS
      3. הוספת Expires or a Cache-Control Header לקבצים הסטטיים
    2. ארכיטקטורת HTML שגוייה
      1. משקל דף גדול וכבד
      2. קוד אינלייני
      3. אלמנטי HTML המקפיאים את טעינת הדף
      4. תמונות ללא גדלים
      5. קבצי הJS נקראים לפני קבצי ה-CSS
    3. CSS יעיל
    4. אופטימיזציית JavaScript
  2. כלים וספרים מומלצים בנושא אופטימיזציית צד לקוח
  3. סיכום ומסקנות

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

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

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

למה שהעמודים שלי יטענו לאט? הרי בניתי אותם בדיבים…

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

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

הגורמים לזמני טעינה ארוכים

1. מספר קריאות HTTP רב יותר ממה שהעמוד אמור לבקש

מהי HTTP Request?

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

כעת, אם בעמוד מסוים יש 10 קבצי CSS & JS, ועוד 50 תמונות (אם אלו תמונות רקע בCSS או תמונות המוטמעות בדף עצמו), ועוד קובץ favicon, ועוד אולי עוד כמה וכמה קבצים המוטמעים בעמוד והרי לכם קיבלנו משהו כמו 60 http request.

פתרון:

  • צמצום מספר הקבצים המוטמעים בדף.
  • שימוש בטכניקות CSS.
  • הוספת Expires or a Cache-Control Header לקבצים הסטטיים.

צמצום מספר הקבצים המוטמעים בדף

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

לקריאה נוספת: Google's page speed: Combine external JavaScript

שימוש בטכניקות CSS

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

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

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

לוגו עמוד תוצאות החיפוש Google.com

שימו לב מה גוגל עשו בתמונה שמשמאל. הם באו ואיחדו את אייקוני הממשק שלהם לתמונה אחת בפורמט png השוקלת KB 5.27. זהו. זהו כל משקל הקובץ ובמקום 27 תמונות נפרדות יש לנו כעת קובץ אחד שנטען פעם בודדת, משרת ומאיץ את זמן הטעינה של יותר מעמוד אחד.

מי יכול לומר לנו אילו אפליקציות מופיעות בתמונה? 🙂

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

לקריאה נוספת: CSS Sprites: How Yahoo.com and AOL.com Improve Web Performance

הוספת Expires or a Cache-Control Header לקבצים הסטטיים

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

יאהו מהווים דוגמה ומופת בכל מה שקשור לאופטימיזציית צד לקוח (עוד עליהם בהמשך מאמר זה), והחברים הנ"ל עושים דבר מאוד פשוט – לכל הקבצים הסטטיים שלהם – JS, CSS & Images הם מעניקים http-header שאומר – תאריך תפוגתי לעולם לא פג. ואז מה קורה? הדפדפן, לאחר שטען את הקובץ למטמונו לעולם לא יבקש בשנית את הקובץ. לעולם לא ייגש לשרת וישאל- האם הקובץ השתנה. האם יש לי צורך לעדכנו. הוא פשוט יטען את הקובץ מהמטמון וזהו.

יאהו צמצמו את כמות ה-requests שלהם פי 6
טבלת הסטטיסטיקות של תוסף Yslow לפיירפוקס, אשר מציג את העובדה ש- Developer.Yahoo.com הצליחו לצמצם את מספר קריאות הHTTP שלהם מ24 ל-4 בלבד (פי 6!)

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

לקריאה נוספת:

2. ארכיטקטורת HTML שגוייה

איך עמוד נולד?

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

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

למה אצל אתרים מסוימים הדפדפן מצליח לשפוך את הדף מהר יותר? ולמה אתרים אחרים ששוקלים אותו דבר ממש נטענים יותר לאט? מה יכול להפריע לו לרוץ כמו שהיינו רוצים? האם יכול להיות שיש עוד כמה פרמטרים חוץ ממשקל קובץ הHTML והתמונות או ה-CSS וה-JS?

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

אז לבעיות הברורות מאליהן:

1. משקל דף גדול וכבד

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

<table>
<tr>

<td>I'm a page title</td>

</tr>
</table>

במקום זאת בואו ונביט בקוד הנכון:

<h1>I'm a page title</h1>

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

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

  • על מנת לרנדר טבלה, הדפדפן זקוק לטאג הסוגר שלה על מנת להתחיל ולרנדר את הטבלה כולה. כן כן, גם את תכולתה. בבנייה תקנית האלמנטים קטנים יותר ואינם חלק מאלמנט ראשי.
  • כתוצאה מכך שהאלמנטים עצמאיים ואינם חלק ממבנה כללי ניתן להכיל עליהם מניפולציות JS שונות למטרות ממשק בצורה קלילה. בטבלאות זה הרבה יותר ספגטי ויכול לגרום לדף להיטען לאט במקרה ומניפולציות אלו יתרחשו בעת עליית הדף.
  • חשיבה טבלאית מבקשת לערוך הדף תוך העמסת מאפייני אלמנטים אינליינים, שיכפול מקטעי קוד ושימוש במבנה על מנת להשיג עיצוב ויזואלי, כמו למשל שימוש בTR בעל &nbsp; על מנת ליצור רווחי שורה.
    חשיבה תקנית מאידך חותרת לקוד המינימלי, יעיל, חכם, קטן, רזה וקריא שניתן. היא מבצעת שימוש בCSS על מנת לעצב הדף תוך שימוש בהיררכיית הHTML ולא כותבת שום מאפיין אינלייני בדף.
    בקישור הבא תוכלו לחזות במימוש תפישה זו על אלמנט Table. כן כן, אלמנט Table. מעולם לא אמרתי שלא משתמשים באלמנט הזה. יש לו תפקיד חשוב במסמכי HTML והוא לתאר מידע טבלאי.
    שימו לב כיצד מחבר המאמר לקח את האלמנט ובשימוש בCSS והיררכיית ה-DOM הוא מעצב את הטבלה. שימו לב כיצד קוד הCSS והHTML שלו נקיים ממאפיינים אינלייניים, קלי משקל ומודולרים וקלים לשינוי ותחזוקה עתידית – Accessible Data Tables. עוד על מאפייני אינליינים בסעיף הבא.

2. קוד אינלייני

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

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

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

Code starts here
<div class="LeftSideMenu">
<h3 class="LeftSideMenu_Heading">I'm a heading</h3>
<p class="LeftSideMenu_Paragraph">i'm a paragraph</p>
<ul class="LeftSideMenu_List">
<li class="LeftSideMenu_ListItem">
<p class="LeftSideMenu_ListParagraph"></p>
</li>
<li class="LeftSideMenu_ListItem"></li>
<li class="LeftSideMenu_ListItem"></li>
<li class="LeftSideMenu_ListItem"></li>
</ul>
</div>
End of code

במקום זאת אנא התבוננו במקטע הקוד הבא:

In the CSS file
.LeftSideMenu{}
.LeftSideMenu H3{}
.LeftSideMenu P{}
.LeftSideMenu UL{}
.LeftSideMenu LI{}
.LeftSideMenu LI P{}

In the HTML
<div class="LeftSideMenu">
<h3>I'm a heading</h3>
<p>i'm a paragraph</p>
<ul>
<li>
<p>I'm a paragraph inside a List Item</p>
</li>
<li>I'm a List Item</li>
<li>I'm a List Item</li>
<li>I'm a List Item</li>
</ul>
</div>

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

חלוקת הקומפוננטות בדף הבית של ynet

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

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

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

קחו למשל את הדוגמה הבאה: תפריט אתר ממונע JQuery. שימו לב לקוד הHTML שלו. הוא מינימלי עד אימה. אין שם שום דבר חוץ מרשימה פשוטה מאוד.

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

3. אלמנטי HTML המקפיאים את טעינת הדף

ישנו מושג חשוב מאוד בWebDesign ושמו סינכרוניזציה. קרי- האם הדף שלי תלוי בקובץ זה על מנת לרנדר העמוד וכתוצאה מכך הדף ימתין עד שהקובץ יטען במלואו ורק אז ימשיך לרנדר הדף. קבצי JS הם כאלה. כאשר ממקמים את קבצי הJS בראש העמוד- הדף כולו ממתין לטעינתם המלאה. כדי לפתור זאת באו לעולם 2 פתרונות – שימוש במאפיין Defer של טאג Script, או מיקום הקריאה לקובץ הJS בתחתית הדף, אם אין צורך בשניהם בעת טעינת הדף.

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

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

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

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

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

עוד על כך בהמשך…

4. תמונות ללא גדלים

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

5. קבצי הJS נקראים לפני קבצי ה-CSS

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

טעינת קבצי CSS לאחר טעינת קבצי JS

מקור התמונה: Google's page speed documentation

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

טעינה מקבילה של קבצי CSS ו-JS

מקור התמונה: Google's page speed documentation

לקריאה נוספת: Google's page speed: Optimize the order of styles and scripts

3. CSS יעיל

אל תשכפלו סלקטורי CSS (קלאסים, IDs או שמות אלמנטי html גנרים כמו OL or DL). לטווח הקצר זה חוסך זמן אך לטווח ארוך הנזקים הם רבים – משקל קובץ מנופח ובזבזני ופגיעה ביכולת עריכת המסמך ומודולריותו. ומהי מודולריות ויכולת עריכה?

לשפת CSS יש כמה תכונות שהופכות את השפה הזו לחזקה במיוחד אם אתה משתמש בהן כמו שצריך: Grouping & Nesting inheritance. ברגע שבונים נכון את מסמך הCSS, שינוי צבע פונט אינו צריך להערך בכמה סלקטורי class. פשוט משנים את הערך בקבוצת סלקטורים אשר החזיקה את מאפיין הצבע וזהו. אין צורך לעבור על כל המסמך ולחפש היכן מוגדר הצבע.
מסמך CSS הבנוי חכם יהיה בעל המשקל הנמוך ביותר שתוכלו לממש. אינני ממליץ על שמות סלקטורים בעלי מספר קטן של אותיות לשם חיסכון במשקל (שימו לב ל- CSS של יאהו). אני לא חושב שחיסכון המשקל שמשיגה שיטה זו יעלה על 5% במקרה הקיצוני ביותר. בד"כ תחסכו K אחד עד שלושה ותקבלו מסמך לא קריא הדורש מסמכי תיעוד וניהולם.

4. אופטימיזציית JavaScript

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

לקריאה נוספת:

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

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

  • לשונית Net – באמצעותו ניתן לבחון את סדר טעינת הקבצים בדף, לנתח משקלם וזמני תגובתם, לבדוק את סוג תגובת הHTTP של הקובץ- האם הוא החזיר שגיאת 404 למשל, או 304 שמשמעותה – אל תוריד אותי כי לא השתנתי ומשוך אותי מהקאש שלך.
  • סקריפט << Profile – באמצעות כלי זה ניתן לנתח את זמן הריצה של פונקציות הJS בעמוד, לבדוק יעילותן המתבטאת במשך זמן ריצתן וגם לשים לב למספר חזרות הריצה, דבר היכול להצביע על עיצוב קוד בעייתי.

על גבי Firebug מתיישבים 2 תוספים סופר חשובים: YSlow של יהאו ו- page speed של גוגל.
שניהם מבצעים כמעט אותו הדבר- מעניקים לדף אותו הם בוחנים ציון ע"י ניתוח ביצועי ומאפייני הדף. אלו 2 תוספים סופר חשובים להבנת ארכיטקטורת צד לקוח וקינפוג השרת. ניתן לחיות רק עם Yslow אך page speed יעניק תמונה יותר מלאה, לפחות בשלב הראשוני של למידת תחום ייעול ביצועים זה. לאחר שלומדים לעבוד נכון התוספים הופכים טיפה פחות רלוונטים.

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

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

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

  • המשקל הראשוני של האתר כאשר הלקוח נכנס אליו בפעם הראשונה ושום קובץ יושב בקאש של הדפדפן (Empty Cache), והמשקל בכניסה השניה (ואילך) בה חלק מהקבצים יושבים בקאש וחלק עדיין נטענים מהשרת (Primed Cache).
  • מספר קריאות ה-HTTP בעת עליית הדף לראשונה ובפעם השניה ואילך.

צילום מסך YSlow מתוך המהדורה המרכזית של נענע

צילום מסך YSlow נענע המהדורה המרכזית

וכיצד אינפורמציה זו יכולה לשרת אותנו? שימו לב לנתונים של דף המהדורה המרכזית של נענע:

  • דף HTML אחד.
  • 33 קבצי JS במצב empty cache ו8 פחות במצב prime cache.
  • 5 קבצי CSS במצב empty cache רק 1 פחות במצב prime cache.
  • אובייקטי פלאש נחתכו מ9 ל1, שהוא בתורו שוקל כמעט כלום.
  • מספר תמונות הCSS והתמונות האינלייניות נותרו ממש ללא שינוי (חוץ מצדיקה אחת).

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

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

את קבצי ה-JS היה ניתן לאחד, או לפחות לאחד ככל הניתן. אם תריצו את YSlow בדפדפן שלכם תוכלו לצפות בקבצים עצמם ולשים לב שחלקם שוקלים פחות מקיי בודד. למה לא היה ניתן לאחדם? אני בד"כ נוהג בפרויקטים שלי לאחד את כל פלאגיני ספריית הJS שלי לקובץ אחד גדול וכך חוסך קריאות HTTP מיותרות.

שימו לב לדוח של עמוד הבית של Yahoo.com:

דו"ח yslow מתוך עמוד הבית של yahoo.com

שימו לב, מ-38 קריאות החברה ירדו ל-2.
1 כי אין מה לעשות – צריכים לקרוא לעמוד ה-HTML שלעולם לא יוכל לשבת בקאש כי הדפדפן תמיד יבקש את ה-HTML עצמו של הדף. ו-1 קובץ נוסף שאין לי מושג מהו ומשקלו מאוד זניח.

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

ויש גם ספרים

סטיב סאודרס הוא מייסד תחום ביצועי צד הלקוח מבחינתי. הוא זה שהיה אחראי על הצוות של yslow ביהאו (כעת הוא עובד בגוגל) והוא הוציא 2 ספרים. אחד פורץ דרך High Performance Web Sites: Essential Knowledge for Front-End Engineers, והשני יצא ביוני 2009- מה שאומר שהוא ממש חדש- Even Faster Web Sites: Performance Best Practices for Web Developers

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

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

סיכום ומסקנות

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

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

מכירים טכניקות אופטימיזציה נוספות?

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

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

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

אודות שלומי אסף

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

עשוי לעניין אותך גם...

איך להתקדם בגוגל בלי אתר? על היום שבו לא נצטרך יותר אתרים

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

קידום אתרי חדשות

מבזק: 27 הנחיות חובה לקידום אתרי חדשות ופאבלישרים בגוגל

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

109 תגובות

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

    כמה הערות קטנות:
    1. תגיות הוא התרגום ל-Tags.
    2. הייתי מוותר על הביטוי 'קוזקים נאציים'.

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

    1. פלאש – השמתו באמצעות swftools בלבד וטעינתו לאחר שהדף עלה.
    2. בעמודים מורכבים שיש בהם לא מעט JS. עבודה נכונה עם AJAX מול צד השרת יכולה לטעון חלק מהסקריפטים רק כשצריך אותם ובכך להפחית את משקלו הראשוני של הדף.
    3. שימוש ב-Minification ל-JS ול-CSS. אם אתם משתמשים ב-PHP אז יש אפילו איזו ספריה שלו שעושה את זה בקלות.
    4. שימוש ב-CSS Framework במקרים *מסוימים* מקטינה את המשקל של ה-CSS.
    5. שימוש ב-cssים נפרדים עבור אקספלורר 6 ו-7 במקום האקים ב-CSS עצמו.

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

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

    • שלומי אסף

      היי רן. תודה על הפידבק החיובי.
      למה התכוונת בתרגום לTags? לכך שציינתי אלמנטים?
      לגבי הקוזקים- פגשתי כמה בחיי והם כתבו css מאוד רזה ויעיל 🙂

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

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

      • הי שלומי.

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

        בנוגע ל-CSS נפרדים לדפדפנים שונים – קל מאד לנהל אותם באמצעות ה-Web Developer של IE (נחות בהרבה מפיירבאג אבל יותר טוב מכלום).

        • שלומי אסף

          היי רן.

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

          לגבי הconditional comments – כיצד אתה עובד עם הטולבר של IE? הרי כדי לגשת אליו מלכתחילה עליך לדעת שאתה צריך לגשת אליו. מהי השיטה בה אתה משתמש כדי לדעת זאת?

          • הדוגמאות האלו לא זמינות על גבי הרשת לצערי 🙂

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

          • שלומי אסף

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

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

    • פבל ישראלסקי
      פבל ישראלסקי

      תודה רבה! אבל במקרה הזה הקרדיט מגיע למי שכתב את הפוסט – שלומי אסף ולא לי. עשה עבודה מקצועית ברמה גבוהה.

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

    תודה רבה.

  4. שלומי – ח"ח על פוסט מרתק, למי שזה תחום עיסוקו והבנתו, כמובן, וח"ח לך, פבל, על הרעיון המבריק לייצר את המדריך ולהצדיק שוב את המוניטין של הבלוג שלך כאכסניה איכותית בכל הקשור לקידום אתרים.
    תרומתי הצנועה לאופטימיזציה של האתר, שתוביל לטעינה מהירה יותר היא בהסבת תשומת ליבם של מזיני המידע למשקל התמונות והאמצעים ויזואליים אחרים.
    רבים טועים לחשוב כי אם לוקחים תמונה גדולה (ולצורך כך, זה יכול להיות כל אלמנט ויזואלי – תמונה, טבלה, תרשים, איור וכד'), ומקטינים את מידותיה, על ידי גרירת צלעותיה או חיתוך התיחום שלה – קטן משקלה בהתאם.
    ובכן – טעות. אפשר לחשוב על זה כך: אם אנחנו עומדים על מאזני שקילה, עוצרים את הנשימה ומכניסים את הבטן עד כלות האוויר – האם ישפיע הדבר על מחוג המשקל? מממ… לצערנו – לא. הדרך היחידה להשפיע על המחוג היא על ידי דיאטה רצינית, שתטפל במרכיבים האמיתיים הגורמים למשקלנו הנוכחי.
    כך הדבר גם בתמונות ממוחשבות: לא הגודל הנראה הוא הקובע – אלא שינוי הפרמטרים בתוכנת עיבוד תמונה – ברמת הגודל, ה- dpi ו/או הפיקסלים. רק בדרך זו – ניתן להקטין את משקל התמונה, ולשחרר את האתר ממשקל עודף שמקשה על קצב הטעינה.
    את התהליך כולו, בתוכנת פוטושופ, תיארתי – צעד צעד, בעמוד המאמרים שלי באתר http://www.seo-simple.co.il.

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

    • שלומי אסף

      תודה רבה לך עידית. לגבי עיבוד וייצוא התמונות אני יכול רק לומר- כל מילה בסלע!

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

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

      כל בייט הוא משמעותי וכל דבר שנכתב ב-5 שורות ויכול להיכתב בשורה אחת צריך באמת להפוך לשורה אחת.

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

    תודה רבה

  6. יפה!

    כמה הערות:

    1. פרסומות – בד"כ הן נטענות ב-Iframe או רכיב דומה, וכבד. עדיף להשתמש ב-JS כדי לטעון את כולן בבת אחת מהשרת הייעודי. ה-Iframeים האלו גוררים בקשות רבות ומיותרות נוספות.

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

    3. לא התייחסת בכלל לנושא של DNS ו-cookieless domain. מי שראה פעם את העוגיה האיומה של גוגל אנליטיקס יודע מה המשמעות.

    4. כמה קישורים נוספים בנושא

    כיווץ JS/CSS בסביבת ASP.net (ולא רק ב-PHP)

    • שלומי אסף

      היי משה.
      מסכים לחלוטין עם דבריך. כמה הערות:
      1. ומה אם יווצר מצב בו תאלץ לרנדר JS בעת זרימת הדף למסך המשתמש ולא לאחריו? כמו לכתוב סלקט JSי בעת כתיבת הדף ולא לאחריו, כי המתנה לכתיבת הDOM במלואה תיצור חור במסך.
      אך בגדול אתה צודק לחלוטין לגבי חוק זה.
      2. לגבי הDNSים והעוגיות כתבתי לך בתפוז שבאמת שאינני מכירם. תודה על המידע.

  7. כתבה נהדרת,חידשת לי המון !
    טיפ שלי שאני לא יודע עד כמה הוא משפיע,הוא להשתמש בקיצורים בCSS,במקום לעשות font-family faont-size וכו' פשוט להשתמש בfont ולרשום את כל הפרמטרים אחד אחרי השני לפי הסדר שהם צריכים להיות,חוסך המון שורות קוד ומפחית בגודל הקובץ

    • שלומי אסף

      תודה ארז.
      השאלה היא- האם לדפדפן לוקח יותר זמן לפענח לעבד ולהבין יותר את הshorthands מאשר כתיבה מלאה של המאפיינים…
      משום מה נראה לי שכתיבה as simply as you can get לדפדפן תאיץ בעוד קצת יותר את רינדור הדף.
      מה שציינתי פה איננו מבוסס על שום מחקר או חומר המפורסם ברשת. זהו רק ההגיון שלי והצוות שלי.

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

  8. עבודה יפה.
    מחכה למאמר הבא שיכלול gzip ומיניפיקציה.

  9. איתי ברנר

    וואו – מזמן לא ראיתי מדריך כל כך מפורט.

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

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

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

    • שלומי אסף

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

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

      • איתי ברנר

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

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

  10. מיכל כהן

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

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

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

  11. מיכל כהן

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

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

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

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

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

      בקיצור, נראה שכל מקצוע האופטימיזציה (SEO) הולך להיעלם מהעולם.

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

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

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

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

        אגב, בתחום בניית האתרים (הותיק מאוד) שממנו אני מגיע, עדיין לא הומצאה תוכנה שמייצרת קוד ברמה בה בן אדם מסוגל לייצר אז אני חושב שכנ"ל לגבי SEO, גם אם זה יגיע בסוף, ייקח המון זמן…

  13. מאחר ורק לפני כמה דקות כתבתי על כך בהרחבה ב-http://www.actv-tec.co.il/forum/viewtopic.php?p=1334#1334 אני לא אחזור על הכתוב שם כדי להמנע מתוכן מועתק בין שני דפי אינטרנט.

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

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

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

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

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

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

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

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

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

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

    • מיכל כהן

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

      • היי מיכל,

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

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

  14. שלומי אסף

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

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

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

    כאשר מפתח צד לקוח ניגש לעבר המלאכה, הוא מקבל לידו את כל המסכים של הפרויקט. אם זה 5 או 200. ומאותו רגע הוא אמור לאחד את קונפוננטות הHTML (רכיבי הדף) למספר המינימלי ביותר שיש תוך שימוש מינימלי בהוראות CSS. כדי לבצע זאת הוא אמור להתבונן במסכים ולראות מכנה משותף בין כולם ולהשתמש באותו קוד HTML במספר דפים. הוא אמור גם לשמור כמו יקה על כל שורת קוד במסמך הCSS שלו. על מנת להגשים זאת הוא משתמש בכלים שונים שCSS העניקה לו – Grouping & inheritance. אני חייב להודות שיש מכווצי CSS שעושים עבודה נאה בתחום.

    בנוסף מפתח צד לקוח דואג לעוד כמה ליירים שאינם קשורים לSEO –
    הנגשת הדף למוגבלים,- כאשר אני כותב דף, אני מדמיין בכל רגע כיצד הדף יראה בקורא המסך של מוגבל הנגישות. וישנם לא מעט דילמות בעת כתיבת הקוד – היכן למקם BR, ואם בכלל למקמו ולהשתמש בCSS למימוש המטרה. אלו שיקולים שאדם לוקח.
    הפרדת שכבות ויצירת unobtrusive js – כפי שציינתי קודם, ניתן לבנות תפריט או כל אלמנט HTML המנוהל ע"י JS במספר דרכים. לעתים מקטעי הHTML הללו הם תפריטים stand alone עצמאיים הניתנים למימוש באמצעות איזה טופס שייצרם אוטומטי (כפי שאתה שואף שיקרה), אך לעתים אלמנטים אלו הם חלק ממערך אובייקטיי JS אשר ניתנים למימוש רק ע"י תכנות JS תפור ספציפית לאתר. מדובר ברמות תחכום מאוד גבוהות ומורכבות הדורשות ראייה רחבה ולא צרה כפי שהאפליקציות שציינת מעניקות.

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

    • שלומי אסף

      תגובתי היא לעמנואל – המשך רציף לתגובתו בתגובה 13.

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

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

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

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

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

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

    • מודאגות? ממש לא 🙂 אני לא עוסק בתחום ה-SEO כלל וכלל אז אי אפשר לבוא ולומר שאני חרד למטה לחמי. אפילו אם יסגרו את ענף האינטרנט מחר בבוקר אני משער שאוכל לעבוד ככלכלן.

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

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

      • זה מסכם את הדיון מבחינתך, כי אתה, כפי שאתה מעיד על עצמך, "לא עוסק בתחום ה-SEO כלל וכלל".

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

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

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

  17. שלומי אסף

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

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

      אבל האלגוריתם של מנועי החיפוש העכשוויים מעניק ציונים בעלי גבול עליון לחלק מהפרמטרים וציונים שאין להם גבול עליון לפרמטרים אחרים, וביניהם פרמטר הקישורים. ולכן גם לציון המשוקלל מהציוניים החלקיים על פי כל הפרמטרים, לביטוי חיפוש נתון, לא יכול להיות גבול עליון בדמות 100% או למשל 17,324 נקודות.

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

      • שלומי אסף

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

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

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

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

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

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

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

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

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

    • שלומי אסף

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

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

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

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

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

      זאת השאלה המקצועית שראויה לתשובה.

      • זאת הייתה תגובה לסתיו זילברשטיין

      • שלומי אסף

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

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

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

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

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

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

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

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

      • היי עמנואל,

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

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

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

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

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

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

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

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

        1. להפוך את האינטרנט למקום מהיר ואיכותי יותר עבור כולנו.

        2. לתת תמריץ למי שיעשה כן.

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

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

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

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

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

          • שלומי אסף

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

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

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

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

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

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

          • לקוח שבוחר חברת SEO לפי הזולה מביניהן הוא לא לקוח של דוראן 🙂

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

  20. 1. שקיפות מלאה של כל תכנית הפעולה בהצעת המחיר.

    2. ההוכחה שכבר עשינו את זה בעבר בתחומים תחרותיים.

    כאן אין פילוסופיה, יש עובדות.

    • איך נראית, בעקרון, תכנית פעולה להשגת מקום 1 (ממקום 14) בגוגל ישראל לביטוי התחרותי יחסית [קידום אתרים], ועל סמך מה אתה מעריך לעצמך את העלות?

      איך הצלחה בעבר בתחום תחרותי אחד מנחה אותך לדייק בהערכת העלות של קידום אתר בגוגל העולמי לביטוי [web hosting]?

  21. רוצה להתייעץ בקשר למהירות אתר המושפעת מrss feed :
    יש לי בעמוד אחד באתר שלי 4 tickers. (עדכוני חדשות כמו ב YNET). הפתרון הראשון שלי היה IFRAME אבל החלטתי לוותר. לאחר מכן הצלחתי לבנות סקריפט ובו מערך של טיימרים הכל עובד טוב מבחינה פונקציונלית רק הבעיה היא שזה מעמיס מאוד על הדפדפן (מוזילה !!). כרגע אני מנסה לפתור את זה עם autoscroll jqueryאבל גם זה לא עוזר,לא יכול להשתמש בפתרון של פלאש(אפל). בכל אופן רציתי להתייעץ האם קיים או ידוע על פתרון לבעיה הזאת

  22. טוב אז מה שיכול לתרום לבעיה שלי למעלה זההעניין הזה עם תמונות רקע גדולות במזילה שיש לי
    http://support.mozilla.com/nl/forum/1/280242
    מישהו יודע מה הפתרון?
    תודה רבה

    • שלומי אסף

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

  23. פאבל,
    מה לגבי גורמים חיצוניים כמו שרתי האחסון?
    האם כדאי להשקיע יותר כסף (זה יכול להגיע גם לפי 2-3) ולאחסן אתר שפונה לקהל הישראלי על שרתים בארץ? האם זמן התגובה המהיר יותר שווה את זה?

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

    כל הכבוד על המאמר! 🙂

  25. מרתק
    נהנתי מאוד

  26. הוספת Expires or a Cache-Control Header לקבצים הסטטיים – תאריך תפוגתי לעולם לא פג.

    מה התג שעליי להוסיף לאתרי על מנת לעשות את זה ?

    תודה.

    • שלומי אסף

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

    • שלומי אסף

      שמתי למעלה במאמר לינק המסביר עוד על כך
      http://developer.yahoo.com/performance/rules.html#expires

      • ראיתי, אך לא מצאתי את התג המתאים.

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

        • שלומי אסף

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

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

  27. תודה שלומי פוסט מעניין ומקיף.אני עדיין לא סיימתי איתו.
    שאלה,לפי הנראה לעיין דפי פלאש עולים ממש במהירות הרבה יותר מ HTML ,האם לדעתך אפשר להשתמש בפלאש כפיתרון? [אני מדבר על משווקי PPC שפחות חשוב להם שגוגל יקרא אותם בחיפוש כמו ב SEO]
    ושוב, תודה.

    • שלומי אסף

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

  28. שלומי אסף

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

    http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html

  29. האם גוגל מתנה משהו בהבטחת מהירות טובה? האם אתר שעולה לאט מנוע מלהופיע במקום הראשון בגוגל? האם הוא מנוע מלהופיע במקום הראשון בזירה תחרותית?

    • שלומי אסף

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

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

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

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

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

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

  30. הי עמנואל,
    אכן גוגל מתחשבים במהירות של טעינת העמוד וזה אחד מהקיטריונים שלהם לפחות בגוגל אדוורדס.
    http://adwords.google.com/support/aw/bin/topic.py?hl=iw&topic=16348

    • לא שאלתי אם גוגל מתחשב במהירות האתר. אני מקבל את זה. מה ששאלתי הוא: האם גוגל מתנה משהו בהבטחת מהירות טובה? האם אתר שעולה לאט מנוע מלהופיע במקום הראשון בגוגל? האם הוא מנוע מלהופיע במקום הראשון בזירה תחרותית?

  31. כתבה מעולה.

    לאחרונה התנסיתי בשיפור מהירות של מספר אתרים. בעקבות כך כתבתי לפני כחודשיים כתבה על אופטימיזצית ביצועים בדרופל, שכדאי לקרוא אותה כמידע משלים:
    http://drupal.org.il/performance

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

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

  32. מדריך מקיף באנגלית: developer.yahoo.com/performance/rules.html

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

  34. מיקום ה CSS לפני ה JS הוא טיפ ממש טוב , תודה .

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

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

  36. תודה רבה על הכתבה המפורטת והשימושית לבעלי אתרים. משום מה, רשום לי ב-Webmaster Tools שזמן הטעינה של האתר שלי הוא כ-16 שניות. לא הבנתי למה, אצלי האתר פועל פשוט מהר. עוד דבר שקרה לי לא מזמן הוא שפתאום חלק מהעמודים לא מקבלים עותק שמור, האם הדבר יכול לקרות מטעינת עמוד ארוכה?

    רועי

    • רועי,

      נתוני WebMaster Tools לא מייצגים בהכרח את כל האוכלוסיה שגולשת אליך אלא מבוססים בעיקר דווקא על דפדפנים ישנים יותר. על ההבדל בין נתוני Google WMT ונתוני GA תוכל לקרוא בבלוג שכתבתי באתר שלנו בכתובת http://www.efficens-software.com/2012/02/googlepagespeed/. בנוסף, חשוב לדעת מהיכן גולשים אליך. אתה יכול לבצע בדיקות בעצמך ממקומות שונים בעולם באמצעות WebPageTest.org, אתר חינמי לבדיקות מסוג זה.

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

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

  38. שלום רב, אני מספק שירות בנושא של השיפור מהירות עבור דפי ASP.NET (דירוג "A"). לפרטים נא ליצור אתי קשר!

  39. זהר עמיהוד

    מאז התפרסם המאמר עברו הרבה מים בנושא שיווק באינטרנט בכלל וקידום אתרים בפרט. נושא מהירות טעינת האתר קיבל יותר ויותר דגש, עד כי בתחילת נובמבר 2013 שולבו כלי בדיקת המהירות וההצעות לשיפור של גוגל בתוך גוגל אנליטיקס.
    קבלו 6 כלים לבדיקת מהירות האתר שיעזרו לכם לשים את האצבע היכן נדרש שיפור.
    http://www.seoreport.co.il/2226

  40. היי.
    תודה על המאמר.
    ביצענו מספר אופטימיזציות לאתר GOGY.COM ואנחנו משתמשים גם כן ב-CDN.
    איך אפשר להאיץ את האתר בנוסף?

    שימוש ב-MEMCACHED יאיץ את האתר? פתיחת קטגוריה באותו דף כמו MAD.COM יפתור את הבעיה?

    איך KIZI.COM נטען מהר יותר? יש שם חלוקה ל-SUBDOMAINS של קבצים סטטים ודינאמיים – כנראה שזו השיטה שלהם לטעון יותר מהר מכולם?

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

    תודה,
    שחר

  41. שימוש ב-MEMCACHED יאיץ את האתר? פתיחת קטגוריה באותו דף כמו MAD.COM יפתור את הבעיה?

    איך KIZI.COM נטען מהר יותר? יש שם חלוקה ל-SUBDOMAINS של קבצים סטטים ודינאמיים – כנראה שזו השיטה שלהם לטעון יותר מהר מכולם?

    תודה למומח

  42. ואוו אחלה מאמר . ושאלה יש איזה תוכנה או פלגאין שעושה את זה אוטמטי ?

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

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

שתפו את הפוסט עם חברים