Headless CMS היא מערכת ניהול תוכן שמנהלת ושומרת את התוכן, אבל לא מציגה אותו בעצמה: היא מוסרת אותו דרך API, ואת החזית — האתר, האפליקציה, המסך בחנות — בונים בנפרד. ב-CMS רגיל (כמו וורדפרס בשימוש הנפוץ), אותה מערכת מנהלת את התוכן וגם מייצרת את עמודי האתר. ב-headless, "הראש" — שכבת התצוגה — מנותק מה"גוף". זו ארכיטקטורה שמתאימה מאוד לחלק מהפרויקטים, ומוסיפה סיבוך מיותר לאחרים.
CMS רגיל מול headless
| CMS רגיל | Headless CMS | |
|---|---|---|
| מי מציג את התוכן | ה-CMS עצמו, דרך תבנית | אפליקציית חזית נפרדת |
| איך התוכן יוצא | עמודי HTML | API שמחזיר נתונים (לרוב JSON) |
| כמה ערוצים | בעיקר אתר אחד | אתר, אפליקציה וערוצים נוספים מאותו תוכן |
| תוספים לתצוגה | עובדים כרגיל | רבים לא עובדים — החזית לא שלהם |
| תחזוקה | מערכת אחת | שתי מערכות לפחות |
וורדפרס כ-headless
וורדפרס יכולה לשמש גם כ-headless CMS. לפי ה-handbook הרשמי, ה-REST API של וורדפרס מספק ממשק שדרכו אפליקציות מדברות עם האתר, ומאפשר להביא את התוכן לאפליקציות נפרדות לגמרי — כל תוכנה שיודעת לשלוח בקשות HTTP ולקרוא JSON יכולה להשתמש בו. כך העורכים ממשיכים לעבוד בממשק המוכר של וורדפרס, והחזית נבנית בטכנולוגיה אחרת. פירוט על ה-API בREST API בוורדפרס.
לצד זה יש מערכות שנבנו מראש כ-headless, בלי שכבת תצוגה בכלל, שמתמקדות במודל התוכן וב-API.
מתי headless מתאים
- אותו תוכן בכמה ערוצים — אתר, אפליקציה, מסכים — ממקור אחד.
- חזית אינטראקטיבית מאוד — ממשק שמתנהג כמו אפליקציה, עם צוות שעובד בטכנולוגיות חזית מודרניות.
- תוכן כחלק ממוצר — למשל טקסטים והגדרות שמוצגים בתוך מערכת SaaS, לצד האתר השיווקי.
- הפרדה בין צוותים — צוות תוכן וצוות פיתוח שעובדים בקצב שונה.
מתי זה מיותר
לרוב אתרי העסקים — אתר תדמית, אתר שירותים, בלוג, ואפילו אינדקס — headless מוסיף עלויות בלי תועלת מקבילה:
- שתי מערכות לתחזק — ה-CMS והחזית, עם עדכונים, אבטחה ואחסון נפרדים.
- תצוגה מקדימה — העורך רוצה לראות איך המאמר ייראה לפני פרסום; ב-headless צריך לבנות את זה.
- תוספים — תוספי SEO, טפסים ונגישות שמשפיעים על התצוגה לא עובדים אוטומטית בחזית נפרדת. כל מה שהם עשו — כותרות, מטא, נתונים מובנים, מפות אתר — צריך לממש מחדש.
- רינדור לגוגל — חזית שמציגה תוכן רק בדפדפן דרך JavaScript דורשת תשומת לב לכך שגוגל ומנועים אחרים יקבלו HTML מלא. ראו אתר JavaScript וגוגל.
חלופה באמצע: CMS רגיל עם קוד נקי
הרבה פעמים מה שאנשים מחפשים כשהם שומעים "headless" הוא בעצם אתר מהיר, עם קוד נקי ותוכן מסודר. את זה אפשר לקבל גם ב-CMS רגיל: וורדפרס עם תבנית ייעודית בלי בונה עמודים, סוגי תוכן מותאמים ושדות מותאמים — כך התוכן מובנה ונקי, ואם בעתיד יידרש ערוץ נוסף, ה-REST API כבר קיים. כך בנוי גם האתר הזה: וורדפרס עם תבנית ייעודית.
שאלות לפני שבוחרים headless
- באילו ערוצים התוכן יוצג — היום ובעוד שנתיים?
- מי יתחזק את החזית, ואיזה ידע נדרש לזה?
- איך עורכים יראו תצוגה מקדימה?
- מה יחליף את התוספים שמטפלים בכותרות, מטא, מפות אתר ונגישות?
- איך הדפים יוגשו לגוגל — רינדור בשרת, יצירה מראש, או בדפדפן?
השוואה רחבה יותר בין פלטפורמות באיך בוחרים פלטפורמה לאתר.
שאלות נפוצות
האם headless מהיר יותר?
לא אוטומטית. המהירות תלויה באופן שבו החזית בנויה ומוגשת. אתר רגיל עם קוד נקי ומטמון טוב יכול להיות מהיר מאוד.
האם headless מאובטח יותר?
הפרדה יכולה להקטין את החשיפה של מערכת הניהול, אבל יש שתי מערכות לאבטח במקום אחת.
מה ההבדל בין headless ל-decoupled?
המונחים משמשים לעיתים לסירוגין. בדרך כלל decoupled מתאר CMS שעדיין יכול להציג עמודים בעצמו, אבל משמש גם כמקור תוכן לחזית נפרדת.
אני בונה גם מערכות ניהול תוכן ייעודיות וגם אתרי וורדפרס, ובוחר ארכיטקטורה לפי מה שהפרויקט צריך — לא לפי מה שאופנתי. ראו מערכת ניהול תוכן בהתאמה אישית או ספרו לי על הפרויקט.
אהבתם את המאמר?
