Chargement rapide d’un site d’architecte chargé de photos
La vitesse d’un site d’architecte se joue sur ses photos de projet. Compression, format et largeur servis selon l’écran, chargement différé, polices et animations : nous réglons chaque poste, puis nous mesurons page par page.

Un site d’architecture est un site d’images lourdes, et c’est là que se joue sa vitesse.
Vos photos de projet sortent d’un reflex ou du studio d’un photographe. Elles pèsent souvent entre 4 et 12 Mo pièce. Publiées telles quelles, une page de réalisation en aligne quinze. Sur une connexion mobile ordinaire, le visiteur voit un écran vide, puis un titre, puis des images qui se remplissent par bandes. Rien ne le retient jusqu’à la troisième.
Le réflexe est alors de sacrifier la qualité, et aucun cabinet n’accepte de voir un rendu de façade se dégrader en aplats flous. Le compromis n’est pas là. Une photo affichée sur 800 pixels de large n’a pas besoin d’en contenir 6000. Le poids qu’on retire est celui que l’écran ne pouvait pas montrer.
Ce que nous faisons
Compression image par image : nous compressons chaque photo, puis nous comparons les deux versions côte à côte, à taille réelle. Le béton, le ciel et le verre supportent une compression forte. Les rendus 3D à dégradés fins et les plans supportent moins. Le réglage se choisit par image, jamais en bloc sur toute la bibliothèque.
Un format et une largeur par écran : chaque photo est déclinée en plusieurs largeurs et servie en WebP, avec un repli JPEG. Un téléphone reçoit un fichier de 800 pixels, un 27 pouces reçoit le grand format. Même page, deux poids sans rapport.
Chargement différé et ordre de priorité : la première image visible part en priorité, avec ses dimensions déclarées pour que la mise en page ne saute pas quand elle arrive. Les suivantes ne se chargent qu’à l’approche du défilement. Sur une page de projet à trente visuels, l’objectif est que seules les premières images comptent dans le poids de démarrage.
Ce qui retarde le texte : deux graisses de police au maximum, en woff2, hébergées avec le site et préchargées, pour éviter les titres invisibles pendant deux secondes. Côté animation, les apparitions au défilement passent par le CSS quand c’est possible et le JavaScript se charge après le contenu. Beaucoup de sites d’architecture masquent tout le texte jusqu’à l’exécution d’un script d’entrée. Le texte doit être lisible avant l’effet.
Mesure sur ce que Google regarde : nous relevons les Core Web Vitals page par page, sur mobile et sur ordinateur, avant et après : temps d’affichage du plus grand élément, stabilité de la mise en page, réactivité au premier geste. Le poids de chaque page figure dans le même tableau.
Ce que ça change
Le raisonnement est simple : un visiteur qui voit une photo de projet en quelques instants n’a aucune raison de partir avant d’avoir vu votre travail. Celui qui attend un écran blanc juge votre cabinet sur cette attente, avant d’avoir vu un seul bâtiment. Ce que nous retirons du poids d’une page, c’est ce que l’écran ne montrait pas : le gain de temps d’affichage qui en découle est relevé avant et après sur vos propres pages, et vous pouvez refaire la mesure vous-même.
Côté moteurs, la vitesse est un signal parmi d’autres, jamais un levier de position à lui seul. Son effet est surtout indirect : les pages sont explorées plus facilement, et celles qu’on ouvre depuis un téléphone sont lues au lieu d’être abandonnées.
Les limites
Nous optimisons les fichiers que vous nous confiez, nous ne retouchons pas vos photos et nous ne rattrapons pas un projet mal photographié. Nous ne maîtrisons ni la connexion du visiteur, ni les outils ajoutés après la livraison : un chat, un pixel publicitaire ou une carte interactive alourdissent la page et défont une partie du travail. Nous ne promettons pas un score parfait dans un outil de test, ni un chiffre de vitesse annoncé d’avance, mais des mesures que vous pouvez refaire vous-même.
La vitesse se décide pendant la construction
Elle ne se rattrape pas à la fin, c’est pourquoi elle appartient au service Site web. La structure retenue au développement Webflow détermine ce qu’il y aura à charger, le CMS de réalisations fixe le nombre d’images par page de projet, et la version mobile est l’endroit où chaque mégaoctet se paie le plus cher.
Ce qui est prévu au livrable
- Photos de projet compressées une à une, fichiers d’origine conservés
- Chaque image déclinée en plusieurs largeurs, servie en WebP avec repli JPEG
- Chargement différé sous la ligne de flottaison, dimensions déclarées sur chaque image
- Polices en woff2 hébergées avec le site, deux graisses au maximum
- JavaScript d’animation chargé après le texte
- Relevé Core Web Vitals et poids par page, avant et après
