Problème :

Que faire si on a plus que 9 arguments à gérer dans une règle de réécriture ?

Solution :

On peut utiliser l'instruction RewriteMap avec le paramètre prg, qui lui apelle un script Perl.

Exemple :

Contenu du fichier .htaccess :

RewriteMap manyargs prg:/home/projet/splitargs.pl

RewriteEngine On

RewriteRule ^/blog/(.*)$ /blog.php?$(manyargs:$1) [PT]

Contenu du fichier splitargs.pl :

#!/usr/bin/perl

$|=1

my $i=0;

my @args = split !/!, $_;

foreach my $args (@args) {

  $i++;

  $return .= "&arg$i=$arg";

}

$return =~ s/^&//;

print $return

Discussion :

Cette règle permettra un nombre indéfini d'arguments d'apparaître dans l'URL et générera une requête avec ces arguments nommés séquentiellement.

Cela peut s'avérer très utile dans le cas ou on a plus de 9 arguments à traiter. Le traitement des expressions régulières dans mod_rewrite est limité à 9 arguments tout simplement parce que le 10e argument ($10) serait indifférentiable du 1er ($1) suivi d'un "0".

Je trouve étrange qu'on soit limité de la sorte... selon moi il aurait pu y avoir un moyen d'échapper les arguments à 2 chiffres. Mais bon, avec l'instruction RewriteMap et un simple script Perl, il est possible de pallier cette limitation!

• Vous devez toujours être en ligne... en d'autres mots, si votre connexion internet flanche, vous perdez votre progression dans le jeu.
  L'implémentation du jeu ici est cruciale. Les développeurs pourraient forcer le jeu à se fermer et vous perdriez votre progression, ou ils pourraient simplement vous donner un avertissement en attendant que votre connexion internet revienne. Vous pourriez perdre votre connexion à cause de votre ISP (Bell, Vidéotron, etc.) à cause de votre rooter ou simplement à cause d'un câble qui s'est fait manger par votre chien.
• Il deviendrait impossible de revendre votre jeu. Le jeu serait associé à votre compte Ubisoft, vous seriez donc obligé de vendre votre compte Ubisoft aussi, ce qui est impossible selon la condition d'utilisation (TOS) des comptes Ubisoft.
• Si les serveurs d'Ubisoft sont fermés pour réparation ou pour une mise à niveau, vous serez dans l'impossibilité de jouer, parce que les parties enregistrées sont sur leur serveur et l'authentification est impossible à faire.
• Possiblité de jouer sans CD/DVD, qui était le DRM par défaut de plusieurs jeux.

Les bons côtés maintenant :

• Si tout fonctionne, on pourrait rêver à une diminution du prix des jeux parce qu'il y aurait moins de piratage, mais j'imagine que le prix va rester le même et les profits seront redistribués sur d'autres franchises et le développement de nouveaux jeux.
• Possiblité de jouer chez un ami avec votre personnage sans avoir à amené votre partie enregistrée. Le fait d'avoir votre partie sur leurs serveurs vous permet de jouer de n'importe ou, pourvu que le jeu soit installé. En théorie c'est une bonne idée, mais en pratique, si vous allez chez ami, c'est pas pour qu'il vous regarde jouer et si vous le faites, vous amenez votre ordinateur. Pourtant, Ubisoft met l'emphase sur ce "très" bon côté.
• Possiblité d'avoir des amis et de parler avec eux pendant que vous jouer, un peu comme fait Steam ou Battle.net entre autres.

En en parlant avec Guillaume, nous avons trouvé des bons côtés qui malheureusement, n'ont pas été mentionnés par Ubisoft pour l'instant :

• Des marchants légendaires se promenant de joueur en joueur et vendant les items achetés/vendus par les autres joueurs. Nous aurions de vrais marchands itinérants!
• Des troupes ennemies légendaires se promenant aussi de joueur en joueur. Présentement les ennemis sont gérés au hasard ou reviennent toutes les X minutes.
• Rendre possible de switcher entre le jeu single player et multiplayer plus facilement et avec plus de transparence. Je vois particulièrement l'intérêt ici, vous êtes en train de jouer avec vos amis et tout à coup votre petit frère commence à télécharger un film en HD sur sa Xbox360, il serait possible de tomber en mode single player et continuer à jouer où vous étiez rendu. Le système d'authentification et d'enregistrement de partie demande beaucoup moins de bande passante qu'un jeu complètement en ligne.
• Avoir les bons cotés des MMO sans avoir les mauvais cotés : Système de vente aux enchères sans les serveurs trop lents par exemple.
• Avoir des émissaires ou des factions qui se promènent entre les joueurs, selon les missions accomplies et les choix faits par les joueurs, le monde diplomatique et ou physique du jeu pourrait changer. Par exemple, 60% des gens décident d'aider le scientifique fou et une ville complète disparaît de la carte pour tous les joueurs. Une ville se fait conquérir par le royaume ennemi parce que la majorité des joueurs ont décidé d'aider le royaume.

Beaucoup de bonnes (et mauvaises!) idées peuvent ressortir avec un système qui oblige le joueur à avoir une connexion internet constante. Les implémentations de ces exemples se font au niveau du jeu et non pas au niveau du DRM, mais si le DRM oblige l'utilisateur à être connecté, les implémentations deviennent beaucoup plus faciles à réaliser. Personnellement, j'espère que le système fonctionnera et qu'il profitera des ouvertures qu'il apporte, mais j'ai bien peur que beaucoup de pirates s'amuseront à faire planter les serveurs de Ubisoft pour les obliger à le retirer. Si les serveurs ne tiennent pas le coup devant les pirates, les gens vont commencer à poursuivre Ubisoft parce que les biens qu'ils ont achetés sont inutilisables.

Pour des questions SEO, il est intéressant de maîtriser certaines techniques de réécriture d'adresses sous Apache avec les fichiers .htaccess. Si l'adresse ne change pas dans la barre d'adresse du navigateur, on parle de redirection interne. Si l'adresse change, on parle de redirection externe, souvent des redirections retournant le code HTTP 301 indiquant que la ressource est déménagée à la nouvelle adresse de façon permanente. Les redirections internes sont les plus complexes à comprendre car intangibles, elles permettent de créer une structure complètement virtuelle pour un site Web qui lui serait généré à partir du même fichier PHP. Wordpress en est un bon exemple!

Il faut garder en tête que le mod_rewrite est appelé chaque fois qu'une demande HTTP est faite sur un fichier. Il faut donc être concis et s'assurer des limites de notre fichier .htaccess pour éviter des comportements incompréhensibles. Le plus complexe dans le URL Rewriting c'est les expressions régulières. Plusieurs règles de base peuvent être mises en place sans trop de connaissance en expressions régulières mais la science des URL Rewriting prend toute son ampleur lorsqu'on y ajoute un peu de "pattern matching"!

Le texte ci-dessous représente principalement une traduction des passages les plus intéressants des 2 sources citées à la fin de l'article.

Contenu de base du fichier .htaccess

Un fichier .htaccess de réécriture d'adresse de base devrait contenir ces lignes. La ligne Options +FollowSymlinks n'est que très rarement utile car elle permet de suivre les liens symboliques à l'intérieur des bornes définies par le de votre serveur Apache. En contrepartie, chez certains hébergeurs, la présence de cette ligne donnera une erreur interne de serveur (500). La solution la plus simple est de laisser la ligne si le serveur ne retourne pas d'erreur, s'assurant que d'éventuels besoins seront comblés automatiquement ou de commenter la ligne si le serveur retourne une erreur. Pour faire un commentaire dans un fichier .htaccess, ajoutez simplement un # en début de ligne.

Options +FollowSymLinks
 
RewriteEngine On
RewriteBase /

Dans le cas où votre projet est dans un sous-répertoire, il faut ajuster le RewriteBase en conséquence pour que les règles commencent à l'intérieur de ce répertoire.

Flags

Mais qu'est-ce que c'est ces lettres entre crochets []? C'est des "flags" indiquant certaines instructions supplémentaires au moteur de réécriture d'adresse d'Apache. En voici une liste des principaux "flags" :

    
• R=code : Indique une redirection. Le code est le code HTTP que vous désirez retourner. Souvent le code 301 est utilisé pour indiquer que l'adresse demandée n'existe plus et a été remplacée par la nouvelle adresse. Si aucun code n'est spécifié, le code 302 sera retourné, celui-ci indiquant qu'il s'agit d'une redirection temporaire.
    
• L : Indique que si cette règle est respectée, ne pas tenter d'autres règles, arrêter immédiatement avec celle-ci. Très utile pour permettre de mettre les règles les plus précises en début de fichier allant vers les moins précises et arrêter le traitement aussitôt qu'une règle correspond à l'adresse demandée.
    
• NC : Fait en sorte que la règle ne doive pas nécessairement respecter la case (majuscule, minuscule)
            
• QSA : Permet de conserver les paramètres d'une adresse et d'en ajouter d'autres. Par exemple, avec la règle suivante RewriteRule fr/nouvelles.html$ nouvelle.php?lang=fr , si l'URL demandé est fr/nouvelles.html?page=2 , nouvelle.php n'aura pas accès à la valeur du paramètre page, seulement la valeur de lang. Si au contraire on ajoute [QSA], les paramètres lang et page seront disponibles dans le fichier PHP.
    
• S=num : Permet de sauter les "num" prochaines règles si la règle en cours est respectée. Permet de faire une sorte de IF ELSE bouetteux... la dernière règle du premier S étant S=X, X étant le nombre de régles à sauter dans la portion "else".
      (if)
      RewriteRule ... [S=2]
         RewriteRule ...
         RewriteRule ... [S=1]
      (else)
         RewriteRule ...
      (endif)
      Lecture normale des règles suivantes...    
    
• NE : Permet d'éviter d'escaper des caractères spéciaux lors d'une redirection ce qui arrive automatiquement sinon. Ainsi, RewriteRule /test/(.*) /page?q=repertoire\%3d$1 [R,NE] redirigera '/test/bobo' sur l'URL suivante '/page?q=repertoire=bobo'.
    
• N : Permet de relancer le traitement des règles de réécriture, mais pas avec l'URL de départ mais plutôt avec l'URL transformé par les premiers passages... À éviter, risque de boucles infinies.
    
• F : Permet de forcer le retour d'une erreur HTTP 403 : Forbidden sur une page ou un ensemble de page respectant une RewriteConds
    
• B : Apache traduit les caractères "url escapés" en caractère standard. La règle RewriteRule ^(.*)$ index.php?show=$1 réécrira /C++ vers index.php?show=/C++ mais va également réécrire /C%2b%2b vers index.php?show=/C++ car les + auront été "dé-escapés"! L'utilisation du flags B vous assurera que /C%2b%2b deviendra index.php?show=/C%2b%2b et /C++ restera index.php?show=/C++.
    
• C : Permet de lier une règle avec la règle suivante et ainsi de suite si le C est présent sur les règles suivantes. Si la règle est respectée, le traitement continue de façon normal et le flag est ignoré. Si la règle n'est pas respectée, toutes les règles liées à celle-ci ne seront pas considérées.
    
• CO=NAME:VAL:DOMAIN[:LIFETIME[:PATH[:SECURE[:HTTPONLY]]]]' : Permet de créer un cookie! Il s'agit d'une fonctionnalité intéressante mais rarement utilisée... Le prochain développeur à travailler sur votre projet risque de chercher l'emplacement de la création du cookie longtemps dans le code! NAME est le nom du cookie, VAL sa valeur, DOMAIN le domaine ".test.com" sur lequel le cookie doit être actif, LIFETIME la durée de vie en minute, PATH le répertoire où le cookie est effectif, SECURE "true" ou "1" fait en sorte que le cookie est effectif seulement sous https, HTTPONLY "true" ou "1" fait en sorte que le cookie n'est pas manipulable par du javascript.
    
• NON COUVERT ICI : DPI, E=VAR:VAL, G, H=Content Handler, NS, P, PT, T

Forcer la présence des www

Bien que les www. ne sont pas du tout nécessaires pour qu'une page Web fonctionne, les internautes néophytes sont tout de même habitués à leur présence. Le plus important à retenir est que www. agit de façon similaire à un sous-domaine (site.domain.com). D'avoir du contenu accessible avec et sans les www. peut causer un problème de dupplication de contenu ce qui n'est pas idéal pour les moteurs de recherche. Une façon d'éviter est de regarder combien de pages sont présentes dans les index des moteurs de recherche avec et sans les www. (site:domain.com). S'il y a plus de pages avec www., forcez la présence du www., sinon, retirez les www. . Dans les 2 cas, faisant des redirections retournant le code HTTP 301 (déplacement permanent), les adresses fautives seront éventuellement remplacées dans les index des moteurs de recherche.

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^www\.domain.com$ [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

Retirer les www

Il est parfois préférable de se départir des www pour rendre les adresses plus courtes. En tant que tel, les www. n'ajoute aucune valeur. Si un site n'est pas déjà bien référencé dans les moteurs de recherche, il peut être intéressant de forcer le retrait des www.

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^domain\.com$ [NC]
RewriteRule ^(.*)$ http://domain.com/$1 [R=301,L]

Forcer la présence du www sans "hardcoder" le domaine

Il peut parfois arriver que plusieurs domaines soient effectifs sur un même compte d'hébergement, bien que c'est en gérale une mauvaise pratique que le même contenu puisse être accessible à partir de différents noms de domaine. Dans un tel cas, plutôt que d'inscrire le nom de domaine dans la règle forçant la présence du www., une règle générale peut être mise en place :

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^www\.[a-z-0-9]+\.[a-z]{2,6} [NC]
RewriteCond %{HTTP_HOST} ([a-z-]+\.[a-z0-9]{2,6})$     [NC]
RewriteRule ^/(.*)$ http://%1/$1 [R=301,L]

Arrêter des loops de redirections

Bien que non recommandé, il peut arriver que nos règles créées des boucles infinies de redirections sur le serveur. Partant du principe que chaque appel HTTP fait une requête au fichier .htaccess, vous pouvez altérer ce fichier avec le code suivant pour arrêter la boucle.

RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [L]

Déjouer la cache des navigateurs

Trop souvent on doit dire "Avez vous vidé votre cache?"... Une façon de régler ce problème est d'utiliser une règle de réécriture d'adresse permettant de conserver toujours le même nom de fichier pour les feuilles de styles et les fichiers javascript sur le disque mais d'ajouter un numéro de version dans le nom de fichier dans le HTML. Ainsi /skin/js/script-VERSION.js pointe vers /skin/js/script.js et /skin/css/styles-VERSION.css vers /skin/css/styles.css

RewriteRule ^skin/(js|css)/([a-z]+)-([0-9]+)\.(js|css)$ /skin/$1/$2.$4 [L]

Retirer le Query_String

Il est très fréquent de voir des sites pour lesquels page.html et page.html?param=bobo affiche le même contenu... Ceci peut causer des problèmes de contenu duppliquer et nuire au référencement de votre site Web. Une façon de régler le problème est de se départir du QUERY_STRING et il suffit simplement d'ajouter un ? à la fin de votre règle.

RewriteRule bobo.html$ bobo.php? [R=301,L]

Documents sauvegardés en base de données

Vous pouvez simuler la présence d'un document PDF ou Word ou autres dans un répertoire donné et utiliser cette règle pour appeler un script en charge de servir le document en provenance de la base de données /getdoc.php

RewriteRule ^docs/(.+)$  /getdoc.php?file=$1.pdf [L,NC,QSA]

Afficher par défaut dans la langue du visiteur (navigateur)

Il arrive très souvent qu'on doive afficher le contenu d'un site multilangue dans la langue du navigateur du visiteur par défaut. Une façon d'y parvenir est d'utiliser le "flag" ENV permettant d'assigner une variable d'environnement.

RewriteCond %{HTTP:Accept-Language} ^.*(es|fr|en).*$ [NC]
RewriteRule ^(.*)$ - [env=prefer-language:%1]

On est fermé! Permettre de bloquer l'accès à un fichier à une période donnée de la journée.

Concept à utiliser que si nécessaire... Rendre indisponible du contenu de votre site à une certaine heure pourrait faire en sorte que ce contenu soit retiré des index des moteurs de recherche si ceux ci visitent votre site à cette heure.

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
# S'il est 17h, on ferme
RewriteCond %{TIME_HOUR} ^17$
RewriteRule ^.*$ - [F,L]

Changer les underscore (_) par des tirets (-)

Pour des raisons SEO, les tirets sont plus efficaces que les underscores car ils permettent de séparer une chaîne de caractères en plusieurs mots, plutôt que d'être considéré comme un seul mot. Pour cette raison, l'utilisation de underscrore dans les URL est généralement à éviter. La régle suivante fonctionne pour des URL présentant jusqu'à 5 underscores...

Options +FollowSymLinks
RewriteEngine On
RewriteBase /
 
RewriteRule !\.(html|php)$ - [S=4] # on skip les 4 règles suivantes si ce n'est pas un appel à du HTML ou PHP
RewriteRule ^([^_]*)_([^_]*)_([^_]*)_([^_]*)_(.*)$ $1-$2-$3-$4-$5 [E=uscor:Yes]
RewriteRule ^([^_]*)_([^_]*)_([^_]*)_(.*)$ $1-$2-$3-$4 [E=uscor:Yes]
RewriteRule ^([^_]*)_([^_]*)_(.*)$ $1-$2-$3 [E=uscor:Yes]
RewriteRule ^([^_]*)_(.*)$ $1-$2 [E=uscor:Yes]
 
RewriteCond %{ENV:uscor} ^Yes$
RewriteRule (.*) http://domain.com/$1 [R=301,L]

Réduire le vol de bande passante

Il n'est pas rare de voir des sites faire référence directement à une image, une animation flash ou autre mais de façon intégrée à leur contenu. Le résultat est que vous fournissez la bande passante pour le média transmis.

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.com/.*$ [NC]
RewriteRule \.(gif|jpg|swf|flv|png)$ /dev/null [R=302,L]

Redirection pour une adresse IP précise

Il arrive souvent qu'on doive ajouter une règle dans un fichier .htaccess et il peut être tentant de la faire directement sur le serveur... Bien entendu, dans certains cas, une erreur de manipulation peut causer des problèmes! C'est pourquoi il peut être intéressant de tester une règle en spécifiant notre adresse IP dans une condition préalable... Ainsi, seulement les requêtes en provenance de cette adresse IP seront considérées.

RewriteCond %{REMOTE_ADDR} ^1\.1\.1\.1$
RewriteRule ^$ http://www.domain.com/testderedirectionjustepourmoi.html? [L]

Contrôle du comportement du HTTPS

Je trouve pratique qu'une section sécurisée d'un site ne soit pas simplement sur https://www.lesite.com... Par exemple, dans le cas de paiement en ligne pour une boutique, l'utilisation d'un sous-domaine secure.lesite.com, lui étant disponible seulement sous HTTPS me paraît un scénario beaucoup plus sympathique... Les règles suivantes permettent d'avoir un contrôle sur une zone bien précise pour le HTTPS et s'assurent que cette zone n'est disponible qu'avec HTTPS

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} secure.lesite.com(.*)$
RewriteRule ^(.*)$ https://secure.lesite.com/$1 [R=301,L]

RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} !^secure.lesite.com
RewriteRule ^(.*)$ https://secure.lesite.com/$1 [R=301,L]

Page 404

Le fichier .htaccess peut également servir à définir une page d'erreur 404 par défaut.

ErrorDocument 404 404.html

Sources

    
• Mod_rewrite Rewriteflags
    
• Mod_rewrite Tips and tricks

C'est toujours un plaisir quand nos clients sont satisfaits et le disent. Le Cégep de Saint-Laurent a récemment mis en ligne le système de gestion d'inscriptions que nous avons développé et voici ce qu'en dit sur son blogue Marc-Olivier Ouellet, le maître d'oeuvre du projet au Cégep:

"Le module d’inscription de Quiboweb fonctionne tel que promis.  Il offre des fonctionnalités uniques au cégep de Saint-Laurent, à faire envier les autres cégeps.  Le module permet de gérer quasiment de A à Z le processus d’inscription pour les ateliers de perfectionnement et les formations aux municipalités (ATPA), y compris le traitement pour les tarifs réduits admissibles pour Emploi-Québec, le paiement en ligne, la génération de PDFs spéciaux, le publipostage, etc.  Donc un gros merci à l’équipe de Quiboweb [...]"

Je n'ai pas pu m'empêcher de bloguer sur ce sujet qui me tient tant à coeur. La validation, c'est très important! Voici quelques exemples qui, à mon avis, sont efficaces et vraiment bien faits.

https://secure.livestream.com/myaccount/login
Il y a un indicateur (assez évident merci) qui valide au fur et à mesure. Notez que le bouton submit est innactif tant et aussi longtemps que les champs ne sont pas remplis correctement. Winner!

http://www.bigcartel.com/signup/diamond
Les erreurs sont affichées en rose en haut. Les labels erronés deviennent rose. L'essentiel quoi.

http://gowalla.com/users/new
Look original! Les champs erronés et valides sont différenciés de façon clair.

http://www.launchmind.com/signup/
Intéressant. Étant donné que le formulaire est long, le message d'erreur s'affiche en bas, en-dessous du bouton « create account ». J'aime l'idée.

http://www.popscreen.com/join
On peut facilement différencier le champs valide et celui qui ne l'est pas. De plus, on a une petite note qui donne de l'information supplémentaire sur le champs actif. Bien pensé.

http://thumbslap.com/signup/
Classique, mais assez évident.

https://wwws.mint.com/login.event?task=S
J'aime le fait que la validation se fait au fur et à mesure. Il est facile de savoir ce qui est bon de ce qui ne l'est pas. Thumbs up!

https://www.squarespace.com/process/CreateSquarespaceAccount
Un formulaire horizontal... c'est la première fois que j'en vois un. Pas mauvais comme validation.

https://secure.wufoo.com/signup/1/
Classique, mais original en même temps. Vive l'évidence!

Une newsletter est destinée à plusieurs boites de messagerie différentes (hotmail, yahoo, gmail, outlook, thunderbird...) et chacune réagit différemment. La simplicité et l'accessibilité est de mise! Voici quelques règles à suivre pour maximiser la compatibilité:

- Ne pas excéder 600 pixels de large

- Ne pas dépasser 30 Ko

- Insérer le code à l'intérieur de la balise BODY (oublier le reste)

- Intégrer complètement en tableaux (aucun div!)

- Déclarer le CSS à l'interieur du code (CSS inline)

- Lier toutes les images (et autres médias) en liens absolus

- Utiliser les entités HTML

- Valider le code (Validator du W3C)

- Supprimer les espaces inutiles et les commentaires

Conseils éclairs

Il semble y avoir des problèmes de compatibilité avec la couleur de background déclaré dans le HTML, BODY ou un DIV. Je vous recommande donc de créer un tableau 100% avec un BGCOLOR.

Il semble aussi avoir des troubles avec les BORDER dans hotmail. Vous pouvez toujours créer des bordures artificielles à l'aide de TR et TD en spécifiant une couleur de fond et un width ou un height.

Privilégiez les IMG au lieu des BACKGROUND-IMAGE. Vous constaterez que hotmail et outlook sont capricieux sur ce point.

Quelques liens très utiles sur le sujet :
http://www.email-standards.org/
http://www.campaignmonitor.com/css/
http://www.xavierfrenette.com/articles/css-support-in-webmail/

Il y a 20 ans, fumer était « in » et bien vue. Maintenant, tout le monde sait que fumer n'est pas bon. Autrefois, avoir une splash page (ou page tunnel, page d'entrée, page d'introduction) était à la mode. Maintenant, il est prouvé que ce genre de pratique n'est pas recommandé (sauf pour certains cas précis). Pourquoi faire cette analogie? Parce qu'il existe encore des gens qui veulent des splash pages pour les mauvaises raisons.

Une splash page peut être utile. En voici quelques exemple :

1- Afficher une mise en garde

2- Afficher un message important ou une nouveauté

3- Choisir une langue et/ou un pays

4- Choisir une version et/ou une préférence

5- Présenter une image très artistique

6- Afficher un mode d'emploi

En dehors de ces exemples, une splash page peut s'avérer dommageable.

La splash page n'a pas très bonne réputation parce qu'elle...

... offre habituellement très peu de contenu textuel et un accès limité aux autres pages du site. Par conséquent, elle diminue considérablement le référencement.

... retarde d'une page l'accès à l'information. Elle oblige à cliquer pour accéder à la page d'accueil (la page la plus importante). Il y a donc un clic de trop. Let’s get to the point!

... peut être longue à télécharger et du même coup, faire fuir le visiteur.

... nuit à la liberté de l'usager. Il doit obligatoirement passer par cette page.

... n'est pas toujours appréciée des visiteurs. La visite débute donc avec une note négative.

... présente souvent une animation flash que les visiteurs s'empressent de skipper!

En conclusion, une splash page devrait être évitée à moins d'avoir une bonne raison.