תיקון בעיות מהירות אתר: המדריך המלא לשיפור ביצועים

87% מהאתרים שאני בודק נכשלים ב-Core Web Vitals במובייל. לא 30%, לא 50% — שמונים ושבעה אחוז. ואתם יודעים מה הכי מעצבן בנתון הזה? רובם המוחלט של בעלי האתרים האלה משוכנעים שהאתר שלהם "די מהיר." אני גלעד קמר, מנכ"ל WEBS, ומ-2014 אני רואה את אותה תופעה שוב ושוב: בעל אתר פותח PageSpeed Insights, רואה ציון 72 בדסקטופ, נושם לרווחה, וסוגר את החלון. שבוע אחר כך הוא מתקשר אליי כי הדירוגים צללו והוא לא מבין למה. אז בואו נעשה סדר — לא במה ש"כדאי לדעת" על מהירות אתר, אלא במה שבאמת שובר את האתר שלכם ברגע זה.

הבדיקה ב-PageSpeed לבד לא אומרת לכם כלום

זאת אמירה שתרגיז הרבה אנשים בתעשייה, אבל היא נכונה. ציון של 92 ב-PageSpeed Insights בריצה אחת בדסקטופ זה כמו לבדוק חום בלי תרמומטר. הסיבה? אתם רואים נתוני "מעבדה" (Lab Data) שמדמים תנאים, אבל המשתמשים האמיתיים שלכם גולשים ברשת סלולרית עם iPhone של לפני ארבע שנים.

הנתון שמשנה הוא נתוני "שדה" (Field Data) שמגיעים מ-CrUX — דאטה אמיתית ממשתמשים אמיתיים. אם אין לאתר שלכם מספיק תנועה כדי להופיע ב-CrUX, אתם פועלים בעיוורון.

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

הדבר שאף אחד לא אומר לכם: רוב האתרים האיטיים סובלים משלוש בעיות בלבד

אחרי 12 שנה של עבודה עם מאות אתרים בארץ ובחו"ל — מארה"ב, גרמניה, אנגליה ושוויץ — אני יכול להגיד לכם דבר אחד בוודאות. 80% מבעיות המהירות שאנחנו פותרים נופלות לשלוש קטגוריות בלבד.

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

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

איך באמת לזהות מה מאט את האתר (במקום לנחש)

פותחים DevTools בכרום. לוחצים F12. עוברים ל-Performance Tab. מריצים הקלטה של טעינת העמוד במצב Slow 4G עם CPU 4x slowdown. ועכשיו אתם רואים את האמת.

תחפשו שני דברים: "Long Tasks" (משימות מעל 50ms שחוסמות את ה-Main Thread) ו-"Network Waterfall" שמראה מה נטען לפני מה. ברוב המקרים תראו סקריפט אחד או שניים שתופסים 60% מהזמן.

סיפור אמיתי: איך פספסנו את הבעיה האמיתית במשך שלושה שבועות

2022. אתר eCommerce ישראלי, כ-40 אלף ביקורים בחודש. LCP של 6.8 שניות במובייל. הצוות שלי ואני עברנו על הכל: ממטנו תמונות, הוספנו lazy loading, דחינו סקריפטים. ה-LCP ירד ל-5.2 שניות. עדיין רחוק מהיעד של 2.5.

שבוע שלישי. בודק מתחיל אצלנו פותח Server-Timing ומגלה ש-TTFB עומד על 2.1 שניות. שתי שניות לפני שהדפדפן בכלל מתחיל לקבל HTML. בדקנו את השרת — שאילתה אחת ל-MySQL רצה 1.8 שניות כי חסר index בטבלה. תיקון של 5 דקות בבסיס הנתונים. ה-LCP ירד ל-2.3 שניות.

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

למה תיקון תמונות הוא 60% מהפתרון (ואיך לא לטעות בדרך)

תמונה אחת ברזולוציה של 4000×3000 פיקסלים, במשקל 3.2MB, שמוקטנת ב-CSS ל-600px רוחב. תאמינו לי, ראיתי את זה אלפי פעמים. הדפדפן מוריד 3.2MB ומציג 600 פיקסלים. בזבוז ענק.

הפתרון הוא לא קסם. רזולוציה נכונה לפי המכשיר עם srcset. פורמט מודרני כמו WebP או AVIF. דחיסה חכמה. ו-lazy loading לכל מה שמתחת לקפל.

למידע נוסף יש מדריך responsive images מצוין ב-web.dev.

הסקריפטים החיצוניים: הרוצח השקט של המהירות

פיקסל פייסבוק. Google Analytics. סקריפט צ'אט. Hotjar. מערכת מעקב אחרי המרות. עוד פיקסל. ועוד אחד. ועכשיו האתר שלכם מריץ 14 סקריפטים חיצוניים שכל אחד מהם מוסיף 100–400ms לזמן הטעינה.

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

אצל לקוח שלנו בענף הביטוח גילינו 9 סקריפטים שהותקנו ב-2018 על ידי סוכנות שיווק שכבר לא עובדת איתם. מחיקה של 9 שורות קוד. שיפור של 1.4 שניות ב-LCP. ועלייה של 23% בהמרות תוך חודש.

JavaScript: הסיבה האמיתית שהאתר שלכם מרגיש "כבד"

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

הפתרון נקרא Code Splitting: לפצל את ה-bundle הגדול לחלקים קטנים שנטענים רק כשצריך אותם. ב-React/Vue/Angular יש לזה כלים מובנים. ב-WordPress עם בילדר זה יותר מסובך, אבל אפשרי.

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

CLS: למה האתר שלכם "קופץ" ואיך זה הורג את ההמרות

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

זה CLS — Cumulative Layout Shift. ולפעמים הוא חשוב יותר ממהירות הטעינה עצמה.

הסיבות הנפוצות? תמונות בלי width/height. פרסומות שנטענות באיחור. פונטים שמחליפים גודל. רכיבים מוטמעים (embeds) שמופיעים אחרי טעינת ה-DOM. הפתרון? תמיד תגדירו מקום מראש. תמיד.

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

קאש ודחיסה: איפה כולם טועים

"שמנו Cloudflare, עכשיו האתר מהיר." האמת? Cloudflare לבד לא פותר כלום. הוא נותן לכם CDN ו-edge caching, אבל אם השרת המקור שלכם איטי או שהקאש לא מוגדר נכון, אתם מקבלים 5% שיפור במקום 50%.

קאש נכון דורש שתי החלטות: מה לשמור, ולכמה זמן. תוכן סטטי כמו CSS, JS, תמונות — שמרו לשנה עם hash בשם הקובץ. HTML דינמי — לדקות, לא לשעות. API responses — תלוי לחלוטין בלוגיקה העסקית.

למי שרוצה את התקנים הרשמיים, RFC 9111 על HTTP Caching הוא המסמך המכונן בנושא.

ניטור: למה תיקון חד-פעמי הוא בזבוז זמן

תיקנתם את האתר. LCP ירד מ-5.4 ל-2.1. CLS מ-0.31 ל-0.04. מצוין. עברו שלושה חודשים. מישהו העלה תמונה חדשה ב-CMS בלי לדחוס אותה. מפתח הוסיף סקריפט מעקב חדש. עדכון של plugin שינה את ה-bundle של JS.

פתאום ה-LCP חזר ל-4.7 שניות. ואתם לא יודעים. עד שתבדקו שוב בעוד חודשיים. עד אז הדירוגים כבר ירדו.

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

סדר הפעולות הנכון: מה לתקן קודם

קיבלתם דוח עם 47 המלצות אופטימיזציה. מאיפה מתחילים? לא לפי הסדר ב-Lighthouse. הסדר ב-Lighthouse לא בהכרח לפי השפעה עסקית.

כמה זמן זה באמת לוקח (בלי בולשיט)

אתר WordPress קלאסי עם 30–50 עמודים, בלי תוספים מטורפים: שבועיים לעבודה מעמיקה. אתר eCommerce עם 500+ מוצרים: 4–6 שבועות. אפליקציית React/Vue מורכבת: חודשיים עד שלושה.

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

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

מהירות אתר ו-SEO: הקשר שכולם מבינים לא נכון

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

הקשר הוא עקיף ב-80% מהמקרים, ישיר ב-20% הנותרים. שיפור מ-6 שניות ל-3 שניות יביא לכם עלייה בדירוגים. שיפור מ-3 שניות ל-2 שניות כנראה לא. למעט מקרים תחרותיים מאוד שבהם זה ה-tie-breaker.

הטעויות שעולות הכי הרבה כסף

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

מיקרו-אופטימיזציות לפני מאקרו

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

מדידה במכשיר חזק

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

תוספי אופטימיזציה אוטומטיים בלי הבנה

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

התעלמות מ-TTFB

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

מה לבדוק ברגע זה (5 דקות של עבודה)

פותחים PageSpeed Insights. מכניסים את כתובת האתר. לוחצים על Mobile (לא Desktop). מסתכלים על ארבעה דברים: LCP, INP, CLS, ו-TTFB. אם אחד מהם באדום או צהוב — יש לכם עבודה.

אחר כך פותחים DevTools, עוברים ל-Network Tab, מסננים לפי Img וממיינים לפי Size. תמונות מעל 200KB? בעיה. תמונות מעל 500KB? בעיה גדולה.

מסננים לפי JS וממיינים לפי Size. קובץ JS אחד מעל 300KB? יש מה לבדוק. סך הכל JS מעל 1MB? יש לכם הזדמנות לשיפור משמעותי.

מתי כדאי לקרוא לעזרה מקצועית

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

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