Guide d'optimisation

Ce guide décrit plusieurs stratégies permettant d'optimiser votre utilisation des API Google Maps concernant la sécurité, les performances et la consommation.

Sécurité

Consulter les bonnes pratiques liées à la sécurité

Les clés API sont des identifiants spécifiquement associés à un projet, qui méritent les mêmes précautions que les ID utilisateur et les mots de passe. Consultez les bonnes pratiques concernant les clés API pour protéger vos clés contre tout usage non intentionnel pouvant entraîner une utilisation imprévue du quota et des frais inattendus pour votre compte.

Utiliser des clés API pour accéder aux API Google Maps

Les clés API constituent la méthode d'authentification privilégiée pour accéder aux API Google Maps. Même si les ID client sont encore acceptés, les clés API utilisent des fonctionnalités de sécurité plus précises et peuvent être ajustées pour fonctionner avec des adresses Web, des adresses IP et des SDK pour mobile spécifiques (Android et iOS). Pour savoir comment créer et sécuriser une clé API, consultez la page "Utiliser une clé API" pour chaque API ou SDK que vous utilisez (par exemple, pour l'API Maps JavaScript, consultez sa page dans Utiliser une clé API).

Performances

Utiliser un intervalle exponentiel entre les tentatives pour gérer les erreurs

Si vos applications rencontrent des erreurs liées à un trop grand nombre de tentatives d'appel d'une API en peu de temps (erreurs de RPS, par exemple), vous pouvez utiliser un intervalle exponentiel entre les tentatives pour permettre le traitement des requêtes.

Plus précisément, vous pourrez ainsi ajuster le rythme de vos requêtes. Dans votre code, ajoutez un délai d'attente de S secondes entre les requêtes. Si la requête génère toujours une erreur RPS, multipliez le délai d'attente par deux, puis envoyez une autre requête. Continuez à ajuster le délai d'attente jusqu'à ce que la requête s'affiche sans erreur.

Envoyer des requêtes d'interaction utilisateur à la demande

Les requêtes API qui incluent une interaction utilisateur ne doivent être envoyées qu'à la demande. Le système doit donc attendre que l'utilisateur final effectue une action (on-click, par exemple) pour lancer la requête API, puis utiliser les résultats pour charger une carte, définir une destination ou afficher les informations appropriées. Utiliser une approche à la demande évite d'envoyer des requêtes inutiles aux API, ce qui réduit la consommation des API.

Éviter d'afficher le contenu en superposition lorsque vous déplacez une carte

Évitez d'utiliser la méthode Draw() pour afficher un contenu personnalisé en superposition sur une carte au moment où un utilisateur est susceptible de déplacer la carte. Sachant que la carte est redessinée chaque fois qu'un utilisateur la déplace, insérer simultanément un contenu en superposition sur la carte peut provoquer un retard ou un stuttering visuel. Vous ne devez ajouter du contenu en superposition sur une carte ou en supprimer que lorsque l'utilisateur arrête d'interagir avec la carte (via un zoom ou panoramique).

Éviter les opérations intensives dans les méthodes Draw

En règle générale, nous vous recommandons d'éviter les opérations qui exigent des performances élevées et ne sont pas liées au dessin dans une méthode Draw(). Par exemple, évitez les actions ou éléments suivants dans le code de la méthode Draw() :

  • Requêtes affichant une grande quantité de contenu
  • Nombreuses modifications apportées aux données affichées
  • Manipulation de nombreux éléments DOM (Document Object Model)

Ces opérations peuvent ralentir les performances et générer un retard ou un stuttering visuel lorsque la carte s'affiche.

Utiliser des images matricielles pour les repères

Utilisez des images matricielles (au format PNG ou JPG, par exemple) lorsque vous ajoutez des repères pour identifier un emplacement sur une carte. Évitez d'utiliser des images SVG (Scalable Vector Graphics), car leur affichage peut ralentir le chargement lorsque la carte est redessinée.

Optimiser les repères

L'optimisation permet d'améliorer les performances en affichant de nombreux repères sous la forme d'un seul élément statique. Cette fonctionnalité est utile lorsqu'un grand nombre de repères est requis. Par défaut, l'API Maps JavaScript décide si un repère est optimisé ou non. Lorsqu'il en existe un grand nombre, l'API Maps JavaScript tente d'optimiser leur affichage. Dans certains cas, ce n'est pas possible, car l'API Maps JavaScript a parfois besoin d'afficher les repères sans les optimiser. Désactivez l'affichage optimisé des fichiers PNG ou GIF animés, ou lorsque chaque repère doit être affiché en tant qu'élément DOM distinct.

Créer des groupes pour gérer l'affichage des repères

Pour vous aider à gérer l'affichage des repères afin d'identifier des emplacements sur une carte, créez un groupe de repères à l'aide de la bibliothèque Marker Clusterer, qui inclut les options suivantes :

  • Taille de la grille, pour spécifier le nombre de repères à regrouper
  • Zoom maximal, pour spécifier le niveau de zoom maximal dans lequel afficher le groupe
  • Chemins des images graphiques à utiliser comme icônes des repères

Consommation

Pour planifier votre budget et maîtriser vos coûts :

  • Définissez une alerte budgétaire pour suivre l'évolution de vos dépenses par rapport à un montant donné. Le budget ne limite pas l'utilisation des API. Vous êtes seulement averti lorsque le montant de vos dépenses s'approche du montant spécifié.
  • Limitez votre utilisation quotidienne d'API pour maîtriser le coût d'utilisation de vos API facturables. En définissant des limites concernant les requêtes par jour, vous pouvez restreindre vos dépenses. Déterminez votre limite quotidienne à l'aide d'une simple équation, en fonction du montant que vous souhaitez dépenser : (Dépenses mensuelles/prix unitaire)/30 = limite des requêtes par jour (pour une API). Votre implémentation peut utiliser plusieurs API facturables. Modifiez donc l'équation au besoin. Un crédit API Google Maps de 200 $ est disponible chaque mois. Assurez-vous d'en tenir compte dans votre calcul.
  • Utilisez plusieurs projets pour effectuer le suivi de votre utilisation tout en l'isolant et la hiérarchisant. Par exemple, supposons que vous utilisiez régulièrement les API Google Maps Platform dans vos tests. En créant un projet distinct pour vos tests, avec ses propres quotas et clés API, vous pouvez effectuer des tests approfondis tout en veillant à ne pas dépasser votre budget.

Gérer la consommation dans Maps

Nous vous recommandons de n'utiliser qu'une seule carte par page pour optimiser l'affichage des cartes, car, en général, les utilisateurs n'interagissent qu'avec une carte à la fois. Votre application peut manipuler la carte pour afficher différents ensembles de données, en fonction de l'interaction et des besoins des utilisateurs.

Utiliser des images statiques

Les requêtes qui utilisent des images dynamiques (Dynamic Maps et Dynamic Street View) coûtent plus cher que Static Maps and Static Street View. Si vous ne prévoyez pas d'interaction utilisateur avec Maps ou Street View (zoom ou panoramique), utilisez les versions statiques de ces API.

Les vignettes (cartes et photos miniatures) sont aussi recommandées pour Static Maps et Static Street View. Ces éléments sont facturés à un tarif inférieur et en cas d'interaction utilisateur (clic). Ils peuvent diriger les utilisateurs vers une version dynamique et leur permettre par là même de profiter d'une expérience Google Maps complète.

Utiliser l'API Maps Embed

Vous pouvez utiliser l'API Maps Embed pour ajouter gratuitement une carte avec un seul repère ou une carte dynamique. Utilisez l'API Maps Embed pour les applications qui nécessitent un seul repère et n'exigent aucune personnalisation de la carte. Les requêtes API Maps Embed utilisant les modes Directions, View ou Search sont facturées (voir la grille tarifaire pour plus d'informations).

Utiliser les SDK Maps pour applications mobiles

Pour les applications mobiles, utilisez le SDK Maps pour Android ou le SDK Maps pour iOS lorsque vous affichez une carte. Utilisez l'API Maps Static ou l'API Maps JavaScript lorsque les conditions excluent l'utilisation de SDK pour mobile.

Gérer la consommation dans Routes

Limiter les points de cheminement de l'API Directions

Dans la mesure du possible, faites en sorte qu'un utilisateur ne puisse pas saisir plus de 10 points de cheminement dans une requête. En effet, le tarif est plus élevé pour les requêtes contenant plus de 10 points de cheminement.

Utiliser l'optimisation de l'API Directions pour un itinéraire optimal

Le tarif est plus élevé pour les requêtes qui utilisent l'argument d'optimisation du point de cheminement. Pour en savoir plus, consultez Optimiser les points de cheminement.

L'argument d'optimisation trie les points de cheminement pour assurer un acheminement optimal. En d'autres termes, le trajet entre les points A et E est de meilleure qualité lorsqu'il est optimisé (A-B-C-D-E) qu'avec une suite de points aléatoires dans un trajet non optimisé (A-D-B-C-E, par exemple).

Utiliser des modèles de trafic en temps réel dans les API Directions et Distance Matrix

Les requêtes API Directions et Distance Matrix incluant des modèles de trafic en temps réel sont facturées à un tarif plus élevé. Pour activer les modèles de trafic en temps réel, définissez l'heure de départ sur now.

Si les modèles de trafic sont omis d'une requête, les résultats ne sont basés que sur des facteurs physiques : routes, distance et limitations de vitesse.

Utiliser Route Traveled et Nearest Road lorsque les données GPS sont imprécises

Route Traveled et Nearest Road sont des fonctionnalités de l'API Maps Roads incluses dans le niveau avancé et facturées à un tarif plus élevé. Utilisez ces fonctionnalités lorsque les données GPS sont imprécises et lorsque l'API Roads peut vous aider à déterminer la route correcte. Speed Limits, autre fonctionnalité de l'API Roads, n'est disponible que pour les clients qui utilisent le suivi des ressources.

Échantillonner les zones de limitation de vitesse avec des intervalles de 5 à 15 minutes

Afin de réduire le volume des appels au service Speed Limit de l'API Maps Roads, échantillonnez les emplacements de vos ressources à intervalles de 5 à 15 minutes. La valeur exacte dépend de la vitesse de déplacement de la ressource. Si une ressource est immobile, un seul échantillon d'emplacements suffit. Il n'est pas nécessaire d'effectuer plusieurs appels.

Pour minimiser la latence globale, appelez le service Speed Limit une fois que vous avez collecté des données au lieu d'appeler l'API chaque fois que vous recevez l'emplacement d'une ressource en mouvement.

Gérer la consommation dans Places

Utiliser l'option de saisie semi-automatique adaptée à votre cas d'utilisation

Identifiez l'option de saisie semi-automatique la mieux adaptée à votre cas d'utilisation (le coût des deux options est identique). La différence réside dans la façon dont les utilisateurs finaux de votre application peuvent exploiter les API.

  • Saisie semi-automatique – Par requête : cette option est idéale lorsqu'une seule entrée suffit (un formulaire permettant à l'utilisateur d'indiquer son adresse postale, par exemple).
  • Saisie semi-automatique – Par session : cette option est recommandée lorsque plusieurs entrées sont requises (recherche d'un hôtel ou d'un restaurant, par exemple).

L'option Saisie semi-automatique – Par session permet d'obtenir des résultats illimités, mais elle nécessite d'intégrer des jetons pour garantir la validité des sessions. Si une session non valide se produit, les frais de l'option Saisie semi-automatique – Par requête sont appliqués par frappe de l'utilisateur, ce qui peut entraîner une facturation plus élevée. Pour en savoir plus sur cette fonctionnalité, consultez Place Autocomplete.

Afficher des données pour des champs spécifiques dans les requêtes Place Details et Place Search

Vous pouvez personnaliser les requêtes Place Details et Place Search pour afficher les données de champs spécifiques utilisés dans votre application. Ces champs sont répartis dans les catégories suivantes : Basic, Contact et Atmosphere. Les requêtes ne spécifiant aucun champ reçoivent des données pour tous les champs.

La facturation des requêtes Place Details dépend des types et du volume de données demandés. Les requêtes ne spécifiant aucun champ sont facturées au tarif complet. Pour en savoir plus, consultez Place Details et Place Search.

Réduire les coûts grâce à l'API Geocoding

Si votre application gère des adresses saisies par l'utilisateur, il peut arriver qu'elles soient ambiguës (incomplètes, mal orthographiées ou dans un format incorrect). Évitez ce type d'ambiguïté grâce à la saisie semi-automatique, puis utilisez les ID de lieux pour obtenir l'emplacement de ces lieux.

Toutefois, si vous disposez d'une adresse exacte (ou presque), vous pouvez réduire les coûts en utilisant Geocoding au lieu d'Autocomplete. Pour en savoir plus, consultez Bonnes pratiques pour géocoder des adresses.