Miksi Sanity CMS on paras sisällönhallintajärjestelmä?

Kysymykseen siitä, onko Sanity paras sisällönhallintajärjestelmä, ei ole yleispätevää vastausta. Valinta riippuu sivuston koosta, sisällön määrästä, budjetista ja siitä, onko yrityksellä käytössään kehittäjä tai tekninen kumppani. Oma vastaukseni on tämä: kun yrityksen sisältö koostuu toistuvista asioista, kuten palveluista, referensseistä ja henkilöistä, ja samaa sisältöä näytetään useassa paikassa, valitsen työssäni Sanityn. Sanity on headless-järjestelmä, eli se tallentaa ja jakaa sisällön, mutta sivuston ulkoasun rakentaa erillinen tekniikka. SK Infran sivustolla tämä tekniikka on Astro. Pienelle ja harvoin päivitettävälle sivustolle, jota yksi ihminen ylläpitää ilman kehittäjää, Sanity vaatii yleensä enemmän suunnittelua ja kehitystyötä kuin sivusto tarvitsee.

Mikä Sanity on

Headless tarkoittaa, että sisällönhallinnalla ei ole omaa ulkoasua. Järjestelmä tallentaa tekstit, kuvat ja niiden väliset suhteet ja luovuttaa ne rajapinnan kautta sille, joka niitä pyytää. Perinteisessä julkaisujärjestelmässä sama ohjelma sekä säilyttää sisällön että muodostaa siitä sivun. Sanityssa sivuston näkyvä osa rakennetaan erikseen, esimerkiksi Astrolla tai Next.js:llä. Ulkoasun voi silloin vaihtaa koskematta sisältöön, mutta tekniikan vaihto vaatii usein silti muutoksia sisältömalliin, kyselyihin ja sivuston koodiin.

Sisältö tallennetaan Sanityn pilvipalveluun, ja sitä muokataan Sanity Studiossa. Studio on selaimessa toimiva hallintanäkymä, jonka kehittäjä muokkaa sisältömallin mukaiseksi, joten sisällöntuottaja näkee vain ne kentät, joita sivustolla tarvitaan. Sivusto hakee sisällön GROQ-kyselykielellä, jolla se pyytää vain tarvitsemansa kentät, esimerkiksi kaikki referenssit otsikoineen ja pääkuvineen. Webhook on automaattinen ilmoitus, jonka Sanity lähettää, kun sisältö muuttuu. Sen avulla sivusto rakennetaan uudelleen julkaisun jälkeen.

Headless-malli vaatii kehittäjän tai teknisen kumppanin, koska jonkun on suunniteltava sisältömalli, rakennettava sivusto ja ylläpidettävä niiden välistä yhteyttä. Jos yritys haluaa valmiin editorin, jossa sivut kootaan raahaamalla ilman ohjelmointia, Sanity ei ole siihen oikea työkalu.

Rakenteinen sisältö

Rakenteinen sisältö tarkoittaa, että sisältö tallennetaan merkityksensä mukaan eriteltyinä kenttinä eikä valmiiksi muotoiltuina sivuina. Sisältömalli on kehittäjän kirjoittama määrittely siitä, millaisia sisältötyyppejä järjestelmässä on ja mitä kenttiä niissä on. Palvelu, referenssi, henkilö tai usein kysytty kysymys voi olla oma tyyppinsä, jolla on kentät kuten nimi, lyhyt kuvaus, kuva ja yhteystiedot. Kun palvelu on oma dokumenttinsa, sama tieto näkyy palvelusivulla, etusivun nostossa ja referenssin yhteydessä, eikä tekstiä kopioida kolmeen paikkaan. Kun kuvaus muuttuu, se korjataan kerran.

Sisältötyyppien välille tehdään viittauksia. Viittaus on linkki dokumentista toiseen: referenssi viittaa palveluun, jota projektissa tehtiin, ja palvelu viittaa yhteyshenkilöön. GROQ:lla sivusto hakee yhdellä kyselyllä palvelun ja siihen liittyvät referenssit. Samaa sisältöä voi hakea myös asiakasportaaliin tai mobiilisovellukseen, jos sellainen rakennetaan, eikä niille tarvita omaa sisältövarastoa.

Sivujen rakennetta varten määritellään uudelleenkäytettäviä sisältölohkoja, kuten nosto, yhteydenottokaista tai kuvagalleria. Sisällöntuottaja kokoaa sivun järjestämällä lohkoja Studiossa. Leipäteksti tallennetaan Portable Text -muodossa, jossa otsikot, linkit ja korostukset säilyvät rakenteisena datana eivätkä katoa yhteen HTML-merkkijonoon, joten sivuston koodi päättää, miltä otsikko tai lainaus näyttää. Jos lohkoja on liian vähän, sivuista tulee kaavamaisia. Jos niitä on liikaa, sisällöntuottaja ei enää tiedä, mitä lohkoa mihinkin käyttää.

Kun nimet, kuvaukset ja painikkeiden tekstit ovat omissa kentissään, monikielisellä sivustolla käännetään vain ne, ja kuvat ja yhteystiedot pysyvät yhteisinä. Datastaxin tapauskuvauksessa yritys ilmoittaa julkaisusyklin lyhentyneen 7–10 päivästä enintään 72 tuntiin, kun lokalisointi siirtyi rakenteiseen malliin [1]. Luku on yhden yrityksen oma ilmoitus Sanityn sivuilla, eikä sitä voi pitää yleisenä näyttönä. Muutaman staattisen sivun yksikielisellä sivustolla kenttiin jakamisesta ei ole juuri hyötyä, koska mitään ei käännetä eikä näytetä toisessa paikassa.

Sanity ja Astro

SK Infran sivustolla Sanity säilyttää tekstit, kuvat ja niiden rakenteen, ja Astro muodostaa niistä sivut, jotka kävijä näkee selaimessa. Kun SK Infran sisältöä päivitetään Studiossa, Astron koodiin ei kosketa, eikä muutos kulje minun kauttani.

Valitsin Astron, koska rakennusalan yrityksen sivusto on sisältöpainotteinen. Kävijä lukee palvelukuvauksia, katsoo kuvia ja etsii yhteystiedot, eikä sivulla tarvita sovelluksen kaltaista toiminnallisuutta. Astro muodostaa sivut valmiiksi HTML:ksi ja lähettää selaimelle JavaScriptiä vain niille osille, jotka sitä tarvitsevat, kuten valikolle tai lomakkeelle. Tämä on Astron ominaisuus, ei Sanityn. Etu pienenee, jos sivustossa on kirjautumisia, suodatuksia ja reaaliaikaisia näkymiä.

Sanity ei tee sivustosta nopeaa. Nopeuden ratkaisevat kuvien koko ja formaatti, välimuistin asetukset, se muodostetaanko HTML etukäteen vai pyynnön hetkellä sekä palvelinympäristö. Omissa projekteissani suurimmat erot ovat syntyneet kuvista: jos kuvaa ei rajata ja pakata oikein, kevyinkään toteutus ei pelasta latausaikaa.

Siksi arvioin suorituskyvyn mittaamalla enkä tekniikan nimen perusteella. Google pitää Largest Contentful Paint -arvoa hyvänä, kun sivun suurin näkyvä sisältöelementti piirtyy enintään 2,5 sekunnissa. Interaction to Next Paint -arvon pitäisi olla enintään 200 millisekuntia ja Cumulative Layout Shift -arvon enintään 0,1 [2]. Mittaan nämä mobiililla ja työpöydällä erikseen, koska tulokset voivat erota selvästi. Lighthouse kertoo, miten sivu toimii testiympäristössä. Search Consolen Core Web Vitals -raportti taas perustuu todellisten käyttäjien dataan ja näyttää tuloksia, kun dataa on riittävästi [3]. Pelkkää Lighthouse-tulosta en esitä todisteena sivuston nopeudesta.

Ylläpito ja kustannukset

Sanityssa sisältömallin ja sisällön ylläpito ovat eri ihmisten töitä. Kehittäjä määrittelee koodissa sisältötyypit, niiden kentät ja sen, mitkä kentät ovat pakollisia. Sisällöntuottaja kirjoittaa ja julkaisee Studiossa. Kun sivustolle halutaan kokonaan uusi sisältötyyppi, muutos kulkee kehittäjän kautta, koska malli on koodia.

Käyttöoikeuksien määrä riippuu tilauksen tasosta ja Sanityn voimassa olevista ehdoista [4]. Enterprise-tasolla Sanity kertoo tarjoavansa laajempia hallinta- ja tietoturvaominaisuuksia [5]. Jos sisältöä päivittää yksi tai kaksi ihmistä, laajasta roolijaosta ei ole juuri hyötyä.

Tyypillinen integraatio on webhook, joka käynnistää sivuston uudelleenrakennuksen hostingpalvelussa julkaisun jälkeen. Jonkun on korjattava se, kun yhteys katkeaa esimerkiksi rajapintamuutoksen takia. Jos yrityksellä ei ole kehittäjää tai teknistä kumppania myös julkaisun jälkeen, suosittelen pitämään integraatioita vain muutaman.

Sanityn hinta ja käyttökiintiöt riippuvat valitusta suunnitelmasta ja voimassa olevasta hinnastosta. Enterprise-tason hinta sovitaan yrityskohtaisesti [4]. Lisenssi on silti vain yksi kulu. Muut tulevat sisältömallin suunnittelusta, sivuston kehityksestä, hostingista, vanhan sisällön siirrosta, käyttäjien koulutuksesta ja jatkuvasta ylläpidosta. Lasken ne mukaan ennen kuin vertaan Sanityä valmiiseen sivueditoriin.

Lopuksi

Käytän Sanityä silloin, kun palvelut, referenssit ja henkilöt ovat omia sisältötyyppejään, niitä näytetään useassa paikassa ja ne pysyvät käytettävissä, vaikka sivuston ulkoasu tai tekniikka myöhemmin vaihtuisi. Valmis sivueditori tai perinteinen julkaisujärjestelmä sopii minun kokemukseni mukaan usein paremmin, jos sivustossa on alle kymmenkunta lähes muuttumatonta sivua ja niitä päivittää yksi henkilö muutaman kerran vuodessa. Raja ei ole mitattu, vaan oma arvioni siitä, milloin sisältömallin suunnitteluun käytetty aika on suurempi kuin päivityksissä säästyvä aika. Sama pätee, jos sisällöntuottaja haluaa koota uusia sivuja raahaamalla ilman, että kukaan on suunnitellut niille sisältömallia. Silloin maksetaan sisältömallin suunnittelusta, Studion räätälöinnistä ja sivuston kehityksestä, mutta rakenteista ei ole käyttöä. Myös käyttäjäkohtainen ja kulutukseen perustuva hinnoittelu [4] voi pienessä hankkeessa tulla kalliimmaksi kuin kiinteähintainen palvelu.

Ennen valintaa suosittelen yhtä harjoitusta. Listaa paperille sisällöt, jotka toistuvat sivustollasi useammassa kohdassa, kuten palvelut, referenssit, yhteyshenkilöt tai usein kysytyt kysymykset, ja merkitse jokaisen viereen, missä muualla sitä tarvitaan nyt tai kahden vuoden päästä. Jos lista jää lyhyeksi ja kaikki sisältö elää vain verkkosivulla, kevyempi järjestelmä riittää. Jos sama tieto päätyy moneen paikkaan, Sanityssa se korjataan kerran joka kerta, kun sisältöä muutetaan.

Lähteet

1. Case Study: DataStax achieves faster content localization and shorter release cycles with Sanity
2. Understanding Core Web Vitals and Google search results
3. Core Web Vitals report - Search Console Help
4. Pricing
5. Enterprise