Menu

Wat er komt kijken bij de bouw van een goede website

HP Hans-Peter Harmsen heeft dit geschreven in augustus 2016

Bij de ontwikkeling van een state-of-the-art website komt veel meer kijken dan alleen html, content en een CMS erachter. Er is een hele rij van randvoorwaarden die de webbouwer ook moet verzorgen. Hierbij een overzicht.

Inleiding

Deze whitepaper is bedoeld voor mensen die wat meer willen weten van het proces van web-ontwikkeling zonder al te technisch te worden. 

Websites zijn tegenwoordig veel meer dan wat html tekst met plaatjes en links. Een goede website is een grote productie waar veel expertises aan te pas komen. Een deel van het werk is meteen zichtbaar, zoals UX, design en de content. Een groot deel van het werk gebeurt echter achter de schermen en dus krijg je daar vaak weinig van mee als je een website laat ontwikkelen. Er zijn een heleboel dingen die goed geregeld moeten worden om de website optimaal te laten functioneren en goed te laten scoren bij zoekmachines. In de volgende paragrafen bespreken we zeven onderwerpen.


1. Afbeeldingen

Afbeeldingen zijn vaak in veel verschillende formaten nodig afhankelijk van de plek waar ze gebruikt worden. Het is zonde van de bandbreedte om overal de grote high res versie van de afbeelding te serveren en zonde van de mogelijkheden van goede schermen om de kleine versie op te blazen.

Neem als voorbeeld een e-commerce website. Bij de zoekresultaten wil je de producten als thumbnails tonen terwijl je op de achterliggende pagina's de afbeeldingen juist zo groot en scherp mogelijk wilt laten zien. En je hebt ook geen zin om in het CMS alle afbeeldingen in verschillende formaten te uploaden. 

Wat we hierbij vaak doen is alleen de grootste versie uploaden in het CMS. De webserver genereert vervolgens 'on-the-fly' de juiste formaten zodra ze worden opgevraagd en bewaart ze vervolgens voor de volgende keer dat dat formaat nodig is. Dit is een heel flexibel systeem waarbij de server steeds alleen de afbeelding serveert die nodig is.

Het kan ook voorkomen dat de server nog niet weet welk formaat er gewenst is. Bijvoorbeeld omdat dit afhangt van het scherm van de gebruiker. In dat geval zit de logica voor het bepalen van welk formaat er wordt opgevraagd in de browser. HTML 5 heeft hier de mogelijkheden voor ingebouwd. Via de <picture> tag en de srcset property kan de browser het juiste formaat afbeelding aan de server vragen afhankelijk van de beschikbare pixels en de schermresolutie.

Als een afbeelding in verschillende groottes getoond wordt, moet deze ook in de juiste formaten geserveerd worden.

Voor tekeningen en iconen en voor bijvoorbeeld een logo, is het sowieso handig om deze in .svg vectorformaat te serveren. Dit is vaak veel kleiner dan een bitmapformaat zoals jpeg of png en de browser kan het op elke gewenste grootte afbeelden zonder dat het pixelig wordt.

2. Lettertypes

Om je website in een bepaald lettertype (font) te tonen, zal de gebruiker dat lettertype op de een of andere manier moeten hebben. Dat kan op verschillende manieren.

Web safe fonts

Web safe fonts zijn fonts die zijn vooraf geïnstalleerd op de meeste besturingssystemen. Veilige lettertypes, die op tachtig procent van zowel Macs als Windows Machines zijn geïnstalleerd zijn tegenwoordig: Arial, Tahoma, Trebuchet MS, Verdana, Georgia, Palatino, Times New Roman, Courier New, en Lucida. 

Wil je een ander lettertype dan een van deze, dan ben je al snel aangewezen op een web font.

Web fonts

In tegenstelling tot web safe fonts, zijn web fonts niet vooraf geïnstalleerd op het systeem van de gebruiker. Ze worden gedownload door de browser bij het ophalen van de webpagina.

Vaak komen de fonts rechtstreeks van een font-leverancier die zorgt voor de hosting en de licentie van het font. Hierbij heb je een aantal grote spelers: Typekit (van Adobe) en fonts.com zijn reuzen met respectievelijk 5500 en 20.000 verschillende fonts. Bij beiden is wel een account nodig en daar betaal je voor. De kosten hangen af van het aantal pageviews dat je per jaar hebt op je website. De andere grote speler is Google die met ruim 700 fonts een veel kleinere collectie biedt maar daar staat dan weer tegenover dat de Google fonts geheel gratis zijn. Daarnaast zijn er nog diverse andere, kleinere spelers die specifieke fonts aanbieden.


Verschillende formaten

Met een licentie op het juiste font ben je er nog niet want de verschillen tussen de diverse browsers gooien weer eens roet in het eten. Er zijn vier verschillende formaten en die worden in meer en minder mate ondersteund:

  • TTF (True Type) wordt het meest ondersteund maar is niet gecomprimeerd en daardoor nogal zwaar om te laden.
  • WOFF (Web Open Font Format) is wel gecomprimeerd maar niet ondersteund op bijvoorbeeld oudere mobiele apparaten.
  • WOFF2 is nog eens 30% kleiner maar alleen beschikbaar in Chrome and Opera
  • Tenslotte nog het EOT formaat, met slechte rendering maar de enige optie in IE9 en oudere browsers.

Een goede website biedt dus vaak links aan naar alle vier de formaten waarbij de browser het meest optimale formaat kiest. Als het font gehost wordt bij een font-leverancier zoals Typekit dan wordt dit laatste automatisch geregeld.

Unicode subsets

Tenslotte nog iets over grote fonts. Door de opkomst van Unicode dat steeds meer verschillende lettertekens ondersteunt, worden veel font-bestanden ook steeds groter. Er moeten tenslotte steeds meer letters/tekens/emoticons meegestuurd worden. Maar al die tekens zijn vaak niet allemaal nodig. Zo heb je niet de volledige set van tekens nodig als je weet dat de tekst toch alleen maar in het Nederlands is. Om dit op te lossen kun je bij het laden van het font een range van unicode-karakters meegeven die je wilt laden. Bijvoorbeeld unicode-range: U+3000-9FFF, U+ff?? haalt alleen Japanse karakters op. Dat scheelt weer laden en dus responsetijd van de site.

3. Compressie

Websites maken steeds meer gebruik van JavaScript. Vooral Single Page Applications die geheel in JavaScript worden opgebouwd slepen een grote hoeveelheid JavaScript libraries met zich mee. Deze JavaScript moet allemaal worden ingeladen om de pagina te laten werken. Dat kost tijd en bandbreedte. Daarom is het verstandig om de JavaScript bestanden (en trouwens ook de CSS bestanden die de styling van de website bepalen) ge-minified op te sturen. Dat wil zeggen: alle overbodige tekens worden eruit gehaald. De meeste goede websitebouwers doen dit trouwens automatisch zij zorgen voor een deployment systeem dat automatisch de laatste versies van de bestanden uit het source control systeem haalt, ze minified en op de juiste plek op de server zet.

Extra compressie kan bereikt worden door de html pagina zelf gecomprimeerd over te sturen. Browsers begrijpen dit. De server stuurt de bestanden gezipt over en de browser pakt ze uit en toont ze. Deze methode zorgt wel voor wat extra werk voor de processors van de server en de client (de bestanden moeten tenslotte ingepakt en uitgepakt worden) maar bandbreedte is meestal meer een probleem dan processorkracht. 

Compressie werkt vooral goed bij html, css en JavaScript bestanden. Bij afbeeldingen, geluid en video heeft dit geen nut want deze zijn van zichzelf al gecomprimeerd.

4. Content Delivery Network

De meeste moderne browsers kunnen zes verbindingen tegelijk aan naar hetzelfde domein. Dat betekent een vertraging voor websites waarop veel javascript bestanden, CSS bestanden, lettertypes en afbeeldingen staan. De browser kan er immers maar zes tegelijk binnen halen.

Met een CDN (Content Delivery Network) worden statische bestanden extern gehost, vaak op meerdere subdomeinen. Naast de mogelijkheid om op deze manier meer bestanden tegelijk binnen te halen biedt dit nog twee andere voordelen: 
Een CDN is vaak gedistribueerd over de wereld. De bestanden zijn dus vaker lokaal beschikbaar en hoeven minder vaak van de andere kant van de oceaan te komen. 
Bij het ophalen van veelgebruikte javascript bestanden (zoals JQuery) is er een grote kans dat deze al door een andere website is opgehaald en dus al lokaal op de machine van de gebruiker beschikbaar is.

Een CDN distribueert bestanden vanaf een centrale plek naar lokale servers om de data sneller bij de gebruikers te krijgen.

Cloudfront

Een bekend voorbeeld van een CDN is Amazon Cloudfront. Dit is Amazon's service die ervoor zorgt dat bestanden razendsnel beschikbaar zijn overal over de wereld. Cloudfront is gebouwd op Amazon's opslagservice S3. Als snelheid voor bepaalde bestanden niet zo'n issue is, dan is het ook mogelijk om bestanden rechtstreeks vanaf S3 te serveren. Dat scheelt in de kosten voor Cloudfront.

5. Browser caching

Bij ieder bestand dat de webserver opstuurt, heeft hij de mogelijkheid om aan te geven hoe lang dat bestand geldig is. Dit geeft de webserver mee in een 'header'. De browser kijkt hiernaar en slaat het bestand zo lang in de lokale cache op. Dit voorkomt dat hij dezelfde bestanden (bijvoorbeeld een logo of een CSS bestand) bij elke pagina opnieuw gaat ophalen.

Door de cache headers van de verschillende bestanden slim in te stellen, kan een web-bouwer een flinke performance boost bereiken. Afbeeldingen wijzigen meestal nooit, stijlbestanden en javascript zelden, maar dynamische data die bijvoorbeeld door PHP wordt gegenereerd wijzigt vaak bij elke pagina.

6. Beveiligde verbinding

SSL is een manier om de internetverbinding tussen twee computers zoals de server en de computer van de gebruiker te beveiligen. Dit is belangrijk want de meeste (wifi) netwerken zijn gemakkelijk af te luisteren. Kwaadwillenden kunnen daarmee wachtwoorden en creditardgegevens afluisteren.

Tegenwoordig wordt overigens TLS gebruikt. Dat is een verbeterde versie van SSL. Het belangrijkste verschil is dat de maker van de website hierbij zelf kan bepalen welk encryptie-algoritme hij gebruikt. HTTPS is HTTP (dus het uitwisselen van webpagina's) over zo'n SSL/TLS verbinding. Om een website via HTTPS aan te kunnen bieden, moet je kunnen aantonen dat je als website bent wie je zegt dat je bent en je moet de data dus op een bepaalde manier versleutelen. Hiervoor heb je een certificaat nodig.

Certificaten

Een certificaat is in feite een bestandje met daarin een aantal gegevens. Het bevat de naam van de eigenaar, zijn publieke sleutel (voor de encryptie), de geldigheidsduur en de uitgever van het certificaat. Daarnaast staan deze gegevens er nog een keer in maar dan versleuteld met de private sleutel van de uitgever van het certificaat. Dit laatste werkt als watermerk.

​Self signed

Een certificaat kan een webbureau gewoon zelf aanmaken, daar bestaan programmaatjes voor. Je krijgt hiermee een prima versleutelde verbinding die niet af te luisteren is. Self signing heeft echter wel een nadeel: de bezoeker van de website heeft geen zekerheid dat de website wel echt de website is die hij bedoelt. Iedereen kan een certificaat maken voor rabobank.nl. Daarom geven browsers snel een foutmelding bij deze self signed certificaten.

Certificaat uitgevers en root certificaten

Om het problem met self signed certificaten uit de weg te gaan zijn er uitgevers van certificaten. Door je certificaat digitaal te laten tekenen door zo'n uitgever geeft die aan dat jouw certificaat betrouwbaar is en dat die echt hoort bij jouw domein.
Om te bewijzen dat die uitgever zelf wel de juiste partij is, laat die zijn certificaat weer tekenen door een nog hogere autoriteit. Zo bestaat er een hele keten van certificaten. Helemaal bovenin deze keten staan een aantal grote partijen zoals Comodo, Symantec of GlobalSign die de browser-makers ervan hebben overtuigd dat hun certificaten, die de root certificaten worden genoemd, altijd betrouwbaar zijn

Die niveau's van beveiliging en hoe dit er in de browser uit ziet.

EV Certificaten

Een nog verder gaande vorm van beveiliging zijn de Extended Validation (EV) certificaten. Dit betekent dat de uitgever van het certificaat eerst een uitgebreid onderzoek heeft gedaan naar de betrouwbaarheid van de website eigenaar. Hierbij wordt onder andere het volgende gecontroleerd:

  • De domeinnaamhoudergegevens (Whois);
  • De KvK-inschrijving
  • Telefonische validatie

EV certificaten komen automatisch op de Certificate transparency lijst van Google. Dit is de lijst van alle certificaten die Google bijhoudt om de bepalen welke websites betrouwbaar zijn.

7. Versturen van e-mails

Niks is meer zomaar eenvoudig bij moderne websiteontwikkeling. Zelfs niet het versturen van een e-mailtje voor bijvoorbeeld het resetten van een wachtwoord. Spamfilters worden (gelukkig maar) steeds beter en daarmee steeds strenger. Dat betekent dat je vanuit een website niet meer zomaar e-mails kunt versturen namens die website. De server waarvandaan de e-mails worden verstuurd, moet namelijk eerst geregistreerd worden als server die daartoe is geauthoriseerd.

Dit gebeurt in de DNS, de wereldwijde gedistribueerde database waarin staat welk domeinnaam aan welke server (IP-adres) is gekoppeld. In de DNS moet een zogenaamd SPF record worden opgenomen waarin staat dat het IP adres van de mailserver gerechtigd is om e-mails te versturen namens het domein dat je gebruikt. Laat de bouwer van de website dit achterwege, dan is er een grote kans dat de e-mails die vanaf de website verstuurd worden in de spam belanden.

domein.nl. IN TXT "v=spf1 a mx ~all"
Voorbeeld DNS record voor het Sender Policy Framework

Conclusie

Het zal intussen duidelijk zijn dat er bij de ontwikkeling van een goede website veel komt kijken. Er moet veel gebeuren waar je in eerste instantie niet bij stil staat. En dan heb ik het nog niet eens gehad over zoekmachine-optimalisatie. Dat is nog weer een vak apart; wellicht een goed onderwerp voor een volgende whitepaper.

Overigens helpen alle bovengenoemde punten mee met hoog scoren bij zoekmachines. Google geeft aan dat dingen als optimalisatie van afbeeldingen en lettertypes, compressie, performance en beveiliging allemaal zaken zijn die mee tellen met het resultaat.

HP

Hans-Peter Harmsen

MANAGEMENT

Oprichter en managing director; verantwoordelijk voor grote accounts en strategie.

E-mail:
hph@oberon.nl
Telefoon:
+31 654 337 275

“We maken samen met onze klanten betere online producten, zowel voor het web als in mobiele apps”

Meer informatie op Oberon.nl