From Snooze to Cruise: Turbocharge Landing Pages with Go & NextJS

דפי נחיתה מהירים עם Go ו-NextJS: איך עושים מעבר בלי לשבור SEO

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

עומרי יוספי, Engineering Manager ב-ZipRecruiter בזמן ההרצאה, מציג case study של דפי נחיתה ב-Go ו-NextJS. זה לא סיפור על framework שניצח. זה סיפור על ארכיטקטורה שמחזיקה SEO, על POC שמקבל מטריקות לפני שיש קוד, ועל החלטה לא לסכן מוצר שמביא טראפיק משמעותי רק כדי לקבל פרונטנד נעים יותר.

למה דפי נחיתה מהירים הם בעיית SEO ולא רק בעיית ביצועים

המערכת שעליה עומרי מדבר מייצרת ומרנדרת דפי נחיתה עבור הגעה אורגנית של מחפשי עבודה ל-ZipRecruiter. כשהיא הוקמה, המטרה הייתה להגדיל SEO visits. הצוות בחר ב-Go וב-Server Side Rendering כי מהירות התגובה של השפה התאימה בדיוק לבעיה הזאת.

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

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

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

כשהפתרון הישן מפסיק לשרת את המפתחים

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

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

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

שלוש אפשרויות, ושלושה סוגי סיכון

האפשרות הראשונה הייתה שמרנית: להחליף את Hero ב-template engine מתוחזק. המאמץ קטן, סיכון האבטחה יורד, והביצועים אמורים להישאר כמעט זהים. אלא שהפרונטנד נשאר באותו מודל עבודה, בלי React ובלי התאמה ל-design system.

האפשרות השנייה הייתה מעבר מלא ל-NextJS. היא הייתה פותרת את חוויית הפיתוח ומקרבת את המערכת לסטנדרט הארגוני: רכיבי React, פיתוח מקומי טוב יותר ו-Server Side Rendering. אבל היא דרשה להחליף שבע שנים של קוד frontend ו-backend. יותר קוד לשנות הוא יותר מאמץ, יותר סיכון, ויותר נקודות שבהן טראפיק קריטי יכול להיפגע.

האפשרות השלישית הייתה ההיברידית. Go נשארת אחראית ללוגיקה העסקית ול-backend. NextJS מקבלת ממנה את הנתונים שרוצים להציג ומרנדרת את דפי הנחיתה. זו הפרדה ברורה: המערכת שכבר יודעת לשרת מהר לא נזרקת, והפרונטנד מקבל רכיבי React וחוויית פיתוח מודרנית.

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

הבחירה לא מבטלת tradeoff. הרינדור עובר דרך NextJS, ולכן יש סיכון ביצועים לעומת template engine שרץ כולו ב-Go. אבל הסיכון קטן יותר ממעבר מלא, והערך למפתחים גדול יותר מהחלפת template engine בלבד.

POC הוא לא דמו - הוא מנגנון קבלת החלטות

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

ה-POC חולק לשלושה milestones. הראשון היה Hello World: endpoint חדש ב-Go מחזיר ערך JSON, ואפליקציית NextJS מציגה אותו. השני הפך את הדף לדינמי: Go מחזירה רשימת משרות, ו-NextJS מרנדרת קומפוננטות שמציגות אותן. השלישי כבר מתקרב למימוש אמיתי: template חדש שנכתב בארכיטקטורה החדשה.

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

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

הצוות לא הסתפק בתחושה ש-NextJS נראה טוב. הוא הגדיר מראש שני success criteria. הראשון הוא server response time: ההשוואה היא מול דף זהה בארכיטקטורה הקיימת, עם תוספת latency נסבלת של עד 50ms. ההנחה הייתה שעלייה כזאת לא תפגע באופן קיצוני ב-crawling budget, ולכן עשויה להיות tradeoff ראוי.

השני הוא Lighthouse. המטרה הייתה ציון 90 ומעלה בכל הקטגוריות שהוצגו - performance, accessibility, best practices ו-SEO. אלה לא הבטחות כלליות של “המערכת החדשה מודרנית”. אלה מספרים שאפשר להציג למקבלי החלטות.

תמיד תמיד תמיד תתחילו ב-POC לפני שאתם מקבלים החלטות טכניות.

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

מה לקחת למיגרציה הבאה שלכם

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

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