אתר רספונסיבי: מדריך להתאמה לכל גודל מסך

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

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

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

• מה זה אתר רספונסיבי ובמה הוא שונה מגרסת מובייל נפרדת;
• מה קורה מתחת למכסה המנוע: מטא-תג viewport, מדיה קוורי ויחידות גמישות;
• איך בוחרים נקודות שבירה ואיך זה עובד ב-Webflow וב-WordPress;
• מה עושים עם תמונות, וידאו וטיפוגרפיה;
• מה מיוחד באתרים בעברית: RTL ונגישות;
• תוכנית עבודה להתאמת אתר קיים, בדיקות וטעויות נפוצות.

מה זה אתר רספונסיבי ובמה הוא שונה מגרסת מובייל

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

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

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

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

למה רספונסיביות משפיעה ישירות על לידים

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

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

קידום אורגני. מלבד האינדוקס לפי מובייל, מדדי חוויית המשתמש של גוגל (Core Web Vitals) נמדדים בעיקר בתנאי מובייל: זמן טעינת האלמנט הגדול בדף (LCP), יציבות ויזואלית (CLS) ומהירות התגובה לאינטראקציה (INP). פריסה לא מותאמת פוגעת בכולם — תמונות בגודל דסקטופ מאיטות את הטעינה, ואלמנטים שקופצים אחרי הטעינה שוברים את היציבות.

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

מה קורה מתחת למכסה המנוע

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

מטא-תג viewport

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

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

מדיה קוורי

מדיה קוורי (media query) הוא תנאי שתולים עליו קבוצת עיצובים: אם רוחב החלון קטן מערך מסוים, החל את הכללים האלה. כך נראית השורה שמפעילה עיצוב מובייל: max-width של 767 פיקסלים. אפשר גם לתחום טווח משני הצדדים ולהגדיר עיצוב שחל רק בין 768 ל-991 פיקסלים, כלומר בטאבלט בלבד.

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

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

יחידות גמישות וקונטיינר קוורי

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

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

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

נקודות שבירה: איך בוחרים אותן נכון

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

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

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

איך זה עובד ב-Webflow

ב-Webflow לא כותבים מדיה קוורי ידנית. יש נקודות שבירה מובנות: מסך בסיס לדסקטופ, מעליו 1280, 1440 ו-1920 פיקסלים, ומתחתיו טאבלט עד 991, מובייל לרוחב עד 767 ומובייל לאורך עד 478 פיקסלים. הכלל החשוב הוא כיוון הירושה: עיצוב שמוגדר במסך הבסיס יורד אוטומטית לכל המסכים הקטנים ממנו, ושינוי שנעשה בטאבלט משפיע גם על המובייל — אבל לא להפך.

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

איך זה עובד ב-WordPress ואלמנטור

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

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

תמונות, וידאו וטיפוגרפיה

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

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

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

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

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

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

עברית, RTL ונגישות: מה מיוחד באתרים ישראליים

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

כיווניות ומעבר בין שפות

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

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

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

נגישות לפי תקן 5568

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

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

תוכנית עבודה להתאמת אתר קיים

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

• שלב ראשון — מדדו לפני שמתקנים. פתחו ב-Google Analytics 4 את פילוח המכשירים והשוו שיעור המרה, זמן שהייה ואחוז יציאה בין מובייל לדסקטופ. זה קובע אם מדובר בתיקון נקודתי או בעבודה גדולה.
• שלב שני — רשמו את הדפים הקריטיים. בדרך כלל אלה דף הבית, דף השירות המרכזי, דף המוצר, דף יצירת קשר והצ'קאאוט. אל תנסו לתקן את כל האתר בבת אחת.
• שלב שלישי — בדקו את הבסיס. קיום מטא-תג viewport, גלילה אופקית מיותרת, ואלמנטים ברוחב קבוע בפיקסלים שגדולים ממסך טלפון — שלושת אלה מסבירים חלק גדול מהתקלות.
• שלב רביעי — עברו על נקודות השבירה. בכל אחת מהן בדקו תפריט, כותרת ראשית, טפסים, טבלאות וכרטיסים.
• שלב חמישי — טפלו במדיה. תמונות כבדות, וידאו רקע וגופנים שנטענים לאט — כאן מרוויחים הכי הרבה מהירות בזמן הקצר ביותר.
• שלב שישי — בדקו טפסים בטלפון אמיתי. סוג מקלדת נכון לכל שדה, מיקום הודעות שגיאה, וכפתור שליחה שלא נחבא מאחורי המקלדת.
• שלב שביעי — מדדו שוב אחרי שבועיים. אותם מדדים מהשלב הראשון, כדי לדעת אם התיקון עבד.

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

איך בודקים ואילו טעויות חוזרות הכי הרבה

כלים לבדיקה

מצב המכשירים ב-Chrome DevTools הוא הכלי היומיומי: הוא מאפשר לגרור את רוחב החלון ברצף ולראות בדיוק היכן הפריסה נשברת — וזו בדיקה טובה יותר מבחירת דגם מכשיר מהרשימה. את הביצועים ומדדי חוויית המשתמש בודקים ב-PageSpeed Insights של גוגל, שמציג תוצאות נפרדות למובייל ולדסקטופ. לבדיקת דפדפנים ומכשירים אמיתיים משתמשים בשירותי ענן כמו BrowserStack.

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

שמונה טעויות נפוצות

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

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

איך RJL Studio הופכת אתר לרספונסיבי באמת

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

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

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

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

שאלות נפוצות

כמה נקודות שבירה צריך לאתר עסקי ממוצע?

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

האם אתר רספונסיבי מספיק, או שצריך גם אפליקציה?

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

האתר שלי בנוי בתבנית ישנה. עדיף לתקן או לבנות מחדש?

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

מה ההבדל בין עיצוב רספונסיבי לעיצוב אדפטיבי?

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

איך בודקים במהירות אם האתר שלי מותאם למובייל?

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