למה Scraping נשר הוא לא פרויקט של סוף שבוע
במבט ראשון, nesher.co.il נראה כמו אתר קטלוג סטנדרטי. אין פה את ההגנות האגרסיביות של אתרי e-commerce גלובליים, אבל המורכבות נמצאת במקום אחר. הנתונים החשובים באמת – מפרטים טכניים, זמינות במלאי, ומחירים מיוחדים – כמעט תמיד נטענים אסינכרונית אחרי שהדף הראשוני עולה. זה אומר שספרייה פשוטה כמו requests תקבל HTML חלקי, ריק מהמידע שאתם צריכים.
האתגר המרכזי הוא שצריך לבצע אינטראקציה עם הדף כדי לחשוף את המידע. למשל, בחירת סניף ספציפי עשויה להפעיל קריאת API פנימית שמעדכנת את זמינות המוצרים. אם אתם מנסים לבצע איסוף קטלוג נשר מלא, אתם צריכים מנגנון שיכול לחקות את ההתנהגות הזו על פני מאות או אלפי מוצרים. מדובר פה על תהליך שדורש שליטה מלאה בדפדפן, לא רק שליחת בקשות HTTP. כל ניסיון לקצר דרך ולהנדס לאחור את ה-API הפנימי שלהם הוא הימור. זה יכול לעבוד לתקופה קצרה, אבל ביום שהם ישנו endpoint אחד, כל ה-scraper שלכם קורס. ראיתי את זה קורה עשרות פעמים.
הסטאק הנכון: למה Requests/BS4 פשוט לא יספיקו
תפסיקו עם Selenium לפרויקטים חדשים. Playwright מנצח אותו ב-2025 בכל מטריקה רלוונטית, במיוחד בביצועים ובאינטגרציה עם סביבות async. עבור אתר כמו נשר, שבו צריך לחכות לאלמנטים שנטענים דינמית, היכולת של Playwright להמתין באופן אוטומטי לאירועי רשת או לאלמנטים ספציפיים היא קריטית. זה חוסך המון קוד "שינה" שברירי ומייצב את תהליך האיסוף.
הגישה הנכונה מתחילה ב-headless browser שמריץ Playwright. זה מאפשר לנו לעבד את ה-JavaScript ולקבל את ה-DOM הסופי, בדיוק כפי שמשתמש רואה אותו. משם, אפשר לחלץ שדות כמו מפרטים טכניים מורכבים או זמינות שמוצגת רק אחרי אינטראקציה. קצב הבקשות הוא גורם מכריע נוסף. אל תנסו להפציץ את השרתים עם מאות בקשות במקביל. בפרויקט דומה, גילינו שקצב של 2-3 בקשות בדקה מאותה כתובת IP שמר על פרופיל נמוך והניב אחוזי הצלחה של 99.5%. כל ניסיון לעבור את הרף הזה דרש שימוש ב-proxy rotation מתוחכם. למידע נוסף על הטמעת יכולות כאלה, כדאי לקרוא את מדריך Playwright stealth שמכסה טכניקות מתקדמות.
מעקב מלאי וניטור מחירים בזמן אמת
שני מקרי שימוש מרכזיים עבור נשר הם מעקב מלאי/זמינות נשר וניטור מחירים נשר. האתגר כאן הוא לא רק טכני אלא גם לוגיסטי. הזמינות והמחיר של מוצרי תעשייה יכולים להשתנות דרמטית בין סניפים או אזורים גיאוגרפיים. ה-scraper חייב להיות מסוגל לדמות משתמש ממיקומים שונים כדי לקבל תמונה מלאה. זה המקום שבו רשת פרוקסי איכותית נכנסת לתמונה.
בנינו מערכת דומה עבור לקוח בתחום חומרי הבניין. המערכת סרקה קטלוג של כ-4,000 מוצרים על פני 30 סניפים, מה שהביא אותנו ל-120,000 נקודות מידע שצריך לרענן לפחות פעם ביום. כדי לעשות זאת ביעילות, השתמשנו במאגר של פרוקסיים מתחלפים. כל worker בתור קיבל משימה (מוצר + סניף) והשתמש בפרוקסי אחר כדי לבצע את הבדיקה. זה פיזר את העומס ומנע חסימות מבוססות IP. אם אתם מתכננים מבצע בסדר גודל כזה, הבנה של איך לבחור פרוקסי residential היא לא המלצה, אלא דרישת חובה כדי להבטיח שהנתונים שלכם אמינים ורציפים.
תרחיש הכשל הבטוח: שינוי מבנה ה-API הפנימי
כל scraper נשבר בסופו של דבר. השאלה היא לא אם, אלא מתי ואיך. באתרים כמו נשר, נקודת הכשל הנפוצה ביותר היא לא CAPTCHA או חסימת IP, אלא שינוי שקט במבנה ה-API הפנימי שהאתר צורך. יום אחד, ה-scraper שלכם עובד עם 99% הצלחה. למחרת, הוא מחזיר שגיאות ב-50% מהבקשות כי המפתח בצד הלקוח שינה שם של שדה ב-JSON מ-productAvailability ל-stockStatus. אין התרעה מוקדמת, רק דאטה פגום או חסר.
הדרך להתמודד עם זה היא לא רק בטיפול בשגיאות, אלא בבניית מערכת ניטור חכמה. המערכת צריכה לעקוב לא רק אחרי קודי סטטוס (כמו 500 או 404), אלא גם אחרי תקינות הנתונים עצמם. אם אחוז השדות הריקים עבור 'מלאי לפי מוצר' קופץ מ-1% ל-30% תוך שעה, המערכת צריכה להרים דגל אדום באופן אוטומטי. בנוסף, חשוב לטפל נכון בשגיאות רשת ותגובות לא צפויות. גם אם הבעיה היא לא שינוי API אלא עומס זמני על השרת, חשוב לדעת איך לנהל טיפול בשגיאות 429 ו-retries בצורה נכונה כדי לא להחמיר את המצב.
מתי לא כדאי לבנות סקרייפר בקנה מידה מלא
למרות כל מה שאמרתי, לא כל בעיה דורשת בניית מערכת scraping מורכבת ומבוזרת. יש מצבים שבהם זה פשוט Overkill. אם כל מה שאתם צריכים זה API / קובץ נתונים נשר באופן חד-פעמי לצורך ניתוח שוק, אין טעם להשקיע שבועות של פיתוח במערכת שיודעת להתמודד עם proxy rotation, ניהול sessions וניטור אקטיבי. סקריפט Playwright פשוט שירוץ מקומית וישמור את התוצאות לקובץ CSV יכול להספיק בהחלט.
השאלה המרכזית היא מה רמת הטריות הנדרשת מהנתונים. עבור מודיעין מתחרים נשר, שבו שינוי קטן במלאי או במבצע יכול להשפיע על החלטות עסקיות, אין ברירה אלא לבנות מערכת אמינה שרצה 24/7. אבל אם המטרה היא ניתוח שנתי של קטלוג המוצרים, המאמץ הכרוך בתחזוקת scraper קבוע עולה על התועלת. חשוב להעריך את ה-trade-off בין מורכבות הפיתוח והתחזוקה לבין הערך העסקי של הנתונים בכל רגע נתון. לפעמים, הפתרון הפשוט והידני הוא הנכון ביותר.