J'ai trouvé et résolu un problème où mon code utm ralentissait considérablement le chargement des pages. Le problème était que le personnage principal était un ?
. La solution consistait à le changer en #
. Maintenant, nous avons littéralement des centaines de campagnes avec le ?
principal et les modifier manuellement prendra une éternité.
Est-il possible de changer ce ?
en #
lorsque la demande arrive et d'éviter le problème de chargement de page?
Il semble qu'il devrait y avoir un moyen d'utiliser Rewrite URL pour le faire.
Sinon, quelqu'un peut-il nous aider à comprendre pourquoi les points d'interrogation pointillés provoquent un chargement de page de 20 secondes alors que le hashtag est inférieur à 2?
Par exemple, le temps de chargement des éléments suivants est de 15 à 20 secondes:
http://example.com/?utm_source=df_intermediate&utm_medium=email&utm_campaign=test
Considérant que, le temps de chargement suivant est de 2-4 secondes:
http://example.com/#utm_source=df_intermediate&utm_medium=email&utm_campaign=test
Cela ressemble à un problème de mise en cache côté serveur avec votre site. (Vous devez peut-être supprimer la chaîne de requête lors de la génération d'une clé de cache?)
Le problème concerne any chaîne de requête, pas seulement les codes UTM. Essayez d’ajouter ?hello=world
à n’importe quelle URL et vous obtiendrez un temps de chargement plus long (plus de 20 secondes) pour la demande initiale (non mise en cache). Cependant, redemandez la même adresse URL et les réponses suivantes durent plus de 2 secondes - c'est avec = cache du navigateur local désactivé.
En remplaçant ?
par #
, vous modifiez la chaîne de requête en un identificateur de fragment. L'identificateur de fragment n'est pas envoyé au serveur, n'interfère donc pas avec le cache côté serveur.
Il est peut-être possible de redirection externe de l'URL de la chaîne de requête vers une URL avec un identifiant de fragment, comme dans .htaccess:
RewriteEngine On
RewriteCond %{QUERY_STRING} ^(utm_source=.*)
RewriteRule (.*) /$1#%1 [QSD,NE,R=302,L]
Cela nécessite Apache 2.4 pour l'indicateur QSD
(qui supprime la chaîne de requête). L'indicateur NE
est requis car nous réécrivons une URL avec un caractère spécial (#
) - pour éviter qu'elle ne soit codée en pourcentage.
Cependant, cela ne fait que masquer un problème sous-jacent et je pense que cela pourrait causer plus de problèmes à l'avenir.
Je pense que l'utilisation de #
au lieu de ?
est pire.
Avec une URL standard, quoi que ce soit après #
signifie normalement une balise sur la page et que la balise est définie à partir d'une valeur d'ID ou si vous voulez passer à l'ancienne, <a name='tagnamehere'>
.
Si vos pages sont principalement statiques (où le contenu d'une URL est le même quels que soient les utilisateurs accédant à l'URL), vous devez mettre les pages en cache sur le serveur afin que le chargement initial de la page puisse être lent, car puis le fichier cache est créé pendant que la page est préparée, mais la seconde fois et les fois suivants, la page se charge, elle se chargera rapidement car seul le fichier cache est lu à la place de tout le traitement de la base de données et tout ce qui fonctionne, le processeur du serveur page.
Si vos pages sont dynamiques, essayez de mettre en cache toutes les parties statiques de la page. Par exemple, si vous avez une page qui affiche tout de la même manière, à l'exception de la valeur date et heure, mettez en cache tout le reste et chargez la valeur date et heure comme d'habitude.
Lorsque vous avez terminé, utilisez webpagetest.org pour tester votre page et voir la valeur Time To First Byte (TTFB). Tout ce qui dépasse 0,2 seconde est mauvais.
Voir cette URL pour plus d'explications sur le moment où un #
peut être utilisé dans une URL: