🌵OldMartijntje

SEO Aandachtspunten

8 min read

Credits

This article is not made by me, it is made by a colleague.

  • Als je een element zonder interactie (b.v. klikken) in beeld laat verschijnen, zoals een popup, gebruik waar mogelijk een animatie om hem vloeiend en minder “plots” te laten verschijnen. Als de layout namelijk plots verschuift op je pagina (een Cumulative Layout Shift) straft Google je website hard af (slechte CLS-score). Meer informatie: https://web.dev/articles/cls (zie bijvoorbeeld het filmpje aan het begin van de pagina)

  • Bij img-tags, geef waar mogelijk een width en height attribuut mee, ook als je de img-tag nog styled met CSS. Als de img-tag een vaste afmeting heeft (b.v. 50x50 px), stel dan deze grote in. Als de grote responsive is (b.v. met CSS media queries, percentages of auto waardes), geef dan de width en height van de afbeelding zelf op.

    Waarom is dit belangrijk? Als de webbrowser geen width en height heeft van de afbeelding, dan kan de CSS nog niet (correct) gerenderd worden totdat de afbeelding gedownload is. Hierdoor kan de website gaan klapperen en heb je dus weer een slechte CLS-score.

  • Als je een <link rel="canonical" href="https://simpelsubsidie.nl">-tag (canonical pagina naam) toevoegd, zorg ervoor dat deze ALTIJD verwijst naar de basis pagina. De canonical-tag wordt door Google gebruikt om een unieke pagina te identificeren als meerdere URLs verwijzen naar dezelfde pagina (Bijvoorbeeld de volgende verschillende URLs verwijzen naar dezelfde pagina: https://simpelsubsidie.nl/blogs/Beste-all-electric-warmtepomp en https://simpelsubsidie.nl/blogs/?Beste-all-electric-warmtepomp). De canonical waarde MOET dezelfde waarde hebben voor alle URLs die naar deze pagina verwijzen, anders ziet Google de pagina mogelijk als duplicaat en wordt je content minder gepromoot in de zoekresultaten.

    Als voorbeeld, de blogs pagina heeft nu altijd de URL zonder ’?’ als canonical (ongeacht of dat de ’?’ url gebruikt wordt). Een tip om dit goed te doen bij dynamische pagina’s (zoals blogs, waarbij /blogs/index.php gebruikt wordt voor het tonen van alle blogs): Laat de canonical waarde niet afhankelijk zijn van GET of POST waardes, maar van de content uit de database bijvoorbeeld. Zie de onderstaande voorbeelden:

<?php
// Uit `/blogs/index.php`
 
// Oude implementatie, twee verschillende canonicals: 1 met '?' en 1 zonder, maar de content op de pagina is hetzelfde. Google == confused
$cannonical = 'https://simpelsubsidie.nl/blogs/'.(isset($htaccess_blognaam) ? $naam : '?'.$naam);
 
// Nieuwe implementatie, alleen de versie zonder '?' wordt gebruikt, Google begrijpt nu wel de structuur van de URLs en ziet geen duplicate meer
$cannonical = 'https://simpelsubsidie.nl/blogs/'.$naam;
?>
 
<link rel="canonical" href="<?php echo $cannonical; ?>" />
 
<?php
// Uit `/faq/index.php`
 
// Oude canonical
//
// Canonical moet ALTIJD verwijzen naar de unieke, basis pagina.
// Aangezien de content op de pagina "altijd hetzelfde is",
// ongeacht de waarde van $getInvoer ($getInvoer filtert de getoonde content alleen maar)
// moet https://simpelsubsidie.nl/faq/ als canonical worden opgegeven.
// Anders raakt Google door de war vanwege de duplicaat content
//
echo '<link rel="canonical" href="https://simpelsubsidie.nl/faq/?'.rawurlencode($getInvoer).'" />';
 
// Nieuwe canonical
echo '<link rel="canonical" href="https://simpelsubsidie.nl/faq/" />'
 
?>

  • Zet niet cruciale css en (vooral) javascript NIET in de head-tags. De head-tag wordt namelijk door de browser render engine gezien als onderdeel van de ‘Critical Path’. Dat houdt in dat ALLES wat in de <head> staat het renderen van de website blokkeerd (in deze tijd ziet de gebruiker een leeg scherm). Vooral externe bestanden (fonts en css in link-tags) en script-tags kosten veel tijd/cpu. Als deze link en script-tags aan het begin van de body worden geplaatst, worden deze elementen (nog steeds in dezelfde volgorde) in de achtergrond en efficiënter verwerkt maar kan de browser ondertussen al wel de pagina tonen.

    Nu moet je niet alles naar de body verplaatsen, cruciale css bestanden en javascript (alhoewel je javascript bijna altijd wilt uitstellen totdat de pagina in ieder geval zichtbaar is) mogen nog steeds in de head worden geplaatst (b.v. /assets/css/style.css en /assets/[..]/bootstrap.css zijn cruciaal voor het renderen), daar zijn ze cruciaal voor. Maar alle CSS en javascript voor bijvoorbeeld nog niet zichtbare element of elementen die door javascript worden gemaakt, kunnen beter in de body worden gezet.

    Meer informatie, zie: https://web.dev/learn/performance/understanding-the-critical-path

  • Aansluitend op het bovenstaande: Maak gebruik van <link rel="preload"> en <link rel="preconnect"> in de head als je css/fonts in de body plaatst of als je weet dat een bepaald bestand binnen 10sec na het laden van de pagina nodig is.

    De preload-functie van link-tags zorgt er voor dat de browser op de achtergrond direct bij het parsen van de tag het gespecificeerde bestand gaat ophalen van de server. Wanneer het bestand dan verderop daadwerkelijk nodig is, dan staat deze al gelijk klaar en hoeft de gebruiker niet meer te wachten.

    Als je niet exact weet welk bestand opgehaald moet worden maar wel van welke server (bijvoorbeeld als je Google Fonts gebruikt), gebruik dan de preconnect-functie van link-tags. Dit verteld de browser om alvast de TCP/TLS-verbinding met de gespecificeerde server te maken, zonder het bestand op te vragen. Wanneer dan het echte bestand opgehaald moet worden, dan is de verbinding met de server al gemaakt en gaat de request naar het bestand een stuk sneller.

    Zie https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preload en https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preconnect voor meer informatie.

    Een voorbeeld voor Google Font:

<!DOCTYPE html>
<html lang="en">
<head>
    <link rel="preload" href="https://fonts.googleapis.com/css?family=Crimson+Text:400,400i,600|Montserrat:200,300,400&display=swap" as="style">
 
    <!-- In het CSS-bestand van Google Fonts -->
    <style>
        /* ... */
        @font-face {
            font-family: 'Montserrat';
            /* ... */
  
            /* Zie de link naar verwijzing naar "https://fonts.gstatic.com", deze link kan dus in preconnect worden gebruikt */
            src: url(https://fonts.gstatic.com/s/montserrat/v30/JTUSjIg1_i6t8kCHKm459WlhyyTh89Y.woff2) format('woff2');
 
            /* ... */
        }
        /* ... */
    </style>
 
    <link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
    
</head>
<body>
 
    <!-- Laad het css bestand voor de Google Font 'asynchroon' in de body, aangezien een font "niet cruciaal" is -->
    <link href="https://fonts.googleapis.com/css?family=Crimson+Text:400,400i,600|Montserrat:200,300,400&display=swap" rel="stylesheet">
 
</body>
</html>

  • Probeer pagina specifieke en kleine CSS/style aanpassingen in style-tags te plaatsen. Het is efficiënter om een iets groter php/html bestand te hebben, dan dat de browser een klein CSS bestand moet opvragen van de server (dit kost server cpu en duurt MINSTENS 50ms per CSS-bestand, en met traag internet nog heel veel langer).

    Nu zijn er een paar haken en ogen hieraan: Hoe zit het met caching van de CSS-bestanden en dezelfde CSS gebruiken op meerdere pagina’s (je moet niet CSS gaan copy-pasten). Het klopt dat inline-CSS niet gecached wordt, maar dat maakt voor kleine (cruciale) CSS bestanden nauwelijks uit. Houd wel een maximum bestands grote aan voor het inlinen van CSS, bijvoorbeeld maximaal 10Kb.

    Nu moet je niet massaal CSS uit bestanden gaan kopiëren en deze in style-tags gaan zetten, dat maakt de boel ook onoverzichtelijk. Daarvoor heb ik een nieuwe php-functie toegevoegd, de cssInline()-functie. Dit is ook gelijk de oplossing voor inline CSS voor een CSS-bestand dat op meerder pagina’s moet worden gebruikt. Deze functie plaatst de contents van het css bestand in <style></style> tags, welke in de webpagina kan worden geplaatst. Zie het code voorbeeld hieronder.

<?php
 
/**
 *
 * @param string $cssFile Path or URL to css file
 * @param ?string $minify Values: 'none'/null, 'full' (best compression, breaking in certain cases), 'basic' (none breaking), 'comments' (only removes comments)
 * @return string
 */
function cssInline($cssFile, $minify = 'basic') {}
 
// Als een de waarde van $cssFile een URL van SiSu is, weet de functie het bestand op de server te vinden
// Kan het bestand niet gevonden worden op de server? Dan wordt de CSS niet ge-inlined en wordt een link-tag gebruikt
 
?>
 
<!-- Gebruik de functie als volgt: -->
 
<?= cssInline('/landingspagina_prefab/style-v2.css'); ?>
<!-- 
Output: 
	<style>/* Minified CSS */</style> 
of 
	<link rel="stylesheet" href="/landingspagina_prefab/style-v2.css"> 
-->
 
<!-- of: -->
 
<?php 
	echo cssInline('https://simpelsubsidie.nl/assets/css/landing-3.css');
?>
<!-- 
Output: 
	<style>/* Minified CSS */</style> 
of 
	<link rel="stylesheet" href="https://simpelsubsidie.nl/assets/css/landing-3.css"> 
-->

  • Mogelijk kennen jullie de Lighthouse tool in Chrome al (zo niet, echt even checken: https://developer.chrome.com/docs/lighthouse/overview). Lighthouse is een moment opname van de prestaties van je website, met name kwa performance en content layout. Hoe hoger de score hoe beter, en je krijgt gelijk tips waar je zwakke punten liggen.

    Lighthouse is een belangrijke tool, maar Google gebruikt een uitgebreidere versie om je website te beoordelen, de web-vitaliteits metrics. Het zal je misschien niet verbazen, maar elke versie van Google gebaseerde Chromium browsers bevat een tracking tool die een “anonieme” lighthouse analyse uitvoert gedurende jouw VOLLEDIGE bezoek en interactie met een website. Deze gebruikt Google om de web-vitaliteitsscore van jouw website te bepalen.

    Jij hebt zelf ook toegang tot deze (cumulatieve) meetresultaten in de chrome DevTools! Open je DevTools (F12 of Ctrl+Shift+I) en ga naar het tabblad “Performance”. Hier zie je je “Local Metrics”, dat is de live waarde van deze webvitaliteitsscore in jouw browser sessie. Rechts daarvan zie je als het goed is een sectie met de naam “Next Steps” en “Field Data”.

    Onder “Field data” klik op de knop “Set up”. Je krijgt dan een melding “dat de url naar Google gestuurd moet worden”. Klik op “Ok” om toegang te krijgen tot de echte webvitaliteitsscores die Google gebruikt om jouw pagina te beoordelen. Zodra je op “Ok” hebt geklikt zie je rechts naast jouw lokale webvitaliteitsscore de score die Google je geeft op basis van de data die ze verzameld hebben uit andere chrome browsers.

    Google maakt in zijn scores onderscheid tussen mobiele apparaten en computers. De score voor smartphones/kleine schermen kan je zien door de “Device toolbar”/“Responsive” weergave te activeren (zie afbeelding) of in het “Field data”-boxje het Device type “Mobile” te selecteren.

    Meer informatie over field data: https://web.dev/articles/lab-and-field-data-differences Meer informatie over de web vitaliteit: https://web.dev/articles/vitals

Graph View