Planification SEM pour 2024 : parce que 2023 ne vous a pas préparé
Préparez-vous pour 2024 avec un plan SEM solide. Apprenez à surmonter les défis et à optimiser vos efforts de marketing de recherche pour des résultats optimaux.
08 novembre 2023
Cet article a été sponsorisé par DebugBear. Les opinions exprimées dans cet article sont celles du sponsor.
Voulez-vous un site Web bien classé dans Google et qui convertit bien ?
S'assurer que vos pages se chargent rapidement est important pour offrir une bonne expérience utilisateur.
Et les trois métriques Core Web Vitals introduites par Google sont un signal de classement depuis plusieurs années maintenant.
Vous ne savez pas comment aborder l'optimisation de vos Core Web Vitals ? Cet article propose 10 conseils sur la manière d'aborder l'optimisation de la vitesse des pages et sur ce que vous pouvez faire pour résoudre certains des problèmes les plus courants.
Google Search Console comprend un rapport Core Web Vitals de haut niveau qui vous indique si certaines pages de votre site Web doivent être optimisées pour la vitesse. Google collecte ces données sur la vitesse des pages auprès de vrais utilisateurs de Chrome.
Vous pouvez cliquer sur les problèmes individuels dans la section « Pourquoi les URL ne sont pas considérées comme bonnes » et découvrir quelles pages sont affectées par le problème.
Notez que la Search Console regroupe les pages similaires. Ainsi, par exemple, la valeur Largest Contentful Paint (LCP) pour « Exemple d'URL » ne correspond pas nécessairement à la valeur globale du « Groupe LCP ».
L'exécution d'un test de vitesse de site Web en ligne vous indique la vitesse de chargement de votre site Web, vous aide à comprendre la vitesse de votre page et fournit des recommandations sur la façon de l'améliorer. Entrez simplement l'URL de votre site Web pour générer un rapport.
Vous pouvez cliquer sur chaque mesure pour en savoir plus sur les facteurs qui influencent la valeur de la mesure. Par exemple, de nombreux jalons de chargement de page peuvent être expliqués en examinant une visualisation en cascade de requêtes qui montre quand les différentes ressources de page commencent et terminent le chargement.
La vue pellicule au sommet de la cascade vous permet de corréler ce qui se passe sur le réseau avec ce que vos visiteurs peuvent voir.
Vous pouvez également voir les performances de votre site Web dans les données réelles du rapport d'expérience utilisateur Chrome (CrUX) . Ce sont les données que Google utilise comme signal de classement.
Enfin, vous pouvez trouver des recommandations de vitesse de page spécifiques à votre site Web au bas de l'onglet « Présentation ».
Lorsque vous chargez votre site Web sur une connexion réseau rapide, il se charge probablement en une seconde ou deux. Trop rapide pour vraiment voir ce qui se passe étape par étape.
L'utilisation de la limitation du réseau dans Chrome DevTools vous permet de voir comment votre site Web se charge avec une connexion plus lente. Vous pouvez regarder le contenu apparaître progressivement et utiliser cette compréhension du processus de chargement lors de vos efforts d'optimisation.
Suivez ces étapes pour charger votre site Web en utilisant une connexion plus lente :
Dans l'exemple ci-dessous, vous pouvez voir que :
Enregistrement vidéo du processus de rendu d'un site Web dans DebugBear, octobre 2023
Vous pouvez également utiliser le test gratuit DebugBear pour parcourir le processus de rendu image par image. Ou téléchargez l'enregistrement au format MP4 avec un abonnement payant à DebugBear .
Enregistrement vidéo du processus de rendu d'un site Web dans DebugBear, octobre 2023
L'outil Lighthouse de Google est largement utilisé pour tester les performances des sites Web. Il est facile à exécuter et fournit un ensemble de recommandations concrètes pour améliorer votre site Web.
Cependant, le score Lighthouse Performance n’est pas un signal de classement SEO. De nombreux sites ont un score Lighthouse faible ou moyen, mais obtiennent de bons résultats dans les trois mesures Core Web Vitals dans les données utilisateur réelles qui ont un impact sur les classements.
Lighthouse est idéal pour tester votre site Web dans un environnement fixe et vous permet d'exécuter des tests avant et après sur votre site Web avant que les données utilisateur réelles mises à jour ne soient disponibles. Mais ce qui compte en fin de compte, c’est la manière dont vos visiteurs réels perçoivent votre site Web.
Les ressources bloquant le rendu sont des fichiers qui doivent être chargés sur votre site Web avant que les navigateurs puissent afficher du contenu à l'utilisateur. Les fichiers CSS et JavaScript de la page bloquent souvent le rendu.
Voici un exemple de cascade de requêtes montrant l'impact des fichiers bloquant le rendu sur le processus de rendu de votre site Web.
Le chargement de nombreuses ressources bloquant le rendu rendra le contenu de la page plus lent et nuira à votre score Largest Contentful Paint.
Le chargement du document HTML initial est la première étape du chargement d'un site Web. La métrique Time to First Byte (TTFB) mesure la rapidité avec laquelle votre serveur Web répond à une demande pour cette ressource.
La meilleure façon d’accélérer le chargement de votre site Web est de réduire le nombre de ressources qui bloquent le rendu. Si un fichier n'est pas nécessaire pour démarrer le rendu du contenu, il ne doit pas bloquer le rendu.
Par exemple, les mots-clés defer et async sur la balise script indiquent au navigateur qu'un fichier JavaScript doit être chargé mais que la page peut commencer à s'afficher avant cela.
To keep the amount of time that rendering is blocked as short as possible you can reduce the size of render-blocking files to speed up the download.
Loading these resources from the same website domain as the HTML document also speeds up these requests, as no additional web server connections are needed.
Some page resources are essential for the page to load, and others can load later on in the page’s lifecycle. There’s only a limited amount of bandwidth available on a network connection, so you want to give browsers appropriate hints about whether a resource is important or can wait until later.
This is especially true for images on your website. When looking at just the HTML browsers can’t tell if a picture appears as a hero image or as a small icon in the website footer. Only when the browser starts displaying content does it realize which images are important.
For important images, you can use the fetchpriority attribute to tell the browser to start loading an image early:
Conversely, images further down on the page can be deprioritized by telling the browser to only start loading them when they are close to appearing in the viewport. The img loading attribute makes this easy to implement:
Page weight measures how many bytes of data need to be downloaded in order to load a web page. The more data needs to be transferred, the longer the download will take. The best way to reduce page weight depends on the type of resources that contribute most to the overall metric.
To reduce the size of images you can use modern image formats like WebP or Avif. These formats use less space to store the same content than PNG or JPEG files.
If text files like HTML documents, CSS stylesheet, or JavaScript code are contributing to your page weight, check if you’re using HTTP compression algorithms like Brotli.
To load important resources quickly you want to start loading them as early as possible. The browser quickly needs to discover the resource early on, which means it should be referenced in the HTML document.
However, sometimes longer sequential request chains form when loading a website. In the example below, the background image is only referenced from inside a CSS stylesheet. Accordingly, the network request for the image only begins after the stylesheet has finished downloading.
In these cases, preloads hints in the HTML document can tell the browser to load resources before they would otherwise be discovered. For example:
Single-page apps are websites where the page content is generated by JavaScript code in the browser. They are often built using coding frameworks like React, Vue, or Angular.
The advantage of single-page applications is that page transitions happen without completely reloading all page contents. Once a page is loaded navigations to a different URL on the website are often fast.
However, the initial page load is often slower with single-page apps as application code needs to be loaded and run to display the page contents. Visitors may just see a spinner or content placeholder initially while they wait for the page to load fully.
To address this issue, the initial page content should be rendered on the server, using server-side rendering. That way the page content loads like a traditional HTML document at first and then transitions to a client-side application.
Running a speed test on your website tells you how fast your website is today and what you can do to improve it.
However, continuously monitoring your website with DebugBear helps your team stay on top of website performance issues and ensures you get alerted if there’s a problem. Having history available over time helps you communicate with management and makes it easier to investigate newly introduced issues.
Google Core Web Vitals data is aggregated over a 28-day period, so when a regression occurs it takes a while to show in the Google data. Scheduling daily tests ensures you get notified of new issues before they impact your rankings.
This screenshot shows an example of a Largest Contentful Paint regression that first shows up in the lab data and then gradually starts to push up the Google data.
DebugBear also provides an Experiments feature that lets you try out site speed improvements without having to deploy code. That way you can go to your development with concrete ideas and an estimate of the performance impact they will have.
You can select from over 20+ test locations, analyze pages that require login or are hosted on a staging server, and keep track of your Lighthouse Performance, Accessibility, and SEO scores.
In addition to running scheduled lab tests DebugBear also offers real-user page speed monitoring. By installing an analytics snippet you can see where on your website your visitors are having a good experience and what pages you need to work on.
While lab data looks at a single consistent type of experience, real-user data better captures the full diversity of visitor experiences. Some visitors will be on slow mobile connections, use an older browser, or visit your website from a location that’s far from your website server.
Real user monitoring also allows you to debug the new Interaction to Next Paint (INP) metric that becomes one of Google’s Core Web Vitals in March 2024.
How responsive your website is for a user depends a lot on what your website is responding to: what page element is the user trying to interact with? DebugBear RUM keeps track of what UI elements users interact with most often and how quickly those elements are to user input.
With this data you know what interactions to focus on when you decide to optimize INP.
DebugBear provides a comprehensive suite of page speed monitoring features that empower your team to deliver great experiences. Sign up for a free trial today!
Ready to start optimizing your website? Sign up for DebugBear and get the data you need to deliver great user experiences.
Image Credits
Featured Image: Image by DebugBear. Used with permission.
Préparez-vous pour 2024 avec un plan SEM solide. Apprenez à surmonter les défis et à optimiser vos efforts de marketing de recherche pour des résultats optimaux.
Le carrousel du forum de Google suscite un débat, soulevant des inquiétudes concernant la désinformation et incitant l'entreprise à réagir.
YouTube introduit de nouvelles informations sur les impressions, permettant aux chaînes de voir une répartition des téléspectateurs nouveaux et connus.