Ottimizzare le API di Google Maps: come ho diviso la bolletta per 5

Il problema: una bolletta che esplode a ogni picco di traffico

VoglioMap è una mappa interattiva che localizza i rivenditori Voglio Bene nel mondo. A ogni visita, il browser carica la mappa, geolocalizza l'utente, geocodifica il suo indirizzo, calcola itinerari, mostra dei marker. Moltiplica tutto questo per qualche centinaio di visitatori al mese, e la bolletta di Google Maps sale in fretta.

All'inizio mi aggiravo intorno ai 250 €/mese. Non catastrofico, ma inutile: la maggior parte di quelle chiamate erano ridondanti. Con qualche ottimizzazione mirata sono sceso sotto i 50 €/mese - cioè -80% - senza perdere funzionalità.

Ecco le 4 tecniche che hanno fatto la differenza.

1. Cachare il geocoding in database

Il geocoding (trasformare un indirizzo in coordinate GPS) è la chiamata più costosa dell'API Maps. Ed è anche quella più frequente: ogni volta che viene aggiunto un nuovo rivenditore, ogni volta che ri-geocodifichi gli indirizzi durante una visita.

Ma un indirizzo non cambia tutti i giorni.

Ho aggiunto una tabella geocode_cache in MySQL:

CREATE TABLE geocode_cache (
    address_hash VARCHAR(64) PRIMARY KEY,
    address TEXT,
    lat DECIMAL(10, 7),
    lng DECIMAL(10, 7),
    geocoded_at DATETIME
);

Prima di ogni chiamata all'API Geocoding calcolo l'hash SHA-256 dell'indirizzo normalizzato e controllo se è già in cache. Se sì, restituisco le coordinate salvate. Se no, chiamo Google, salvo il risultato e lo riutilizzo per tutte le richieste future.

Risultato: 95% delle chiamate Geocoding eliminate. La bolletta su quella voce è passata da ~80 €/mese a ~5 €/mese.

2. Rate limiting sugli endpoint pubblici

Senza rate limiting, chiunque può martellare il tuo frontend (uno script che ricarica la pagina, un bot malevolo) e far esplodere la bolletta in poche ore. È successo una volta al mio sito - e la brutta sorpresa si è vista sulla fattura del mese successivo.

Ho aggiunto un middleware lato PHP:

function checkRateLimit($ip) {
    $key = "rate:$ip";
    $count = apcu_fetch($key) ?: 0;
    if ($count >= 60) return false; // 60 richieste / ora max
    apcu_store($key, $count + 1, 3600);
    return true;
}

60 richieste per IP all'ora sono ampiamente sufficienti per un uso umano e bloccano gli abusi. Ho anche aggiunto un check lato API per gli endpoint sensibili (ricerca, navigazione), con una soglia più bassa (10/h per la navigazione).

Risultato: zero picchi anomali da allora. La bolletta è diventata prevedibile.

3. Lazy load dei marker e clustering

Mostrare tutti i marker tutti insieme quando ne hai qualche centinaio sovraccarica il browser e fa scattare più chiamate all'API. La soluzione: caricare solo i marker visibili nel viewport.

Uso l'evento bounds_changed di Google Maps per ottenere le coordinate visibili, poi faccio un fetch dei marker in quell'area. Lato server è un semplice WHERE lat BETWEEN x AND y AND lng BETWEEN x AND y - veloce con indici spaziali.

Ho anche attivato il MarkerClusterer: invece di mostrare 200 marker individuali quando si fa zoom out, vengono raggruppati in cluster numerati. Molto più leggibile, e molto meno DOM da gestire.

Risultato: meno chiamate a places.nearbySearch() e un sito che resta fluido anche con tanti rivenditori.

4. Static Maps per le viste non interattive

Non tutte le pagine hanno bisogno di una mappa interattiva. Sulle schede dei singoli rivenditori, per esempio, l'utente vuole solo vedere la posizione - non andrà a fare zoom o esplorare.

Per quei casi ho sostituito l'embed JavaScript con l'API Static Maps, che restituisce un'immagine PNG. Il costo è ~10 volte inferiore per chiamata, ed è anche più veloce da caricare (una semplice immagine vs uno script JS che inizializza la mappa).

<img src="https://maps.googleapis.com/maps/api/staticmap?
    center=43.6108,3.8767
    &zoom=14
    &size=400x300
    &markers=color:red%7C43.6108,3.8767
    &key=YOUR_API_KEY"
/>

Bonus: le immagini vengono cachate dal browser, quindi tornare sulla stessa scheda = zero nuove chiamate.

Risultato: ~30% delle chiamate JavaScript convertite in Static Maps, a ~10x più economiche.

Il bilancio in cifre

E l'esperienza utente? Nessun degrado visibile. Al contrario, il sito carica più velocemente (Static Maps + lazy load dei marker) ed è protetto dagli abusi.

Cosa porto a casa

L'API di Google Maps non è cara in assoluto - è cara di default, perché non fa nessuna ottimizzazione per te. Paghi ogni chiamata, sia utile o ridondante.

Cachare, fare rate limiting, lazy-loadare: è roba di base, ma raramente viene fatta nelle implementazioni standard. Se parti da una mappa non ottimizzata, dividere la bolletta per 3 o 5 è probabilmente a portata di qualche ora di sviluppo.

E se il tuo traffico esplode un giorno: le tue ottimizzazioni ti proteggono dallo shock tariffario. Anche questo è ROI.