מהירות אתר: איך מאיצים טעינה ומשפרים המרות

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

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

במדריך הזה נסביר:

• למה מהירות הטעינה משפיעה על מכירות ועל SEO;
• איך מודדים מהירות ומה אומרים המדדים של Core Web Vitals;
• איך מאיצים תמונות, פונטים, קוד, שרת ומסד נתונים;
• מה עושים בפועל ב-WordPress וב-Webflow;
• מה מיוחד באתרים בישראל ואיך בונים תוכנית עבודה בלי טעויות מיותרות.

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

למה מהירות האתר משפיעה על מכירות ועל SEO

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

ההשפעה מורגשת בשלושה מקומות:

• המרות. עמוד נחיתה איטי מאבד גולשים עוד לפני שהם ראו את ההצעה. זה בולט במיוחד בתנועה מקמפיינים, שבה משלמים על כל כניסה.
• עלות פרסום. אם חלק מהגולשים עוזבים לפני שהעמוד נטען, אותו תקציב מביא פחות לידים. גם Google Ads מתחשבת בחוויית עמוד הנחיתה כשהיא מעריכה את איכות המודעה.
• קידום אורגני. Google משתמשת באותות של חוויית עמוד, כולל Core Web Vitals, במערכות הדירוג שלה. הרלוונטיות של התוכן חשובה יותר, אבל כשיש כמה עמודים טובים באותה רמה, עמוד מהיר ויציב נמצא בעמדה טובה יותר.

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

איך מודדים מהירות אתר: Core Web Vitals והכלים

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

שלושת המדדים של Core Web Vitals

Google מגדירה שלושה מדדים מרכזיים לחוויית המשתמש, והם נחשבים טובים כשהם עומדים בסף אצל לפחות 75% מהכניסות:

• LCP (Largest Contentful Paint). כמה זמן עובר עד שהאלמנט הגדול ביותר במסך הראשון מופיע, בדרך כלל תמונת הפתיחה או הכותרת הראשית. היעד: עד 2.5 שניות.
• INP (Interaction to Next Paint). כמה מהר העמוד מגיב ללחיצה, להקלדה או לפתיחת תפריט. המדד החליף ב-2024 את FID. היעד: עד 200 מילישניות.
• CLS (Cumulative Layout Shift). כמה התוכן "קופץ" בזמן הטעינה, למשל כשבאנר נטען מעל הטקסט ומזיז את הכפתור. היעד: עד 0.1.

נתוני מעבדה מול נתוני שטח

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

הכלים שכדאי להכיר

• PageSpeed Insights מציג גם נתוני שטח, אם יש לאתר מספיק תנועה, וגם בדיקת Lighthouse עם רשימת המלצות.
• דוח Core Web Vitals ב-Google Search Console מקבץ את כל עמודי האתר לפי בעיות ומראה אילו תבניות עמוד דורשות טיפול.
• Chrome DevTools, בלשוניות Performance ו-Network, מראה מה בדיוק נטען, באיזה סדר וכמה זמן.
• WebPageTest מאפשר לבדוק ממיקומים ומרשתות שונים ולראות סרטון של הטעינה.

הסבר מפורט על המדדים והספים נמצא ב-web.dev, האתר הרשמי של צוות Chrome.

אופטימיזציה של תמונות ווידאו

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

פורמטים מודרניים ודחיסה

WebP ו-AVIF שוקלים פחות מ-JPEG ומ-PNG באיכות דומה, וכל הדפדפנים המודרניים תומכים בהם. לדחיסה ידנית מתאימים Squoosh ו-TinyPNG. באתרים גדולים עדיף להגדיר המרה אוטומטית ב-CMS או ב-CDN, כדי שלא יהיה תלוי במי שמעלה את התמונה.

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

תמונות רספונסיביות

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

טעינה עצלה, אבל לא לכל תמונה

הערך loading="lazy" דוחה את הטעינה של תמונות שנמצאות מתחת לקו הגלילה עד שהגולש מתקרב אליהן. זה חוסך הרבה בטעינה הראשונה. אבל תמונת הפתיחה, שהיא בדרך כלל אלמנט ה-LCP, לא צריכה טעינה עצלה. להפך: כדאי לסמן אותה ב-fetchpriority="high" כדי שהדפדפן יוריד אותה ראשונה.

מידות קבועות נגד קפיצות

תנו לכל תמונה, וידאו ו-iframe רוחב וגובה, או aspect-ratio ב-CSS. כך הדפדפן שומר להם מקום מראש, והטקסט לא קופץ כשהם נטענים. זה התיקון הנפוץ ביותר לבעיות CLS.

וידאו וסרטוני רקע

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

פונטים, CSS ו-JavaScript: פחות קוד שחוסם את הטעינה

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

פונטים

• השתמשו בשתיים-שלוש משקולות של פונט, לא בשמונה.
• ארחו את קובצי הפונט על אותו דומיין או CDN, בפורמט WOFF2.
• הוסיפו font-display: swap, כדי שהטקסט יופיע מיד בפונט גיבוי ולא יישאר בלתי נראה.
• עשו preload רק לפונט שמשמש בכותרת הראשית.
• פונט משתנה (variable font) יכול להחליף כמה קבצים נפרדים.

CSS

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

JavaScript וסקריפטים חיצוניים

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

• טוענים סקריפטים עם defer או async, כדי שלא יחסמו את הצגת העמוד;
• עוברים על כל התגים ב-Google Tag Manager ומוחקים את מה שכבר לא בשימוש: פיקסלים של קמפיינים ישנים, כלי מפות חום שאיש לא מסתכל בהם, בדיקות A/B שהסתיימו;
• טוענים וידג'טים של צ'אט, ביקורות ומפות רק אחרי אינטראקציה או אחרי שהעמוד נטען;
• בודקים ב-DevTools אילו סקריפטים הכי כבדים, ומחליטים אם כל אחד מהם באמת מביא ערך.

דחיסה בזמן העברה

השרת צריך לשלוח קבצים דחוסים ב-Brotli או ב-Gzip. ברוב האחסונים המודרניים זה מופעל כברירת מחדל, אבל כדאי לבדוק בלשונית Network ש-Content-Encoding אכן מופיע.

שרת, אחסון, מטמון ו-CDN

שרת ואחסון

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

• משאבי מעבד וזיכרון שמתאימים לתנועה, ולא שרת משותף עמוס מדי;
• גרסת PHP עדכנית ונתמכת, אם זה אתר WordPress;
• תמיכה ב-HTTP/2 או HTTP/3;
• מטמון בצד השרת ואפשרות ל-object cache, למשל Redis;
• מיקום השרת או נקודות ה-CDN קרוב לקהל שלכם.

מטמון (Cache)

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

CDN

CDN (Content Delivery Network) היא רשת שרתים ברחבי העולם ששומרת עותקים של הקבצים שלכם ומגישה אותם מהשרת הקרוב לגולש. השרת הראשי מקבל פחות בקשות, והגולש מקבל את הקבצים מהר יותר. ספקים מוכרים הם Cloudflare, Amazon CloudFront, Fastly ו-Bunny.net. כדי לחבר CDN בוחרים ספק, מוסיפים את הדומיין ומעדכנים את רשומות ה-DNS או את שרתי השמות. כשהאתר מאוחסן בחו"ל והקהל בישראל, CDN עם שרתים קרובים מקצר את זמן ההגעה של כל קובץ.

מסד הנתונים

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

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

מה עושים בפועל ב-WordPress וב-Webflow

WordPress

ב-WordPress הגמישות היא גם הסיכון: כל תוסף, תבנית ובונה עמודים מוסיפים קוד. מה עובד:

• תבנית קלה. תבניות כמו GeneratePress, Kadence ו-Astra, או תבנית בלוקים מבוססת theme.json, מתחילות ממשקל נמוך.
• תוסף מטמון אחד. למשל WP Rocket, LiteSpeed Cache (בשרתי LiteSpeed) או WP Super Cache. שני תוספי מטמון במקביל יוצרים בעיות, לא מהירות.
• פחות תוספים. עברו על הרשימה ומחקו מה שלא בשימוש. תוסף Query Monitor עוזר למצוא תוספים ושאילתות איטיים.
• Elementor. הפעילו את הגדרות הביצועים המובנות, כמו טעינת נכסים משופרת ופלט DOM מצומצם, והימנעו מקינון עמוק של קונטיינרים.
• תמונות. WordPress יוצר גדלים שונים ו-srcset אוטומטית ותומך ב-WebP וב-AVIF. תוסף אופטימיזציה או CDN עם המרת תמונות משלימים את השאר.

עוד על בנייה נכונה של אתר WordPress מההתחלה, כולל בחירת אחסון, במדריך איך בונים אתר ב-WordPress.

Webflow

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

• להמיר תמונות ל-WebP או AVIF ישירות בפאנל Assets;
• להגדיר טעינה עצלה לתמונות למטה בעמוד, ו-eager לתמונת הפתיחה;
• להיזהר עם אינטראקציות ואנימציות כבדות שרצות בטעינה;
• לבדוק קוד מותאם ב-Custom Code ובאלמנטי Embed, ולטעון סקריפטים חיצוניים עם defer;
• לא להעמיס רכיבי Collection List גדולים בעמוד אחד;
• לשמור על מבנה מחלקות מסודר, למשל לפי Client-First, כדי שה-CSS לא יתנפח.

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

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

• מובייל קודם. רוב הכניסות לאתרים עסקיים בישראל מגיעות מהטלפון, ולעיתים קרובות ברשת סלולרית. בודקים קודם כול בגרסת המובייל של PageSpeed Insights.
• פונטים בעברית. פונטים כמו Heebo, Assistant ו-Rubik כוללים גם עברית וגם לטינית. טענו רק את ערכות התווים והמשקולות שבאמת בשימוש.
• תוספי נגישות. אתרים רבים מוסיפים סרגל נגישות כדי לעמוד בתקן הישראלי 5568. חלק מהכלים האלה טוענים הרבה JavaScript. נגישות אמיתית נבנית בקוד עצמו, וכל כלי נוסף צריך להיבדק גם מבחינת משקל.
• וידג'ט וואטסאפ וצ'אט. כפתור וואטסאפ פשוט הוא קישור קל. וידג'ט צ'אט מלא טוען ספריות שלמות. אם הוא נחוץ, טענו אותו אחרי שהעמוד מוכן.
• פיקסלים וסליקה. Meta Pixel, Google Ads, GA4 ודפי תשלום בתוך iframe מוסיפים בקשות. השאירו רק מה שבאמת משמש למדידה, ושקלו לנהל חלק מהמעקב בצד השרת.

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

שלב 1: מודדים את המצב הקיים

מריצים PageSpeed Insights על העמודים החשובים: עמוד הבית, עמודי השירות, עמודי הנחיתה של הקמפיינים ועמוד מוצר. בודקים בדוח Core Web Vitals ב-Search Console אילו קבוצות עמודים מסומנות כבעייתיות. שומרים את התוצאות כנקודת התחלה.

שלב 2: מתעדפים לפי השפעה

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

שלב 3: מתקנים את הקל והמשתלם

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

שלב 4: מטפלים בתשתית

מטמון, CDN, שדרוג אחסון וגרסת PHP, ניקוי מסד הנתונים. כאן כבר נדרש מפתח או איש DevOps.

שלב 5: בודקים ומנטרים

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

טעויות נפוצות

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

איך RJL Studio מאיצה אתרים

ב-RJL Studio אנחנו בודקים את מהירות האתר כחלק מאבחון SEO טכני: מודדים Core Web Vitals בנתוני שטח ובמעבדה, מאתרים את מה שמאט את העמודים ובונים תוכנית תיקונים לפי סדר השפעה. אנחנו מטפלים בתמונות, בפונטים בעברית, בסקריפטים ובתגים, במטמון וב-CDN, ובונים אתרים חדשים ב-Webflow וב-WordPress עם מהירות כדרישה מהיום הראשון.

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

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

כמה מהר צריך להיטען אתר?

אין מספר אחד לכל אתר, אבל יעד טוב הוא לעמוד בספים של Core Web Vitals: LCP עד 2.5 שניות, INP עד 200 מילישניות ו-CLS עד 0.1, אצל לפחות 75% מהכניסות. בפועל, ככל שהתוכן המרכזי מופיע מהר יותר, כך טוב יותר.

מהירות האתר משפיעה על המיקום בגוגל?

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

למה הציון ב-PageSpeed Insights משתנה בכל בדיקה?

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

Webflow מהיר יותר מ-WordPress?

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

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

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