מדוע דפי AMP מאבדים מהירות במובייל
דפי AMP תוכננו כפורמט מהיר באופן מובטח לתוצאות החיפוש במובייל, אך בפועל ההאצה אובדת כבר בשלב האינטגרציה עם האתר הראשי. הסיבה היא שעטיפת ה-AMP אינה מבטלת שגיאות בתוכן ובחיבורים: מוני צד שלישי, צ'אטים ווידג'טים מתחברים לדף באמצעות תגים רגילים והופכים שוב לסקריפטים חוסמים. הדפדפן עוצר את ניתוח המסמך עד שיטען ויריץ אותם — וכל התועלת ממסגרת קלה נעלמת.
מקור שני להידרדרות — תמונות. ב-AMP הן מוגשות דרך רכיב ייעודי שמקצה מקום לתמונה וטוען אותה בעצלתיים. אם עוקפים את הרכיב הזה באמצעות תג צד שלישי או מגישים קובץ בגודל מלא ללא וריאנטים אדפטיביים, מהירות המובייל צונחת: הדף קופץ בזמן הטעינה, והזמן עד לרינדור התוכן הראשי גדל.
כך גם עם גופנים וסגנונות — CSS קריטי שלא הוצא החוצה וחיבור גופנים חיצוניים חוסמים את הרינדור הראשון.
סיבה שלישית — היעדר עדיפויות טעינה. כאשר כל המשאבים נדרשים בו-זמנית ובאותו משקל, הדפדפן מבזבז זמן על משני: אנליטיקה, באנרים, בלוקים מוסתרים. אופטימיזציית הטעינה מתחילה ממה שנראה במסך הראשון — השאר נדחה. ללא קביעת עדיפויות, אפילו דף AMP שנבנה כהלכה מפסיד במדדים לעימוד רגיל ומהוטב היטב.
בנפרד יש להתייחס לשמירה במטמון ולהגשה. אם גרסת ה-AMP מתארחת על תת-דומיין נפרד ללא מדיניות מטמון משותפת, המבקר במעבר מתוצאות החיפוש במובייל מקבל תגובת שרת קרה. כותרות מטמון מתואמות, דחיסה והגשה נכונה של סטטי מחזירות את השניות שאובדות בבקשות חוזרות.
כל הסיבות הללו ניתנות לתיקון, ואנו מפרטים כיצד זה נסגר ברמת הבנייה, העדיפויות וההגשה.
מה נותן תרגום האתר לתגי AMP
תגי AMP מסירים את כל מה שמפריע לעמוד להופיע על המסך מיד: סקריפטים כבדים, בלוקים חיצוניים, טעינה מאוחרת של התוכן הראשי. הדפדפן מקבל תגים מוכנים מראש ומצייר את המסך הראשון בלי להמתין לבקשות צד שלישי — הזמן עד לציור הראשון ברשתות סלולריות מתקצר פי כמה, ולא באחוזים בודדים. בשביל המבקר זה ההבדל בין "נפתח מיד" לבין "הגלגלת מסתובבת".
בהמשך האפקט מצטבר. כשהמסך הראשון מופיע במהירות, חלק מהאנשים לא מספיקים לעזוב: שיעור הנטישה יורד, כי האדם לא נוטש את העמוד בשלב ההמתנה. זה מורגש במיוחד במקומות שבהם הקהל מגיע מהטלפונים ובחיבור לא יציב — כלומר, ברוב התעבורה הסלולרית.
שכבה נפרדת — תוצאות מהירות. עמודים שנבנו לפי דרישות AMP נכנסים לבלוק התצוגה המואצת בתוצאות החיפוש, שבו התוצאות נפתחות בלי טעינה מלאה של האתר. חלקם של עמודים כאלה גדל, והמעברים מהחיפוש מתחילים להגיע לגרסה מוכנה, ולא לגרסה "גולמית".
חשוב שזה לא אתר כפול נפרד. הכתובת הקנונית נשארת כשהייתה, הגרסה הרגילה וגרסת ה-AMP מפנות זו לזו, ולכן המשקל המצטבר של העמודים והמיקומים לא הולכים לאיבוד. אם התגים במקום כלשהו חורגים מהדרישות, העמוד פשוט נושר מהתצוגה המואצת — שאר האתר ממשיך לעבוד כמו קודם.
האצת הטעינה כאן היא לא תיקון חד-פעמי, אלא מצב עבודה: תבניות, עיצובים ולוגיקת הטעינה מקובעים במסגרת הכללים, ועמודים חדשים נבנים מיד לפיהם. לכן הרווח נשמר, ולא נעלם אחרי הבנייה מחדש הראשונה.
אפשרויות מימוש AMP: השוואת גישות
בחירת הגישה קובעת לא רק את מהירות הטעינה, אלא גם כיצד האתר יתנהל בהמשך: כמה גרסאות של הדף יהיה צורך לתחזק, עד כמה מורכב יהיה לבצע שינויים, וכיצד יתנהגו תוצאות החיפוש בעת עדכון התוכן. להלן שלוש אפשרויות מעשיות, שביניהן באמת בוחרים בפרויקטים, עם החוזקות שלהן ומחיר התחזוקה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| דפי AMP נפרדים | מדורי תוכן: מאמרים, חדשות, כרטיסי מוצר, שבהם חשובה הצגה מיידית בחיפוש | שתי גרסאות של כל דף — יש לסנכרן שינויים; סט מצומצם של אלמנטים, כללים משל עצמם לסקריפטים ולעיצוב |
| סימון היברידי | תוכן אחד, שתי תוצאות: דף רגיל וגרסת ה-AMP שלו מאותה כתובת | דורש קישור מדויק בין הגרסאות ושליטה בקישורים הקנוניים, אחרת מנוע החיפוש יבחר את הדף הלא נכון |
| רכיבי AMP דינמיים | בלוקים אינטראקטיביים בתוך AMP: מסננים, טעינה מתמשכת, טפסים, פידים | ההיגיון מוגבל לסט הרכיבים המותר; תרחישים לא סטנדרטיים יש לכתוב מחדש בהתאם לכללי AMP |
בפועל, לרוב בוחרים בסימון ההיברידי: הוא מספק גרסת AMP מהירה ללא שכפול תוכן וללא צוות שינויים שני. דפים נפרדים מוצדקים כאשר AMP נדרש נקודתית — למשל, רק עבור מאמרים, בעוד שאר האתר מתנהל באופן עצמאי.
רכיבים דינמיים מחברים על גבי כל אחת מהאפשרויות, כאשר בגרסת ה-AMP נדרשים מסננים או טעינה מתמשכת, ולא רק טקסט.
המגבלות של AMP אינן גזר דין, אלא מסגרת שבתוכה מתכננים מראש: סט התגים המותר, האיסור על סקריפטים שרירותיים, הדרישות לעיצוב ולסימון. אם מניחים אותן בשלב התכנון, ולא מצרפים AMP לאתר מוכן, עלות התחזוקה יורדת: השינויים מתבצעים במקור אחד, והגרסה המהירה נבנית אוטומטית.
את בחירת הגישה מקבעים לאחר ניתוח מבנה האתר והתרחישים: היכן נדרשת מהירות הצגה, היכן אינטראקטיביות, והיכן חשוב יותר מקור תוכן אחיד. תארו את המשימה — נחזור עם הערכה ותוכנית לאפשרות konkretit.
כיצד אנו מיישמים AMP: שלבי העבודה
יישום AMP אינו "להתקין תוסף", אלא לבנות מחדש את התוצאות והסימון כך שכל עמוד יעבור ולידציה ויוגש מהמטמון באופן מיידי.
אנו מתחילים בביקורת: בוחנים אילו סוגי עמודים בכלל הגיוניים ב-AMP (מאמרים, כרטיסי מוצר, דפי נחיתה), אילו סקריפטים והטמעות צד שלישי שוברים אותם, והיכן כבר קיימות גרסאות מובייל כפולות. בסיום הביקורת אנו מקבעים רשימת תבניות ומגבלות — זה חוסך שבועות של עבודות תיקון בהמשך.
מכאן התהליך מתקדם בשלבים, ובכל שלב יש תוצאה ברורה שאפשר לבדוק.
- ביקורת הסימון הנוכחי. מפרקים את מבנה העמודים, מאתרים HTML לא תקין, סקריפטים כבדים של צד שלישי, סגנונות inline ובלוקים ש-AMP אוסר. בתום השלב — מפת עמודים ורשימה של מה שיהיה צורך לכתוב מחדש.
- תכנון תבניות AMP. מרכיבים סט תבניות לכל סוג תוכן: מאמר, קטלוג, כרטיס, דף נחיתה. מראש מגדירים רכיבים המותרים בסימון ונקודות חיבור של אנליטיקה.
- הגדרת מטמון. מגדירים הגשת סטטיקה וסימון כך שהעמודים ייכנסו כראוי למטמון מנוע החיפוש ויתעדכנו בעת פרסום. כאן גם מחליטים כיצד לסנכרן את גרסת ה-AMP עם הגרסה הראשית.
- ולידציה. מריצים כל עמוד דרך הוולידטור, מתקנים שגיאות ואזהרות. המטרה — אפס שגיאות קריטיות: אחרת העמוד לא ייכנס לתוצאות המהירות.
- יישום ומסירה. מעלים לפרודקשן, בודקים אינדוקס, מוסרים לצוות תיעוד של התבניות והכללים להוספת עמודים חדשים.
הנקודה המרכזית — סנכרון: גרסת ה-AMP לא צריכה להתקיים בנפרד מהגרסה הראשית. אנו מקשרים ביניהן באמצעות קישורים קנוניים כדי שמנוע החיפוש לא יחשיב זאת לכפילות, ומגדירים בנייה מחדש אוטומטית בעת עדכון התוכן. כך הצוות מפרסם חומר פעם אחת, ושתי הגרסאות נשארות מעודכנות.
לאחר ההשקה אנו עוקבים אחר שיעור העמודים שעברו ולידציה וזמן הטעינה במובייל. אם תבנית נשברת בעת הוספת בלוק חדש — זה נראה מיד, לפני שהעמוד נופל מהתוצאות המהירות.
מה הלקוח מקבל לאחר הטמעת AMP
לאחר הטמעת AMP הלקוח מקבל לא "מודול מופעל", אלא סט ארטיפקטים שלפיהם ניתן לפתח את המערכת ולהעביר אותה לצוות אחר ללא אגדות בעל פה. להלן מה שנשאר בפועל במאגר ובתיעוד הפנימי.
- תצורות תבניות. סט תבניות סימון AMP עם ולידציה בשלב הבנייה: וריאנטים נפרדים לכרטיסי מוצר, מאמרים, קטגוריות ודפי נחיתה. בנוסף, כללים אילו בלוקים מותרים ואילו נחתכים אוטומטית — כדי שמפתח לא ישבור את הסימון ידנית.
- סכמות מטמון. מפה: מה נשמר במטמון בצד ה-CDN, מה בצד האפליקציה, מה תוחלת החיים של כל סוג תוכן וכיצד המטמון מתבטל בעת עדכון. בנפרד — ההתנהגות כאשר המקור אינו זמין, כדי שהדף לא יחזיר תגובה ריקה.
- מדיניות אבטחה. כותרות מוגדרות, הגבלות על תוכן מוטמע, כללי עבודה עם סקריפטים חיצוניים וטפסים. הכול מתועד כך שמפתח חדש לא יכבה את ההגנה בשם "תיקון מהיר".
- תיעוד. תיאור מבנה הפרויקט, נקודות ההרחבה, התלויות וכיצד לשחזר את הבנייה באופן מקומי. עם דוגמאות למשימות טיפוסיות: להוסיף תבנית חדשה, לשנות סימון, לחבר מקור נתונים חדש.
- נהלי עדכון. סדר הוצאת שינויים: כיצד נבדקת תקינות הסימון, אילו בדיקות חובה לפני פרסום, כיצד מבוצעת חזרה לאחור של מהדורה כושלת ומי אחראי על כל נקודה.
- ניטור ודיווח. לוח מחוונים עם מדדים מרכזיים: שיעור הדפים התקינים, מהירות התגובה, שגיאות מטמון. מוגדרות התראות בעת סטייה מהנורמה — הבעיה נראית לפני שהמשתמש מבחין בה.
- הוראות מסירה. רשימת תיוג לקליטת צוות חדש: הרשאות, סביבות, סדר הפריסה, אנשי קשר אחראיים. המסירה אורכת ימים, ולא שבועות של התכתבות.
כל סעיף הוא תוצאה שניתן לבדוק: לפתוח את המאגר, להריץ בנייה, להסתכל בלוח המחוונים. אם בסיום ההטמעה אין ארטיפקטים כאלה — המשמעות היא שהעבודה לא הושלמה, ואנחנו מתעדים זאת ביושר בקבלה.
קייס: האצת התוצאות במובייל לחנות מקוונת
חנות מקוונת עם קטלוג של כמה אלפי פריטים פנתה אלינו עם כאב טיפוסי: התוצאות במובייל נחלשו, והאנליטיקה הראתה שמבקרים עוזבים לפני שהכרטיסים הספיקו להיטען.
המדידות אישרו את ההשערה — בסמארטפונים ברשתות עם כיסוי לא יציב עמוד הקטגוריה נבנה לאט מדי, וחלק ניכר מהביקורים הסתיים בחזרה עוד לפני המסך הראשון.
מה עשינו
חילקנו את הפרונט לשני מעגלים. האתר הראשי נשאר בסטאק הרגיל עם פונקציונליות מלאה, ולעמודי הקטלוג וכרטיסי המוצרים בנינו גרסאות AMP מוקלות: רק סימון קריטי, טעינה נדחית של תמונות, ויתור על סקריפטים חוסמים.
קישורים קנוניים וסימון נתונים מובנים חיברו את שתי הגרסאות כך שמנוע החיפוש יספק למשתמש המובייל את הגרסה המהירה, ולמשתמש הדסקטופ — את המלאה.
בנפרד טיפלנו בתמונות: העברנו את הקטלוג לפורמטים מודרניים, קבענו מידות לקונטיינרים כדי שהפריסה לא "תקפוץ" בזמן הטעינה. מטמון הסטטי הועבר לפריפריה — ביקור חוזר הפך לקל noticeably יותר מהראשון.
תוצאה
| מדד | לפני | אחרי |
|---|---|---|
| זמן טעינה במובייל | 6–7 ש' | 1.5–2 ש' |
| שיעור נטישה בעמודי הקטלוג | ~58% | ~31% |
| מיקומים לפי שאילתות מסחריות | מחוץ לעשירייה הראשונה | טופ-5 בקטגוריות מפתח |
את הפרויקט הוביל המהנדס שלנו, שהיה אחראי על הפרונט והסימון; את העבודה קיבלנו לפי מדידות בתנאים אמיתיים, ולא לפי בדיקות סינתטיות. לאחר ההשקה חלקו של תעבורת המובייל מתוצאות מהירות גדל, וההמרה לסל בעמודים האלה השתפרה בעקבות המהירות.
במה AMP שונה מעיצוב רספונסיבי?
אלו שתי גישות שונות לאותה משימה — להציג עמוד במהירות בכל מסך. עיצוב רספונסיבי הוא פריסה גמישה: אותו סימון מתארגן מחדש לפי רוחב המסך באמצעות מדיה-קווריז, וההתנהגות נקבעת על ידי הסגנונות והסקריפטים שלכם.
AMP הוא פורמט סימון נפרד עם סט תגים משלו וכללים נוקשים: חלק מהאלמנטים המוכרים הוחלפו ברכיבים מובנים, קוד צד שלישי מחובר רק דרך בלוקים מורשים, וסגנונות קריטיים מוטמנים ישירות במסמך.
מכאן ההבדל העיקרי — במידת החופש. רספונסיביות אינה מגבילה: אתם בונים כרצונכם, מחברים כל ספרייה, אנליטיקה ווידג'טים חיצוניים, אך על המהירות והיציבות אתם אחראים בעצמכם — אופטימיזציה של תמונות, טעינה נדחית, סדר הרינדור נופלים על הצוות.
AMP לוקח על עצמו את ההחלטות הללו: כללי הפורמט לא מאפשרים להפיל את הביצועים בטעות, ולכן העמוד עובר בדיקה באופן צפוי ומוצג במהירות באינטרנט סלולרי חלש.
המגבלות של AMP הן בעצם הערובה שלו. אי אפשר להכניס סקריפט צד שלישי שרירותי, סליידר כבד או אנימציה מותאמת אישית ללא רכיב מוכן; חלק מהאינטראקטיביות יש לבנות מחדש עבור האלמנטים הזמינים.
רספונסיביות אינה מציבה מסגרות כאלה, אך גם אינה מגנה מפני רגרסיות: ספרייה כבדה אחת — ומדדי הטעינה צונחים בכל העמודים.
בפועל זה לא "או-או". פריסה רספונסיבית נשארת הבסיס של האתר, ול-AMP יש היגיון כשכבה קלה נפרדת לעמודים שצריכים להיפתח באופן מיידי מתוצאות החיפוש ומהפיד.
אנחנו מנתחים אילו עמודים מרוויחים מהפורמט, ואילו זול יותר להאיץ באמצעים של הרספונסיביות עצמה, ובונים את שתי הגרסאות כך שלא יתנגשו בסימון ובאנליטיקה.
שאלות טכניות נפוצות בנושא עמודי AMP
עמודי AMP מוטמעים באתר קיים ואינם מחליפים אותו: הכתובת הקנונית נשארת במסמך הראשי, והגרסה המקלה מוגשת בכתובת נפרדת ומסומנת ב-rel="amphtml". מנוע החיפוש בוחר בעצמו איזו גרסה להציג בתוצאות החיפוש בנייד, ולכן חשוב ששתיהן יכילו תוכן זהה ומטא-נתונים תקינים. אם הקנוניזציה מוגדרת נכון, AMP לא "גונב" תנועה אלא מרחיב נקודות כניסה.
התמיכה מצטמצמת לשתי פעולות שגרתיות: אימות סימון וסנכרון תוכן. הוולידטור תופס הפרות של כללים מחייבים (תגיות אסורות, סגנונות אינ�ליין מעבר למגבלה, סקריפטים של צד שלישי), ואי-סנכרון תוכן בין הגרסאות הוא הסיבה הנפוצה ביותר לירידת מיקומים. אנחנו סוגרים זאת באמצעות בנייה ממקור אחד: התיקון מוזן פעם אחת, ושתי הגרסאות מתעדכנות יחד.
AMP מתנגש עם הסטאק הנוכחי שלנו — נצטרך לכתוב הכול מחדש?
לא. גרסת ה-AMP נבנית מאותם נתונים ותבניות כמו האתר הראשי — אין צורך לכתוב מחדש את הלוגיקה. המגבלות נוגעות רק לשכבת הלקוח: סקריפטים של צד שלישי מחוברים דרך רכיבים מורשים, והאינטראקטיביות מיושמת באמצעים המובנים. אם בלוק כלשהו אינו ניתן להעברה, הוא נשאר באתר הראשי, ובגרסת ה-AMP מוחלף בקישור לעמוד המלא.
מה יקרה ל-SEO אם נוותר על AMP מאוחר יותר?
החזרה לאחור בטוחה: די להסיר את הסימון rel="amphtml" ולהגדיר הפניה מחדש מהכתובות המקלות לקנוניות. מנוע החיפוש יאנדקס מחדש את העמודים בתוך מספר מחזורי סריקה, והמיקומים נשמרים מכיוון שהכתובת הקנונית לא השתנתה. אנחנו שומרים את ההליך הזה בתיעוד, כך שהמעבר לכל כיוון יארך שעות ולא שבועות.
באיזו תדירות יש לבדוק את האימות לאחר עדכונים?
את האימות מריצים בשלב הבנייה: אם הסימון נשבר, הגרסה לא יוצאת לפרודקשן. בנוסף, אחת לחודש אנחנו בודקים עמודים שכבר פורסמו — עדכונים של מנוע החיפוש משנים לעיתים את הדרישות לתכונות מחייבות. כך ההפרות מתגלות לפני שהעמוד נופל מהתוצאות.
בואו נדון במשימה שלכם לאופטימיזציית AMP
מעבר של אתר ל-AMP הגיוני לא "באופן כללי", אלא למשימה קונקרטית: להאיץ את התוצאות במובייל, להסיר ירידה בשיעור הנטישה, להביא לראש התוצאות קטגוריה שכרגע לא משיגה מספיק תנועה.
לכן את השיחה מתחילים מהנתונים הראשוניים — אילו תבניות עמודים בעדיפות, מאיפה מגיעה התנועה, אילו מדדים נחשבים ליעד. לאחר מכן בוחנים את הסימון הנוכחי ומחליטים היכן AMP יניב רווח והיכן מספיקה אופטימיזציה רגילה.
הערכת לוחות הזמנים נבנית לפי היקף: כמה סוגי עמודים מתרגמים, האם יש בלוקים דינמיים, כיצד בנויה הפריסה ומנוע התבניות. לאחר הניתוח אנו נותנים תוכנית לפי שלבים עם לוחות זמנים ריאליסטיים והבנה מה בדיוק בודקים בכל שלב.
מה כלול בעבודה:
- ניתוח העמודים הנוכחיים ובחירת תבניות לגרסת AMP;
- תכנון סימון AMP והחיבור שלו לגרסה הראשית של האתר;
- הגדרת קישורים קנוניים כדי שהגרסאות לא יתחרו בתוצאות החיפוש;
- בדיקת תקינות הסימון ותיקון שגיאות לפני העלאה לאוויר;
- בדיקת מהירות הטעינה וההתנהגות במובייל;
- חיבור אנליטיקה כדי לראות את האפקט במספרים;
- מסירת תיעוד והדרכת הצוות שלכם לעבודה עם AMP.
את התוצאה מקבעים מראש: אילו עמודים מאיצים, בכמה מקצרים את זמן הטעינה, כיצד עוקבים אחרי מיקומים ונטישות לאחר ההטמעה. לאחר מכן — תמיכה: עוקבים אחרי תקינות הסימון, מעדכנים תבניות בעת שינויים באתר ומנתחים ירידות אם הן מופיעות.
תארו את המשימה — אילו עמודים תרצו להאיץ ואיזו תוצאה נחשבת להצלחה. נחזור עם הערכת לוחות זמנים ותוכנית הטמעה.