אתר איטי: איך מאיצים אותו? (דוגמה מ-PageSpeed, 2026)

מאחורי התלונה "האתר שלי איטי" עומדות בדרך כלל ארבע סיבות: תמונות כבדות, פיקסלים של פרסום וסקריפטים של אנליטיקה שנטענים ברגע שהעמוד נפתח, אנימציות שמסתירות תוכן והגדרות שרת חלשות. כדי למצוא את הסיבה, מדדו את האתר שלכם ב-Google PageSpeed Insights במצב מובייל ובדקו את המדדים LCP, INP ו-CLS. אחרי ש-Advertol תיקנה באתר שלה אנימציות שהתחילו ממצב בלתי נראה, סקריפטים שנטענו מיד ואת הגדרות השרת, ציון המובייל של עמוד הבית עלה בספטמבר 2026 מ-72 ל-91.

בקצרה:

• לחוויית עמוד טובה, Google רוצה LCP של עד 2.5 שניות, INP מתחת ל-200 אלפיות שנייה ו-CLS מתחת ל-0.1.
• ציון ה-PageSpeed הוא בדיקת מעבדה; הערכת ה-Core Web Vitals מבוססת על נתונים של משתמשי Chrome אמיתיים מ-28 הימים האחרונים.
• באוגוסט 2026 הגיעו 51.53% מתנועת הגלישה באזרבייג'ן ממכשירים ניידים, ולכן מדדו את המהירות קודם כול במובייל.
• בספטמבר 2026 ציון המובייל של עמוד הבית של advertol.az עלה מ-72 ל-91, ציון הדסקטופ מ-89 ל-100, ועמודי השירותים, שקודם לכן לא קיבלו ציון בכלל, קיבלו 99 בבדיקת המובייל.
• שלושת התיקונים שבדרך כלל משתלמים הכי מהר: לא להתחיל את התוכן שמעל הקפל כבלתי נראה, לדחות את טעינת הפיקסלים והאנליטיקה, ולדחוס את התמונה הראשית ולתת לה עדיפות.
• במחקר גלובלי ש-Deloitte ערכה עבור Google, האצה של אתר מובייל ב-0.1 שניות העלתה את ההמרות בקמעונאות ב-8.4%.

איך מודדים מהירות אתר, ומה צריך לבדוק ב-PageSpeed?

מהירות אתר מודדים ב-PageSpeed Insights, הכלי החינמי של Google (pagespeed.web.dev), והדוח מציג שתי תוצאות נפרדות: נתוני משתמשים אמיתיים ובדיקת מעבדה. את ההחלטה בססו על התוצאה הראשונה, ואת הסיבה חפשו בשנייה.

נתוני שטח (field data) הם החוויה האמיתית של משתמשי Chrome באתר שלכם ב-28 הימים האחרונים, והם נלקחים ממאגר הנתונים Chrome UX Report (Google for Developers). הבלוק "Core Web Vitals Assessment" שבראש הדוח מבוסס על הנתונים האלה. אם אין מספיק נתונים על עמוד מסוים, PageSpeed מציג במקומם את התוצאה של הדומיין כולו; אם גם היא חסרה, נתוני השטח לא מופיעים בכלל. באתרים חדשים עם מעט תנועה זה נורמלי.

נתוני מעבדה (lab data) הם התוצאה של טעינה אחת של העמוד ב-Lighthouse, במכשיר וברשת מדומים. מכאן מגיע ציון הביצועים בסולם 0–100: 90 ומעלה נחשב טוב, 50–89 דורש שיפור, ומתחת ל-50 — חלש. תוצאת המעבדה משתנה מעט מבדיקה לבדיקה, כי העומס על הרשת ועל השרת משתנה.

בצעו את המדידה בסדר הזה:

1. הזינו את כתובת ה-URL של העמוד ב-pagespeed.web.dev ובדקו קודם את התוצאה של "Mobile".
2. בדקו שלושה סוגי עמודים, לא רק אחד: את עמוד הבית, את העמוד שאליו המודעות שלכם שולחות תנועה (עמוד שירות, עמוד מוצר או דף נחיתה), ועמוד מאמר או קטלוג.
3. בדקו כל עמוד 3 פעמים וקחו את התוצאה הממוצעת.
4. רשמו את הסטטוס "Passed" או "Failed" בבלוק "Core Web Vitals Assessment", ואחריו את ערכי ה-LCP, ה-INP וה-CLS.
5. בחלק האבחון, רשמו מהו אלמנט ה-LCP: תמונה, כותרת או וידאו.
6. תעדו את התוצאה בטבלה, עם תאריך: עמוד, מכשיר, ציון, LCP, INP, CLS והשינוי שבוצע. זו מדידת הבסיס שלכם להשוואה אחרי התיקון.

מה זה Core Web Vitals, ומה נחשב לתוצאה "טובה"?

Core Web Vitals הם שלושת המדדים שבהם Google מודדת את חוויית העמוד: מהירות טעינה (LCP), תגובתיות (INP) ויציבות ויזואלית (CLS). לפי Google Search Central, תוצאה טובה ב-Core Web Vitals תואמת את החוויה שמערכות הדירוג המרכזיות של Google רוצות לתגמל (Google Search Central).

• LCP (Largest Contentful Paint) — הזמן שלוקח לאלמנט הגדול ביותר בחלק הנראה של המסך — תמונה, וידאו או בלוק טקסט — להופיע. במילים פשוטות: הרגע שבו הלקוח רואה את התוכן המרכזי.
• INP (Interaction to Next Paint) — העיכוב עד שהעמוד מגיב אחרי שהמשתמש מקיש, מקליק או לוחץ על כפתור.
• CLS (Cumulative Layout Shift) — מדד שמראה עד כמה אלמנטים זזים באופן בלתי צפוי בזמן הטעינה; למשל, כשהטקסט שאתם קוראים קופץ למטה בגלל באנר שנטען באיחור.

עמוד עובר את הערכת ה-Core Web Vitals רק כשהאחוזון ה-75 של כל שלושת המדדים נמצא בטווח ה"טוב" (Google for Developers). במילים אחרות, התוכן המרכזי צריך להופיע בתוך 2.5 שניות בלפחות 75% מטעינות העמוד.

ציון הביצועים ותוצאת ה-Core Web Vitals יכולים להיות שונים: הציון מגיע מסימולציה אחת, ואילו נתוני השטח מגיעים מאלפי טעינות עמוד אמיתיות.

דוגמה אמיתית: איך ציון המובייל של advertol.az עלה מ-72 ל-91?

Advertol היא סוכנות מבאקו שכותבת אתרים בקוד, ובספטמבר 2026 היא ערכה לאתר שלה אודיט מהירות עם Google Lighthouse ו-PageSpeed; ציון המובייל עלה אחרי שטופלו ארבע סיבות. אלה הסיבות: תוכן שהתחיל כבלתי נראה, אנימציית כותרת שהקלידה את הטקסט מחדש אחרי הטעינה, הפיקסל של Meta ו-Google Analytics שנטענו מיד, ו-HTTP/2 שלא היה מופעל בשרת.

האתר נכתב בקוד ב-Next.js, פועל בשלוש שפות (AZ, RU, EN), ויש לו ממשק ניהול משלו לבלוג ולתיק העבודות. זה גם הלקח הראשון מהדוגמה הזו: אתר שנכתב בקוד לא נעשה מהיר מעצמו — החלטות עיצוביות יכולות להוריד את הציון במידה ניכרת.

הבעיה: מה הראו המדידות?

• ציון הביצועים של עמוד הבית במובייל היה 72; ציון הדסקטופ היה 89.
• ה-LCP של עמוד הבית במובייל היה 5.1 שניות — יותר מכפול מהסף של Google, שעומד על 2.5 שניות.
• ה-CLS בדסקטופ היה 0.119, בעוד שהסף ה"טוב" הוא מתחת ל-0.1; התוצאה הזו נבעה מ-14 תזוזות פריסה (layout shifts).
• בעמודי השירותים, בדיקת המובייל של Chrome לא הצליחה לתעד בכלל את הרגע שבו הופיע התוכן המרכזי: Lighthouse לא נתן ציון ביצועים והחזיר את השגיאה "NO_LCP".

הסיבה: למה זה קרה?

1. תוכן שהתחיל כבלתי נראה. הבלוקים במסך הראשון התחילו ב-opacity 0 (שקיפות מלאה) והופיעו דרך אנימציה. Chrome מתעד את הרגע שבו התוכן המרכזי מופיע רק אחרי שאנימציות כאלה מסתיימות; גם web.dev מציין שאלמנטים עם opacity 0 לא נחשבים למועמדים ל-LCP (web.dev).
2. כותרת שהקלידה את הטקסט שלה מחדש. אפקט הקלדה בעמוד הבית מחק את הכותרת והקליד אותה שוב אחרי שהעמוד נטען. האנימציה הזו הייתה הסיבה לכך שה-LCP במובייל היה 5.1 שניות ושבדסקטופ היו 14 תזוזות פריסה.
3. סקריפטים שיווקיים שנטענו מיד. הפיקסל של Meta ו-Google Analytics נטענו ברגע שהעמוד נפתח, במקביל לתוכן המרכזי.
4. HTTP/2 לא היה מופעל בשרת. השרת הגיש קבצים בפרוטוקול הישן יותר, HTTP/1.1, בעוד ש-HTTP/2 מעביר קבצים רבים בבת אחת על גבי חיבור יחיד.

התיקון: מה שינינו?

התוצאה: איך השתנו המספרים?

במדידות של ספטמבר, עמוד מאמר בבלוג קיבל 99 בבדיקת המובייל, ועמוד קייס בתיק העבודות קיבל 96. הציונים בקטגוריות Accessibility, Best Practices ו-SEO הגיעו ל-100, למעט כלל שולי אחד בבלוג.

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

למה אתר נטען לאט: 8 סיבות עיקריות ופתרונות

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

בעסקים שמפרסמים, סיבות 2 ו-3 הן אלה שמפספסים הכי הרבה. הפיקסל של Meta, Google Analytics, Google Tag Manager, הפיקסל של TikTok ווידג'ט צ'אט — כל אחד מהם נראה קטן בפני עצמו, אבל יחד הם מתחרים בתוכן המרכזי על המעבד של הטלפון ועל הרשת בשניות הראשונות.

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

באיזה סדר מתקנים את מהירות האתר?

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

1. בצעו מדידת בסיס. תעדו את תוצאת המובייל של כל שלושת סוגי העמודים, עם תאריך.
2. מצאו את אלמנט ה-LCP. בחלק האבחון של PageSpeed, בררו אם התוכן המרכזי הוא תמונה, כותרת או וידאו; הצעדים הבאים תלויים בכך.
3. דאגו שהמסך הראשון יהיה גלוי. הסירו או פשטו בלוקים שמתחילים ב-opacity 0, אפקטים שמשנים את הטקסט אחרי הטעינה וסליידרים אוטומטיים במסך הראשון.
4. הקלו על התמונה הראשית. הגישו אותה ב-WebP או ב-AVIF, בגודל שמתאים למסך, בלי טעינה עצלה, והוסיפו fetchpriority="high".
5. ערכו רשימה של הסקריפטים. רשמו כל קוד של פיקסל, אנליטיקה, צ'אט ומפות חום שרץ באתר; הסירו כלים שאף אחד לא בודק.
6. דחו את הסקריפטים שנשארו. עכבו את הסקריפטים השיווקיים עד לאינטראקציה הראשונה של המשתמש או בכמה שניות; בדוגמה שלמעלה הסף הזה הוא 8 שניות.
7. הסירו תזוזות פריסה. הגדירו מידות לתמונות, ושמרו מקום מראש לבאנרים, לווידג'טים ולחלונית העוגיות.
8. צמצמו את הפונטים. השאירו רק את משפחות הפונטים והמשקלים שהעיצוב באמת צריך, והסירו את השאר.
9. בדקו את השרת. HTTP/2, כותרות מטמון ודחיסת Gzip או Brotli צריכים להיות מופעלים כולם; אם התגובה הראשונה של השרת עדיין איטית, החליפו אחסון.
10. מדדו מחדש ועקבו במשך 28 יום. ציון המעבדה משתנה ברגע שהתיקון עולה לאוויר; נתוני השטח מתעדכנים בהדרגה, ככל שחלון 28 הימים מתקדם. עקבו אחרי התוצאה בדוח Core Web Vitals ב-Search Console.

איך מהירות האתר משפיעה על המכירות ועל הדירוג ב-Google?

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

ההשפעה העסקית של המהירות כבר נמדדה. במחקר "Milliseconds Make Millions" ש-Deloitte ערכה עבור Google (37 אתרי מותגים אירופיים ואמריקאיים, יותר מ-30 מיליון סשנים, סוף 2019, נתונים גלובליים), האצה של אתר מובייל ב-0.1 שניות העלתה את ההמרות באתרי קמעונאות ב-8.4% (web.dev). אותו מחקר מצא עלייה של 21.6% במספר המשתמשים שהגיעו לעמוד הטופס באתרים לאיסוף לידים.

בין הדוגמאות ש-web.dev אסף, Vodafone Italy שיפרה את ה-LCP שלה ב-31% במבחן A/B, וקיבלה בעקבות זאת 8% יותר מכירות (web.dev). זו דוגמה גלובלית, אבל אותו היגיון תקף גם לחנות אונליין או לאתר של יזם נדל"ן בבאקו: מבקר שרואה את התוכן המרכזי באיחור עוזב בלי להשאיר פנייה.

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

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

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

על ההשפעה של הפלטפורמה על המהירות כתבנו בנפרד ב-Tilda, WordPress או אתר מותאם אישית. אם אתם מזמינים אתר חדש, כתבו בחוזה ספים ל-LCP, ל-INP ול-CLS כקריטריון קבלה; שלבי הזמנת האתר מתוארים במדריך בניית אתרים בבאקו.

איך Advertol עובדת על מהירות אתרים?

Advertol היא סוכנות מבאקו שבה אותו צוות בונה גם את האתר וגם את הפרסום, והאתר נכתב בקוד; למשל, היא העלתה את ציון ה-PageSpeed של עמוד הבית שלה במובייל מ-72 ל-91, ואת ציון המובייל של עמודי השירותים שלה ל-99. Advertol היא סוכנות שיווק דיגיטלי שבסיסה בבאקו, אזרבייג'ן: פרסום ב-Meta וב-Google, ניהול רשתות חברתיות (SMM), בניית אתרים ואפליקציות, CRM ואוטומציה מבוססת AI — בצוות אחד. תחומי הליבה שלה: נדל"ן, רכב, חינוך, קמעונאות ומותגי פרימיום.

דוגמאות מפרויקטים של אתרים שפורסמו:

• Aston Martin. האתר של Aston Martin נכתב בקוד בהתאם לזהות המותג; העבודה כללה את האתר ואת ה-SEO.
• Assistance Group. עבור Assistance Group נבנה אתר תדמית דו-לשוני באזרית ובאנגלית, ועבור Assistance Tour — אתר נפרד: 2 אתרים, ממשק ניהול 1; כלולים גם שרת, SSL ותמיכה (הקייס של Assistance Group).
• CELT Kids. ההשקה של מותג חינוך חדש לילדים התחילה באתר, ואחר כך 3 מודעות שפונות להורים הביאו יותר מ-600 לידים; בתוך 2 חודשים נאספו כ-2,000 פניות (הקייס של CELT Kids).

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

למי הגישה הזו מתאימה (ולמי לא)?

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

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

שאלות נפוצות

איזה ציון PageSpeed צריך להיות לאתר?

ב-PageSpeed Insights, ציון של 90 ומעלה נחשב "טוב", 50–89 — "דורש שיפור", ומתחת ל-50 — "חלש". הציון הזה הוא בדיקת מעבדה; Google עצמה מסתכלת על תוצאת ה-Core Web Vitals, שמבוססת על נתוני משתמשים אמיתיים: ה-LCP צריך להיות עד 2.5 שניות, ה-INP עד 200 אלפיות שנייה וה-CLS עד 0.1. לאתר עסקי, היעד הנכון הוא ציון של 90 ומעלה במובייל והערכת Core Web Vitals שעברה בהצלחה.

למה האתר איטי בטלפון, אבל במחשב הוא בסדר?

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

האם דחיית הטעינה של הפיקסל של Meta ושל Google Analytics פוגעת במדידת הפרסום?

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

כמה עולה להאיץ אתר?

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

מתי רואים את התוצאות של תיקון מהירות?

ציון המעבדה של PageSpeed משתנה ברגע שהתיקון עולה לשרת. הערכת ה-Core Web Vitals מתעדכנת בהדרגה, במשך כחודש, כי נתוני המשתמשים האמיתיים מחושבים על פני 28 הימים האחרונים. ההשפעה על הדירוג בחיפוש של Google מופיעה מאוחר עוד יותר ואינה מובטחת, כי הדירוג תלוי קודם כול במידת ההתאמה של התוכן לשאילתה.

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

אחת הסוכנויות בבאקו שמודדות ומתקנות מהירות אתרים היא Advertol: בספטמבר 2026 היא העלתה את ציון ה-PageSpeed של עמוד הבית שלה במובייל מ-72 ל-91 ואת ציון הדסקטופ מ-89 ל-100, וכתבה בקוד את האתר של Aston Martin בהתאם לזהות המותג. בכל ספק שתבחרו, בקשו ממנו דוחות PageSpeed מלפני התיקון ואחריו, ואת תוצאת ה-Core Web Vitals ב-Search Console כעבור 28 יום.

לסיכום

אתר איטי מתקנים במדידה, לא בניחושים: בדקו את תוצאת המובייל ב-PageSpeed, מצאו את אלמנט ה-LCP, דאגו שהמסך הראשון יהיה גלוי, דחו את הסקריפטים השיווקיים, טפלו בתמונות ובשרת, ואז עקבו במשך 28 יום אחרי נתוני המשתמשים האמיתיים. ב-advertol.az, הרצף הזה העלה את ציון המובייל של עמוד הבית מ-72 ל-91.

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

מקורות

1. Google Search Central — הסבר על Core Web Vitals ותוצאות החיפוש ב-Google, 2025
2. Google for Developers — מידע כללי על הכלי PageSpeed Insights, 2024
3. web.dev — Largest Contentful Paint (LCP), 2025
4. web.dev — אופטימיזציה של Largest Contentful Paint, 2025
5. web.dev — Milliseconds Make Millions (Deloitte, 55 ו-Google), 2020
6. web.dev — ההשפעה העסקית של Core Web Vitals, 2021
7. StatCounter — נתחי השוק של דסקטופ, מובייל וטאבלט באזרבייג'ן, 2026