מדוע דפי AMP מאבדים מראה וולידציה בעת העברה
בעת העברת דפי AMP בין סביבות, לרוב נשברת לא הלוגיקה אלא התצוגה: התבנית נבנתה עבור מערכת אחת של קומפוננטות, ובשלב הקבלה היא נופלת להקשר אחר — והוולידציה של AMP מתחילה להציף שגיאות על דבר של מה בכך.
הסיבה כמעט תמיד אחת: התצוגה הותאמה ידנית, בלי הישענות על מערכת קנונית של קומפוננטות AMP, ולכן חלק מהתגים נשארו HTML "רגיל", וחלק מהאלמנטים המותאמים חוברו עם מאפיינים שגויים.
הכשל הטיפוסי השני — חוסר סנכרון של סגנונות בעת העברת התצוגה. CSS אינטרנאלי, ש-AMP דורש להחזיק בתוך <style amp-custom>, בעת העתקה בין סביבות או משוכפל, או נחתך לפי המגבלה, והדף מאבד את מראהו: הגריד זז, הגופנים מוחלפים, הבלוקים קורסים.
בנפרד צצות שגיאות תצוגה בבלוקים דינמיים — קרוסלות, אקורדיונים, טפסי הרשמה: המקבילות שלהם ב-AMP דורשות מבנה מוגדר בהקפדה, וכל סטייה לא עוברת את הוולידטור.
המקור השלישי לבעיות — אינטגרציה עם הבקאנד. כאשר התבנית מחוברת לנתונים אמיתיים, לתצוגה נכנסים מאפיינים ועטיפות שלא היו במוקאפ הסטטי, והתאמת תבניות הופכת למעבר ידני: מתקן בלוק אחד — נשבר הבלוק הסמוך. בלי בדיקה אוטומטית בכל שלב, תיקונים כאלה מצטברים וצפים כבר בפרודקשן.
אנו מפרקים את הכשלים האלה לפי הסדר: היכן בדיוק אובדת ההתאמה של התצוגה, אילו קומפוננטות לא עוברות ולידציה של AMP, וכיצד לבנות את ההעברה כך שהסגנונות והמבנה יגיעו לפרודקשן בלי התאמות ידניות.
מה נותנת ווירטואליזציה תקינה של דפי AMP
סימון AMP תקין אינו "גרסה מואצת של האתר", אלא חוזה נפרד עם הדפדפן: כללים נוקשים לגבי סגנונות אינ�лайн, גדלים קבועים למדיה ואיסור על סקריפטים חוסמים.
כאשר הסימון נבנה לפי המפרט של AMP, הדף מוגש מהמטמון של מנוע החיפוש ומציג תוכן כמעט מיד בערוץ המובייל, ולא לאחר טעינת החבילה הראשית.
מהירות ויציבות ההגשה
תבנית שנבנתה כראוי מונעת ריקומפוזיציה של הפריסה: גדלי התמונות ומשבצות הפרסום מוגדרים מראש, וסקריפטים של צד שלישי מועברים לרכיבים מותרים. בפועל זה נותן טעינת מסך ראשון בתוך כמה שניות גם בחיבור מובייל חלש ואפס תזוזת תוכן — המשתמש לא "קופץ" בדף בזמן שהוא מצטייר.
אינדוקס ותוצאות מובייל
דף AMP תקין נכנס לאינדקס נפרד ומקבל ייצוג מורחב בתוצאות המובייל — קרוסלה ותצוגה מהירה. שגיאות ולידציה שוברות זאת: מבנה אחד לא חוקי בסימון, והדף נופל מאינדקס ה-AMP, בעודו מוגש כדף רגיל. לכן אנחנו מחזיקים ולידציה בבנייה, ולא בודקים ידנית לאחר השחרור.
הפחתת נטישות בעת עדכונים
המחלקה העיקרית של נטישות AMP — רגרסיות בעת עריכות בסימון: בלוק חדש שובר את הסכימה, עדכון רכיב משנה את הסימון. אנחנו מקבעים את חוזה התבנית בבדיקות ובודקים כל בנייה מול המפרט — עדכונים מפסיקים "להפיל" דפים, והמהירות ויציבות התצוגה נשארות צפויות מגרסה לגרסה.
גישות לבניית AMP: תבניות, רכיבים, היברידי
הבחירה באופן בניית שכבת ה-AMP קובעת באיזו מהירות הדף ייכנס לאינדקס וכמה משאבים יידרשו לתחזוקתו. AMP טהור הוא סט נפרד של תבניות, שבו הסימון מוגבל לסט מותר של רכיבי AMP, וכל האינטראקטיביות מועברת אל <amp-script> או מוחלפת בבלוקים תקניים.
סימון היברידי משאיר את האתר הראשי כפי שהוא, ואילו גרסת ה-AMP נבנית מאותם נתונים דרך שכבת תבניות נפרדת, המקושרות בקישורים קנוניים. בנייה רכיבית הולכת רחוק יותר: הדף מורכב מרכיבי AMP לשימוש חוזר, שכל אחד מהם עובר ולידציה בנפרד.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| AMP טהור | מדורי תוכן, חדשות, דפי נחיתה ללא אינטראקטיביות מורכבת | מגבלות נוקשות על סקריפטים, תחזוקה נפרדת של הסימון |
| היברידי עם האתר הראשי | אתר גדול עם בק-אנד ומנוע תבניות קיימים | נדרשת סנכרון נתונים וקישורים קנוניים בין הגרסאות |
| בנייה רכיבית | קטלוגים, כרטיסים, בלוקים חוזרים | דורש מרשם רכיבים ומשמעת ולידציה |
מה קובע הבחירה בווריאנט
AMP טהור מעניק מהירות טעינה צפויה וסיכון מינימלי לשגיאות ולידציה, אך כל שינוי בתוכן דורש עריכת תבנית נפרדת. ההיברידי מסיר כפילות: הנתונים נלקחים ממקור אחד, ושכבת ה-AMP נשארת דקה. בנייה רכיבית מנצחת בקנה מידה — בלוק חדש מורכב מרכיבי AMP מוכנים, ולא נכתב מאפס.
כיצד זה משפיע על התחזוקה
הצומת המרכזי — קישורים קנוניים: הדף הראשי מפנה לגרסת ה-AMP, וגרסת ה-AMP מחזירה קנון לדף הראשי. אם הקשר מוגדר שגוי, מנועי החיפוש רואים כפילויות ומאבדים את שתי הגרסאות מהתוצאות. אנו מקבעים כלל זה בתבניות, כדי שלא יהיה תלוי בעריכות ידניות בכל שחרור.
בפועל אנו בוחרים לרוב בהיברידי עם בנייה רכיבית של בלוקים: הוא אינו שובר את האתר הקיים ומשאיר מרווח לפיתוח. ננתח איזה וריאנט סוגר את המשימה שלכם.
שלבי הטמעת AMP-וёрстки تحت ключ
העבודות מתנהלות באיטרציות: תחילה מתעדים מה בדיוק בסימון הנוכחי מונע מעבר ולידציה, לאחר מכן מרכיבים את הרכיבים ורק אחרי כן מחברים את AMP לעמודים החיים. סדר זה מאפשר לא לשכתב תבניות פעמיים ולשמר את הלוגיקה הקיימת של הצגת התוכן.
כיצד בנוי התהליך
- ביקורת סימון. מוציאים את ה-HTML הנוכחי של התבניות המרכזיות, מחפשים תגים אסורים, סגנונות אינניינים, סקריפטים של צד שלישי ומאפיינים לא תקניים. בפלט — מפת בעיות עם עדיפויות: מה חוסם ולידציה, מה שובר את הפריסה, ומה ניתן להשאיר.
- סכמת רכיבים. מפרקים את העמוד לבלוקים לשימוש חוזר: גלריה, קרוסלה, טופס, וידאו מוטמע, אקורדיון. עבור כל אחד בוחרים רכיב AMP ומתארים אילו נתונים הוא מקבל, כדי שלא יהיה צורך לשנות את מנוע התבניות עבור כל עמוד.
- הגדרת AMP. מחברים את הריצה החובה, רושמים קישורים קנוניים וקישורי AMP, מגדירים מטמון וכותרות תגובה. בנפרד סוגרים את האנליטיקה — מונים מועברים לרכיבים מותרים ללא אובדן אירועים.
- פריסה וסגנונות. מעבירים את העיצוב למערכת CSS מותרת, מגבילים את נפח הסגנונות ומסירים כל מה שגורם לחישוב מחדש של הפריסה בעת הטעינה. זה גם מסיר קפיצות תוכן בעת הרינדור.
- בדיקה עם ולידטור. מריצים כל סוג עמוד דרך הוולידטור, מפרקים שגיאות ואזהרות עד לאפס. בנפרד בודקים התנהגות בחיבור איטי ובמסכים ניידים.
- מסירת הפרויקט. מוסרים את המאגר עם התבניות, את תצורת הבנייה, את רשימת הבדיקה לוולידציה ואת ההוראות להוספת בלוקים חדשים. מראים כיצד לשחזר מקומית את הבדיקה לפני שחרור.
- תמיכה. עוקבים אחרי שינויים בדרישות לסימון ומעדכנים את התבניות, כדי שעריכות תוכן חדשות לא יפילו את הוולידיות.
כל שלב מסתיים בארטיפקט שניתן לבדוק: מפת בעיות, סכמת בלוקים, תבנית מוגדרת, דוח ולידטור. בזכות זה ההטמעה מתנהלת בצורה צפויה, והתמיכה לא הופכת לתיקון חד-פעמי אחרי כל פרסום.
מדיניות חיבור AMP ואינטגרציה עם האתר הראשי
החיבור בין גרסת ה-AMP לאתר הראשי נשען על שלושה כללים: קנוניזציה, הפניות ומטמון. אם לפחות אחד מהם מוגדר באופן שגוי, מנועי החיפוש מתחילים להתייחס לעמוד ה-AMP כמסמך עצמאי — והדירוגים של שתי הגרסאות נפגעים. לכן אנו קובעים את מדיניות החיבור לפני פרסום העמוד הראשון, ולא אחריו.
קנוניזציה — כלל בסיסי: כל עמוד AMP מפנה לגרסה המלאה דרך rel="canonical", והגרסה המלאה מפנה ל-AMP דרך rel="amphtml". הקישורים חייבים להיות הדדיים ולהצביע על אותו URL בדיוק ללא פרמטרים וללא כפילויות עם לוכסן. עבור פרויקטים רב-לשוניים אנו מוסיפים hreflang לשתי הגרסאות, אחרת העתקים בשפות שונות מתחרים זה בזה.
מטמון AMP פועל אחרת מאשר באתר רגיל: הסימון מוגש עם מטמון CDN, ולכן עדכון התוכן מגיע למשתמש באיחור. אנו מגדירים כללי אינדוקס ואיפוס מטמון כך שעריכות באתר הראשי ישתקפו בגרסת ה-AMP באופן צפוי, ולא "מתישהו".
סנכרון תוכן — נקודת הכשל הנפוצה ביותר בתחזוקה ידנית. אנו בונים אותו על מקור נתונים יחיד: כותרת, טקסט, תמונות וסימון נוצרים ממודל אחד, ותבנית ה-AMP רק פורשת אותם אחרת. כך פער בין הגרסאות בלתי אפשרי פיזית.
- קנוניזציה הדדית וקישורי
amphtmlלכל זוג עמודים - כללי הפניה: מ-AMP לגרסה המלאה ובחזרה ללא שרשראות
- מדיניות מטמון ואיפוס מטמון בעת עדכון תוכן
- סכמת סנכרון ממקור נתונים יחיד
- כללי אינדוקס:
robots.txt, מפת אתר, החרגת פרמטרים פנימיים - נוהל בדיקה לאחר עלייה לאוויר: ולידציה של סימון והצלבת קישורים קנוניים
סט מדיניות כזה מסיר את הסיכון המרכזי של AMP — פיצול התוכן, כאשר מנוע החיפוש אינו מבין איזו גרסה להציג. תארו את האתר שלכם ואת מבנה ה-URL הנוכחי — נחזור עם הערכה ותוכנית חיבור.
מה הלקוח מקבל לידיו לאחר וёрстки AMP
לאחר מסירת הפרויקט נשארת בידיכם לא ערכת קבצים "כפי שיצא", אלא מערכת עובדת שניתן להעביר לכל מפתח או קבלן משנה בלי לאבד את ההקשר. להלן — מה בדיוק נכלל באספקה.
- קונפיגורציות AMP — פרופילי בנייה וולידציה עובדים: הכללים שלפיהם נבדק העמוד לפני פרסום, וההגדרות שמסננות תגים וסקריפטים אסורים בשלב הבנייה ולא לאחר ההעלאה.
- סכמות רכיבים — מפה של בלוקים לשימוש חוזר (קרוסלה, אקורדיון, טופס, גלריה) עם תיאור אילו מאפיינים וסלוטים יש לכל אחד, כדי שבלוק חדש ייבנה מחלקים מוכנים ולא ייכתב מאפס.
- מדיניות מטמון והפצה — תקנון מה נשמר במטמון ולכמה זמן, כיצד הוא מבוטל בעת עדכון תוכן וכיצד מתנהג העמוד כאשר המקור הראשי אינו זמין.
- תיעוד אינטגרציה — כיצד גרסת ה-AMP מקושרת לאתר הראשי: כללי קישורים קנוניים, סנכרון תוכן והתנהגות בעת אי-התאמה בין גרסאות.
- תקנון עדכון — סדר שלב-אחר-שלב להוצאת שינויים: היכן נערך הסימון, כיצד מורצת הוולידציה, מי מאשר את הפרסום וכיצד מבצעים rollback לגרסה הקודמת.
- הוראות לעורכים — מה ניתן לשנות בתוכן בלי מפתח, ומה דורש עריכת רכיב, עם דוגמאות למשימות טיפוסיות.
- צ'ק-ליסט קבלה — רשימת בדיקות לפני כל ריליס: תקינות הסימון, מהירות הטעינה, נכונות התצוגה במובייל, פעולת הטפסים והמעברים.
כל ארטיפקט מלווה בהסבר קצר "לשם מה" — כדי שכעבור חצי שנה מהנדס חדש יבין את ההיגיון של ההחלטות ולא יפענח אותו מתוך הקוד. אם כבר יש לכם עמודי AMP, נרכיב ערכה זהה עבור הפרויקט הנוכחי ונקבע מה בה סוטה מהכללים העובדים.
במה שונה פריסת AMP מפריסה רספונסיבית רגילה
פריסה רספונסיבית רגילה פותרת משימה אחת: לסדר מחדש בלוקים בהתאם לרוחב המסך. AMP מוסיפה לכך שלד מחייב של סימון, שהדפדפן וסורק החיפוש בודקים לפני הרינדור. כאן אי אפשר לחבר סקריפט שרירותי ולתלות מאזין על כל אלמנט — מערך הרכיבים קבוע, והלוגיקה מועברת למאפיינים דקלרטיביים. בדיוק משום כך דף AMP נטען באופן צפוי, אך דורש משמעת אחרת בפריסה.
ההבדל המרכזי הוא במודל ההתנהגות. בפריסה רספונסיבית אתם שולטים בדף באמצעות קוד משלכם: מאזיני אירועים, טעינה דינמית, ווידג'טים של צד שלישי. ב-AMP קוד צד שלישי מוחלף ברכיבים מוכנים — קרוסלה, אקורדיון, לייטבוקס, טופס, וידאו מוטמע.
כל אחד מוצהר בתג עם מאפיינים חובה, ומידות האלמנט נקבעות מראש כדי שהסימון לא "יקפוץ" בזמן הטעינה. זה מסיר סוג של הזזות תוכן שבגללן המבקר מפספס את הכפתור.
המגבלות נוגעות לא רק לסקריפטים. הסגנונות נשמרים במקום אחד ומוגבלים בנפחם, מאזינים מוטבעים כמו onclick אסורים, והטמעות צד שלישי עוברות דרך רשימה מאושרת. בתמורה הדף מקבל סדר רינדור צפוי: קודם תוכן, אחר כך אינטראקטיביות.
עבור הלקוח משמעות הדבר היא שהפיד, הגלריה או הטופס עובדים באותו אופן גם בחיבור מובייל חלש וגם בדסקטופ.
ההבדלים בגישות מתבטאים גם בתחזוקה. פריסה רספונסיבית מתוקנת נקודתית — שינו בלוק, בדקו בדפדפן. דף AMP לאחר כל תיקון מריצים דרך ולידטור: אי-התאמה בסימון שוברת אותו כולו, ולא אלמנט בודד. לכן בתהליך משלבים בדיקה אוטומטית בבנייה — אז השגיאה צפה לפני הפרסום, ולא בפרודקשן.
המסקנה המעשית: AMP לא מחליפה פריסה רספונסיבית, אלא נבנית מעליה. הגריד, הטיפוגרפיה ונקודות השבירה נשארים רגילים, משתנים כללי חיבור הלוגיקה והרכב הרכיבים. אם באתר כבר יש פריסה רספונסיבית, המעבר ל-AMP הוא עיבוד מחדש של האינטראקטיביות והסימון, ולא כתיבה מחדש של העיצוב מאפס.
מקרה בוחן: כיצד דפי AMP הפסיקו להישבר בעת עדכונים
הלקוח — פורטל חדשות עם זרם פרסומים ועשרות תבניות של דפי AMP. כל שחרור של תבנית הביא עמו את אותה התוצאה: חלק מהדפים הפסיקו לעבור ולידציה, פיד הקרוסלה של AMP איבד מיקומים, והמערכת למדה על כך ממנועי החיפוש ולא מהבדיקות שלה עצמה. חקרנו את הסיבה ובנינו מחדש את התהליך.
מה היה לפני
הוולידציה הופעלה ידנית ורק על כמה דפים "לדוגמה". השאר נבנו מאותם בלוקים, אך עם סטים אחרים של פרמטרים — ואותם בדיוק נשברו: מאפיינים אסורים, רכיבים מקוננים, סגנונות מתנגשים. שיעור הדפים הלא-תקפים לאחר שחרור הגיע ל-18%, והחזרה לאחור דרשה שעות של תיקון ידני. זמן התגובה של חלק מהדפים גדל בגלל תמונות לא ממוטבות ובקשות מיותרות.
מה שינו
בנינו ספרייה של רכיבי AMP עם סט קבוע של פרמטרים מותרים — הבנייה הפסיקה להיות תלויה במי ואיך בונה את הדף. הוולידציה שולבה בצינור: כל בנייה מריצה את כל התבניות והשילובים שלהן, וגרסה לא-תקפה פשוט לא נכנסת לשחרור. הוספנו בדיקה על נתונים אמיתיים של המערכת, ולא על תרשימים מדומים.
מה התוצאה
שיעור הדפים הלא-תקפים ירד מ-18% לאפס — בנייה עם שגיאה לא מגיעה לפרסום. תקלות בשחרורים הצטמצמו מכמה בשבוע למקרים בודדים, וכל אחד מהם מנותח לפי לוגים בדקות ולא בשעות. זמן התגובה של הדפים ירד בכשליש בערך הודות למיטוב תמונות וצמצום בקשות. המערכת הפסיקה להיות תלויה במפתחים בעת הפרסום.
AMP — תקן פתוח לדפים מהירים למובייל, שבו אנו משתמשים כבסיס לתבניות מהירות עם ולידציה צפויה.
בואו נדון במשימה שלכם בנוגע ל-AMP
כדי שהערכה של AMP תהיה מציאותית ולא "על העין", אנחנו צריכים נתוני קלט על העמוד הנוכחי שלכם ועל האופן שבו הוא אמור לעבוד לאחר ההמרה. ככל שהתמונה ההתחלתית מדויקת יותר, כך יהיו פחות תיקונים בשלב הקבלה והלוחות זמנים יהיו צפויים יותר.
מה עוזר לחדד את המשימה ולהאיץ את ההערכה:
- קישורים לעמודים הנוכחיים שאתם מתכננים להמיר ל-AMP, ולעמוד הייחוס שאליו אתם שואפים מבחינת מראה והתנהגות.
- אילו בלוקים קריטיים: גלריות, טפסים, מחשבונים, וידאו מוטמע, מפות, ביקורות, פידים של מוצרים.
- מאיפה מגיע התוכן — תבניות סטטיות, CMS, מקור חיצוני, ומי אחראי על עדכונו.
- כיצד בנויה האנליטיקה ואיסוף הפניות: אילו אירועים צריכים להגיע למערכות החשבונאות לאחר המעבר.
- דרישות לתצוגה בחיפוש ולכתובות קנוניות, כדי לא לאבד תנועה שכבר נצברה.
- מגבלות עיצוב ומותג שאסור להפר בעת הרכבת הרכיבים.
- גישות למאגר הקוד, לסביבת הבדיקה ולפאנל הניהול — כדי לא לבזבז זמן על תיאומים.
על סמך הנתונים האלה אנחנו מרכיבים תוכנית עבודה: ניתוח הסימון הנוכחי, תכנון רכיבים, הרכבת תבניות, מעבר ולידציה, אינטגרציה עם אנליטיקה וטפסים, בדיקה על מכשירים אמיתיים ומסירה עם תיעוד. בתמורה אתם מקבלים הערכה לפי שלבים, הרכב הצוות ולוחות זמנים עם מרווח לתיקונים לאחר האיטרציה הראשונה.
תארו את המשימה ושלחו את מה שכבר קיים — נחזור עם הערכת AMP, תוכנית עבודה ולוחות זמנים לפרויקט שלכם.
