vendredi 25 septembre 2026

À propos

Contact

Performance

Mettre en cache les appels à l’API Google Maps sur une page de contact

Une page de contact qui recharge l'API Google Maps à chaque visite ajoute des centaines de kilo-octets inutiles. Recette pour charger la carte au clic et cacher le géocodage.

Par Clément Hadrot • 30 septembre 2024 • 5 min de lecture • Aucun commentaire
Mettre en cache les appels à l'API Google Maps sur une page de contact

La page de contact d’un cabinet d’architectes affichait une carte Google Maps intégrée directement dans le contenu, chargée automatiquement dès l’arrivée sur la page via le script standard fourni par Google. Le problème : cette page, comme beaucoup de pages de contact, reçoit un trafic modeste mais régulier, souvent depuis des recherches de type « cabinet architecte + nom de ville », et chaque visite déclenchait le téléchargement d’environ 340 Ko de JavaScript avant même que le visiteur n’ait manifesté la moindre intention d’interagir avec la carte.

Le problème : une ressource lourde pour une intention rare

Sur les données d’usage collectées pendant un mois avec un simple événement de clic, moins de 8 % des visiteurs de la page de contact interagissaient réellement avec la carte (zoom, déplacement, clic sur l’itinéraire). Pour les 92 % restants, le poids de l’API Google Maps ne servait strictement à rien d’autre qu’à afficher une image statique de carte qu’une simple capture aurait tout aussi bien montrée.

La recette : charger la carte au clic plutôt qu’au chargement

La solution retenue remplace le script Google Maps par une image statique légère (via l’API Static Maps, qui ne pèse que quelques dizaines de kilo-octets) affichée au chargement de la page, avec un bouton superposé invitant à afficher la carte interactive. Le script complet de l’API Maps n’est chargé dynamiquement qu’au moment du clic.

L'essentiel à retenir : La carte n'a pas besoin d'être chargée avant une interaction ; Le géocodage d'une adresse fixe ne change jamais, donc se cache ; Un clic déclenche le chargement complet sans pénaliser le LCP
<div class="carte-contact" data-lat="45.7640" data-lng="4.8357">
  <img
    src="https://maps.googleapis.com/maps/api/staticmap?center=45.7640,4.8357&zoom=15&size=600x300&key=CLE_API"
    alt="Localisation du cabinet"
    width="600" height="300"
    loading="lazy"
  >
  <button type="button" class="bouton-carte-interactive">Afficher la carte interactive</button>
</div>
document.querySelector('.bouton-carte-interactive').addEventListener('click', function (e) {
  const conteneur = e.target.closest('.carte-contact');
  const lat = parseFloat(conteneur.dataset.lat);
  const lng = parseFloat(conteneur.dataset.lng);

  const script = document.createElement('script');
  script.src = 'https://maps.googleapis.com/maps/api/js?key=CLE_API&callback;=initCarteContact';
  script.async = true;
  window.initCarteContact = function () {
    const carte = new google.maps.Map(conteneur, { center: { lat, lng }, zoom: 15 });
    new google.maps.Marker({ position: { lat, lng }, map: carte });
  };
  document.head.appendChild(script);
  e.target.remove();
});

Mettre en cache la clé de géocodage

Un deuxième point observé sur ce site : l’adresse du cabinet était convertie en coordonnées latitude-longitude à la volée à chaque chargement de la page d’administration où l’adresse est modifiable, via un appel à l’API de géocodage de Google. Or l’adresse du cabinet ne change pratiquement jamais, ce qui rendait cet appel systématique parfaitement inutile la plupart du temps.

Le correctif consiste à mettre en cache le résultat du géocodage dans une option WordPress, et à ne relancer l’appel que si l’adresse source a effectivement changé depuis le dernier enregistrement.

function geocoder_adresse_cabinet( $adresse ) {
    $cache_key = 'geocodage_' . md5( $adresse );
    $coordonnees = get_option( $cache_key );

    if ( false !== $coordonnees ) {
        return $coordonnees;
    }

    $reponse = wp_remote_get( add_query_arg( [
        'address' => rawurlencode( $adresse ),
        'key'     => GOOGLE_MAPS_API_KEY,
    ], 'https://maps.googleapis.com/maps/api/geocode/json' ) );

    if ( is_wp_error( $reponse ) ) {
        return false;
    }

    $donnees = json_decode( wp_remote_retrieve_body( $reponse ), true );
    if ( empty( $donnees['results'][0]['geometry']['location'] ) ) {
        return false;
    }

    $coordonnees = $donnees['results'][0]['geometry']['location'];
    update_option( $cache_key, $coordonnees, false );

    return $coordonnees;
}

Variante : se passer entièrement de l’API Maps pour l’image statique

Pour les sites qui souhaitent réduire encore la dépendance à Google avant même le clic, une variante consiste à générer l’image statique une seule fois en tâche de fond et à l’héberger localement plutôt que de l’appeler à chaque chargement de page via l’API Static Maps, ce qui supprime la requête sortante vers Google au chargement initial tout en gardant l’expérience visuelle identique.

  • Aucune ressource Google Maps chargée avant une intention explicite du visiteur.
  • Le géocodage d’une adresse fixe est calculé une seule fois puis mis en cache.
  • L’image statique peut elle-même être hébergée localement pour éviter tout appel sortant par défaut.

Hors périmètre

Cette recette porte sur la réduction du coût de Google Maps lui-même, pas sur son remplacement par des alternatives comme OpenStreetMap ou Mapbox, qui posent des questions différentes de couverture cartographique et de tarification à traiter séparément selon les besoins du projet.

La carte la plus rapide est celle qu’on ne charge pas tant que personne n’a demandé à la voir bouger.

En résumé

Le report du chargement de l’API Google Maps au clic a économisé environ 340 Ko de JavaScript sur le chargement initial de la page de contact, sans dégrader l’expérience des visiteurs qui souhaitent réellement explorer la carte. La mise en cache du géocodage, bien que plus modeste en impact direct sur la performance perçue, a supprimé un appel réseau sortant systématique à chaque enregistrement de la page d’administration.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi