העלות הנסתרת של פיתוח וורדפרס "מספיק טוב"
מאת דניאל משקוב, ארכיטקט מערכות AIפורסם עודכן 4 דק׳ קריאה
בקצרה
מחקר של Deloitte, שנעשה בהזמנת Google, מצא ששיפור של 0.1 שנייה במהירות האתר במובייל העלה את ההמרות בקמעונאות ב-8.4%. רוב בעיות הביצועים בוורדפרס הן מבניות: החלטות קוד גרועות, יותר מדי תוספים ותמונות שלא עברו אופטימיזציה. שדרוג אחסון כמעט אף פעם לא פותר אותן, ובכל זאת רוב העסקים משלמים על טיפול בסימפטום ("השרת איטי") במקום בסיבה (הקוד איטי).
למה פיתוח זול יוצא יקר יותר בסוף?
בנייה זולה של אתר וורדפרס מגיעה לא פעם עם עשרות תוספים שהותקנו בלי שום בדיקה. כל תוסף מוסיף קוד PHP, בדרך כלל גם JavaScript ו-CSS, ושאילתות משלו למסד הנתונים. התקינו את התוסף החינמי Query Monitor ופתחו עמוד: באתר מנופח, מספר השאילתות גבוה לא פעם פי כמה ממה שאותו עמוד צריך בבנייה רזה — וכל זה רץ עוד לפני שלדפדפן יש מה להציג.
העלויות הנסתרות צצות חודשים אחר כך: עמוד איטי מבריח גולשים, וגולש שעזב לא קונה. הנתון של Deloitte מבוסס על 37 מותגים ואי אפשר פשוט להעתיק אותו לחנות שלכם, אבל החשבון מפכח גם בלי זה. בחנות שמוכרת ב-₪50,000 בחודש, אפילו ירידה של 2% במכירות היא ₪1,000 בחודש — ₪12,000 בשנה שהולכים לאיבוד בגלל החלטת קוד שהתקבלה כבר בהתחלה.
ועל זה נוספות עלויות התמיכה. בבנייה זולה כמעט אף פעם לא מתעדים מה הותקן ולמה, כך שהמפתח הבא נאלץ להנדס את האתר לאחור לפני כל שינוי, גם פשוט. עבודה שאמורה לקחת אחר צהריים אחד נמשכת כמה ימים.
תרחיש להמחשה: לאן הולך הכסף בשנה הראשונה של בנייה ב-₪3,500
מה באמת מייקר בניית אתר וורדפרס?
עודף תוספים. קוד ה-PHP של כל תוסף פעיל נטען בכל בקשה — גם בעמודים שבהם התוסף לא עושה כלום — ורבים מהתוספים מוסיפים את הסקריפטים וקובצי הסגנון שלהם לכל עמוד. סטאק "תקציבי" נפוץ של ווקומרס, Yoast SEO, אלמנטור, WP Rocket וכמה הרחבות ווקומרס הוא כבר הרבה מאוד קוד, עוד לפני ערכת העיצוב ולפני כל פיתוח מותאם. השאלה לגבי כל תוסף היא לא "האם הוא טוב?" אלא "האם האתר הזה צריך אותו?"
מסד נתונים מנופח. כל טעינת עמוד שולפת מהמסד הגדרות, פוסטים, מטא-נתונים ונתוני משתמשים. שאריות של שנים — הגדרות של תוספים שנמחקו מזמן, נתונים זמניים (transients) שפג תוקפם, גרסאות ישנות של פוסטים — יחד עם אינדקסים חסרים, הופכות שאילתות שאמורות לרוץ בכמה מילישניות לשאילתות שלוקחות חלק מורגש מהשנייה. זה מרגיש כמו בעיית שרת, אבל זו בעיית שאילתות.
תמונות בלי אופטימיזציה. מפתח זול מעלה תמונה של 8 MB ישר מהמצלמה וממשיך הלאה. תמונת תוכן באתר מודרני צריכה בדרך כלל בין עשרות לכמאתיים KB, בפורמט WebP או AVIF ובגודל שמתאים למקום שהיא תופסת בעמוד. בעמוד בית טיפוסי, התמונות הן סוג הקבצים הכבד ביותר — כ-40% מהמשקל בחציון, לפי ה-Web Almanac של HTTP Archive לשנת 2024 (בעמודים פנימיים JavaScript עוקף אותן לא פעם).
למה אחסון לא יפתור את זה
רוב האתרים התקציביים יושבים על אחסון משותף. הפיתוי הוא "לשדרג ל-VPS", מה שבדרך כלל מכפיל את חשבון האחסון. אבל אם הקוד עצמו לא יעיל, שרת מהיר יותר פשוט מריץ קוד איטי קצת יותר מהר. הדפדפן עדיין צריך להוריד ולהריץ את אותו עמוד כבד.
בדקו לפני שאתם משלמים: שכפלו את האתר לעותק staging על השרת המהיר ומדדו את שניהם. זמן התגובה של השרת בדרך כלל ישתפר, אבל ה-LCP לא פעם כמעט לא זז, כי רוב זמן הטעינה עובר בדפדפן ולא בשרת. אם זה מה שאתם רואים, האחסון מעולם לא היה צוואר הבקבוק — הקוד היה, ושרת מהיר יותר לא מתקן קוד איטי.
התיקון הנכון: קודם כול בדקו את הקוד. הסירו תוספים שאינם בשימוש, תקנו את השאילתות האיטיות, דחסו תמונות והפעילו מטמון — ואז מדדו שוב. ניקוי ממוקד כזה הוא עבודת פיתוח חד-פעמית, ובאתר שהבעיה שלו היא הקוד, הוא עושה יותר מכל שדרוג אחסון — בלי שקל נוסף בחשבון החודשי.
כמה באמת עולה קוד "מספיק טוב"
תרחיש להמחשה — הציבו בו את המספרים שלכם: שכרתם פרילנסר שיבנה לכם חנות וורדפרס ב-₪3,500. היא עובדת, אבל נטענת לאט. נניח שהאיטיות עולה לכם ₪2,500 בחודש במכירות שלא קרו; בשנה אלה ₪30,000. אחר כך אתם שוכרים מישהו שיתקן את זה (₪2,500–₪5,000). העלות האמיתית של החנות שעלתה ₪3,500 היא עכשיו ₪36,000–₪38,500.
האלטרנטיבה: לשלם מראש על קוד נקי, אופטימיזציה ותיעוד. הצעת המחיר תהיה גבוהה מ-₪3,500 — טווחי המחירים שמתפרסמים בשוק מופיעים במדריך כמה עולה אתר ב-2026 — אבל המהירות מפסיקה לעלות לכם במכירות כבר מהיום הראשון, ורוב ה-₪30,000 האלה נשארים בעסק.
שאלות נפוצות
איך יודעים אם הבעיה באתר היא בקוד או באחסון?
הריצו Google PageSpeed Insights (https://pagespeed.web.dev/) וקראו את ממצאי הביצועים שמתחת לציון. אם רובם מצביעים על העמוד עצמו — "Reduce unused JavaScript", "Render-blocking requests", "Improve image delivery", "Optimize DOM size" — הבעיה בקוד. אם הממצא העיקרי הוא "Document request latency" (השרת מתעכב בשליחת העמוד), ייתכן שגם האחסון אשם. בדרך כלל זה גם וגם — אבל התחילו מהקוד.
אפשר לתקן בנייה "זולה" לבד?
חלקית. אתם יכולים להסיר תוספים שאינם בשימוש, להתקין מחדש את ערכת העיצוב בצורה נקייה ולדחוס תמונות בעצמכם עם כלים כמו Smush או ShortPixel. ניקוי מסד הנתונים ושכתוב שאילתות דורשים בדרך כלל מפתח. גישה משולבת — אתם עושים את החלקים הקלים, ומפתח עושה את הקשים — עולה חלק קטן ממחיר של בנייה מחדש, ועובדת טוב.