Performance et optimisation des rapports

Limiter la période par défaut (gain : -70 % temps de chargement)

Un client avait configuré son rapport pour afficher "toutes les données depuis 2019". Cela paraît logique, non  ? Il voulait afficher l’historique complet sauf que son rapport mettait 25 secondes à s’ouvrir et personne ne l’utilisait.

Il a modifié la période pour afficher les 90 derniers jours par défaut et le temps de chargement est passé à trois secondes. Même rapport, mêmes graphiques, seule la limite de période a été modifiée.

Pourquoi cela fonctionne ? Parce que vous passez de 2 millions de lignes à 50 000 lignes.

Et franchement, pour 90 % des analyses quotidiennes, les 90 derniers jours suffisent largement. Si vous avez vraiment besoin de l’historique complet, ajoutez un bouton pour étendre la période. Mais ne l’affichez pas par défaut.

Réduire le nombre de graphiques par page

Votre page d’accueil ressemble au cockpit d’un avion ? Avec quinze graphiques qui se chargent en même...

Les trois coupables habituels

Après avoir déboggé des centaines de rapports, je retrouve toujours les mêmes suspects.

Pousser les calculs vers la source

Pour mieux comprendre, voyons un exemple concret.

Vous avez une table BigQuery analytics.events avec 500 000 lignes. Vous voulez classer vos sources en "Paid" ou "Organic".

Mauvaise approche : vous connectez la table brute à Data Studio et créez un champ calculé :

CASE 
  WHEN REGEXP_MATCH(source, ".*(cpc|ads|paid).*") THEN "Paid" 
  ELSE "Organic" 
END  

À chaque ouverture du rapport, Data Studio charge 500 000 lignes et calcule cette formule 500 000 fois. Cela donne 8 secondes de chargement, 750 Go scannés par mois sur BigQuery.

La solution est de créer une vue BigQuery qui fait le calcul une fois :

CREATE OR REPLACE VIEW analytics.dashboard_data AS 
SELECT 
  date, 
  source, 
  country, 
  sessions, 
  revenue, 
  
-- Calculs faits UNE fois 
  CASE 
    WHEN REGEXP_CONTAINS(source, r'.*(cpc|ads|paid).*') THEN 'Paid' 
    ELSE 'Organic' 
  END...

La règle : un écran, un message

Je l’ai dit tout au long de ce livre, mais je le redis : maximum 6-8 graphiques par page. Au-delà, Data Studio commence à sérialiser les requêtes au lieu de les traiter en parallèle. Cela devient de plus en plus lent.

Par exemple une page surchargée avec 15 KPI, 5 graphiques et 3 tableaux engendre 30 secondes de chargement.

Par contre une page optimisée avec 4 KPI, 2 graphiques et une navigation claire vers les détails charge en 3 secondes.

Maîtriser les filtres intelligents

Comprendre la facturation BigQuery

Les coûts BigQuery ont été évoqués au chapitre Connecter et gérer ses données dans Data Studio. Nous approfondissons ici les techniques concrètes pour les réduire.

Tarification 2024 :

Cela paraît généreux et ça l’est. Jusqu’au moment où cela ne l’est plus.

Exemple de dérapage :

Table : 10 Go

Rapport : 8 graphiques

Consultations : 20 fois par jour

Calcul : 10 Go × 8 graphiques x 20 consultations x 30 jours = 48 To par mois

Facture : 235 €. Pour UN SEUL rapport.

Techniques d’optimisation BigQuery

CREATE TABLE analytics.events_partitioned 
PARTITION BY DATE(event_timestamp) 
AS SELECT * FROM analytics.events  

Signaux d’alerte précoce

Plutôt que de subir les problèmes, anticipez-les en surveillant ces métriques clés. C’est comme surveiller la température d’un moteur avant qu’il casse.

Temps de chargement

Utilisation des quotas

Gardez un œil sur la consommation de vos quotas techniques. Sur :

Enfin...

Checklist pré-production (15 minutes)

Avant de partager votre rapport, accordez-vous 15 minutes pour vérifier ces trois aspects. 

Sources de données

Assurez-vous que :

Structure du rapport

Vérifiez que :

Test de charge

Enfin, ouvrez le rapport en navigation privée (sans cache) et vérifiez que le chargement initial ne dépasse pas 10 secondes et qu’un changement de filtre s’exécute en moins de 5 secondes.

Dépannage express

Voici les trois problèmes les plus fréquents et comment les résoudre rapidement.

"Mon rapport ne se charge plus"