Mikä on headless CMS? Ero perinteiseen CMS:ään

01Mikä sisällönhallintajärjestelmä on?

Sisällönhallintajärjestelmä (CMS) on ohjelmisto, jonka avulla myös henkilö, jolla ei ole teknistä osaamista, voi lisätä ja muokata sivuja, uutisia, tuotteita tai blogikirjoituksia. Syötät paneeliin otsikon, tekstin ja kuvan; järjestelmä julkaisee ne sivustolla.

Perinteisissä CMS-järjestelmissä sisältöpaneeli, tietokanta ja sivuston ulkoasu ovat yhden paketin osia. Paneeli tallentaa sisällön, ja sama ohjelmisto yhdistää sisällön malleihin ja tarjoaa sen kävijälle HTML-sivuna. Tätä rakennetta kutsutaan monoliittiseksi eli integroiduksi arkkitehtuuriksi.

Headless-lähestymistapa jakaa tämän paketin kahtia. Nimen ”headless” (päätön) ilmaisu kertoo, ettei järjestelmällä ole ”päätä” eli kiinteää näkymäkerrosta. Näkymäkerros on erillinen projekti, ja se pyytää sisällön API:n kautta.

02Miten headless-arkkitehtuuri toimii?

Headless-arkkitehtuuri koostuu yleensä kolmesta osasta: hallintapaneelista, jossa sisältö syötetään, API:sta, joka antaa sisällön ulos, sekä yhdestä tai useammasta käyttöliittymästä, joka näyttää sisällön.

1. Toimittaja syöttää sisällön: täyttää paneelissa otsikon, tekstin, kuvan ja kentät.
2. Sisältö tallennetaan jäsenneltynä datana: sivuasettelua ei tallenneta vaan kentät (otsikko, tiivistelmä, runko, kirjoittaja, päivämäärä).
3. Käyttöliittymä lähettää pyynnön API:lle: verkkosivusto, mobiilisovellus tai muu kanava saa sisällön JSON-muodossa.
4. Käyttöliittymä näyttää sisällön omalla suunnittelullaan: sama sisältö esitetään jokaisessa kanavassa kyseiselle kanavalle sopivalla tavalla.
5. Muutos julkaistaan: sivut joko luodaan uudelleen tai seuraavassa pyynnössä haetaan ajantasainen data.

const yanit = await fetch('https://cms.ornek.com/api/yazilar?limit=3');
const { veriler } = await yanit.json();
veriler.forEach(y => console.log(y.baslik, y.yayinTarihi));

03Headlessin ja perinteisen CMS:n ero

Kuten taulukosta näkyy, headless tuo joustavuutta ja skaalaa, mutta vaatii alussa enemmän kehitystyötä. Siksi se ei ole oikea valinta jokaiseen projektiin; sitä tulee arvioida tarpeen kanssa.

04Headless CMS:n edut

Nopeus ja suorituskyky

Headless-rakenteessa käyttöliittymä voi luoda sivut etukäteen ja tarjota ne CDN:n kautta. Kävijän ei tarvitse odottaa tietokantakyselyä joka pyynnöllä; sivu on valmis. Tämä helpottaa Core Web Vitals -tavoitteiden (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1) saavuttamista. Olemme käsitelleet nopeutta yksityiskohtaisesti nopeuden ja suorituskyvyn hallinta -sivullamme.

Tietoturva

Hallintapaneeli voi sijaita eri osoitteessa kuin kävijän käyttämä sivusto. Jos sivusto koostuu staattisista tiedostoista, hyökkääjän kohteeksi joutuvaa palvelinpuolen koodia on vähemmän. Tämä pienentää hyökkäyspintaa; muista kuitenkin, että myös paneeli ja API on suojattava.

Monikanavainen julkaisu

Sama tuotekuvaus voidaan käyttää verkkosivustolla, mobiilisovelluksessa, myymälänäytöllä ja markkinapaikan syötteessä. Sisältö päivitetään kerran, ja se muuttuu kaikkialla. Tätä kutsutaan monikanavaiseksi julkaisuksi (omnichannel).

Teknologian vapaus

Käyttöliittymätiimi voi valita haluamansa teknologian sitoutumatta CMS:n mallikieleen. Kun haluat uudistaa käyttöliittymän, sisältö pysyy paikallaan; vain näkymäkerros kirjoitetaan uudelleen.

05Haitat ja huomioitavat asiat

Headless-rakenteen joustavuus ei ole ilmaista. Monet perinteisessä järjestelmässä valmiina tulevat ominaisuudet rakennetaan ja ylläpidetään tässä tiimin toimesta. Ennen päätöstä arvioi alla olevat kohdat yksitellen oman projektisi kannalta; usein ratkaisevaa ei ole teknologia vaan se, pystyvätkö tiimi ja budjetti kantamaan tämän lisävastuun.

• Riippuvuus kehittäjästä kasvaa: uuden sivumallin tai komponentin lisääminen vaatii koodia.
• Esikatselu rakennetaan erikseen: toimittajan sivun näkemiseksi ennen julkaisua tarvitaan lisätyötä.
• Osien määrä kasvaa: CMS, API, käyttöliittymä ja palvelinympäristö hallitaan erikseen.
• SEO-työ jää käyttöliittymälle: otsikkotagit, jäsennelty data ja sivukartta on rakennettava oikein käyttöliittymäprojektissa.
• Kustannusmalli on erilainen: jotkin pilvi-CMS-palvelut laskuttavat sisällön, käyttäjien tai API-pyyntöjen määrän mukaan.

06Mikä Jamstack on?

Jamstack on verkkoarkkitehtuurin lähestymistapa, joka mainitaan usein yhdessä headless CMS:n kanssa. Sivut luodaan etukäteen koontivaiheessa ja tarjotaan CDN:n kautta staattisina tiedostoina; dynaamiset asiat hoidetaan API:illa ja JavaScriptillä.

Tässä lähestymistavassa sisältö tulee headless CMS:stä ja sivut muodostaa staattinen sivugeneraattori tai kehys, kuten Next.js. Olemme kertoneet, miten Next.js yhdistää sekä staattisen että palvelinpuolen renderöinnin, artikkelissa Mikä on Next.js.

Jamstack ei sovi jokaiseen projektiin. Hyvin usein muuttuvassa, käyttäjäkohtaisesti personoituvassa sisällössä palvelinpuolen renderöinti tai hybridimenetelmät voivat sopia paremmin. Tärkeintä on valita oikea renderöintitapa sen mukaan, kuinka usein mikäkin sivu muuttuu.

07Missä projekteissa se kannattaa valita?

Katso päätöstä tehdessäsi ennen teknologiaa sisältöäsi: montako kanavaa on, kuinka usein sisältöä päivitetään, montako ihmistä muokkaa ja kuinka kriittistä nopeus on? Jos vastaat vahvasti kyllä vähintään kahteen näistä kysymyksistä, headless-rakenne on vakava vaihtoehto; muuten yksinkertaisempi arkkitehtuuri antaa yleensä sekä nopeamman että edullisemman tuloksen.

• Monikanavaiset brändit: yritykset, jotka käyttävät samaa sisältöä verkossa, mobiilisovelluksessa ja fyysisillä näytöillä.
• Monikieliset ja usean alueen sivustot: sisällön jäsennelty muoto helpottaa käännösten hallintaa.
• Paljon liikennettä saavat sisältösivustot: etukäteen luodut sivut kestävät kuormitusta paremmin.
• Sovellus ja sivusto yhdessä: verkkokauppa- tai varausalusta, jolla on mobiilisovellus.
• Usein ulkoasuaan uudistavat brändit: ne, jotka haluavat kirjoittaa käyttöliittymän uudelleen siirtämättä sisältöä.

08Mitä siirtymässä kannattaa huomioida?

Siirryttäessä nykyiseltä sivustolta headless-rakenteeseen tärkein vaihe on rakentaa sisältömalli oikein. Sivujen siirtämisen sellaisenaan sijaan sisältö on jaettava mielekkäisiin kenttiin: tuotteen nimi, lyhyt kuvaus, pitkä kuvaus, kuva, luokka ja niin edelleen.

Toinen vaihe on URL-rakenteen säilyttäminen. Jos osoitteet muuttuvat, jokaiselle vanhalle osoitteelle on suunniteltava 301-uudelleenohjaus; muuten hakukonenäkyvyys voi kärsiä. Tässä kohdassa hakukoneystävällisen verkkosivusuunnittelun periaatteet ovat tienviittoja.

Käyttöliittymäpuolella on puhuttava alusta alkaen myös siitä, millä teknologialla sisältö tarjotaan. Käyttöliittymän ja palvelimen työnjaon olemme käsitelleet artikkelissa frontendin ja backendin ero ja yhden palvelinpuolella yhä yleisen kielen artikkelissa Mikä on PHP. Aurora Yazılımilla verkkosivusuunnitteluprojekteissa sisältörakenne, nopeustavoitteet ja hallinnan helppous suunnitellaan yhdessä.