Il y a peu de temps, j'ai été confrontée à un problème sur AdSense :
je devais valider mon numéro de téléphone pour débloquer mes gains, mais
mon numéro de vérification n'était pas le bon.
Quand j'allais
dans mon compte, le numéro de téléphone indiqué dans la section
"Informations personnelles" était le bon, mais une fois sur la page de
validation du numéro, c'était mon ancien numéro.
J'ai essayé de le
changer en effaçant le numéro et en le remettant, rien n'y faisait,
c'était toujours l'ancien numéro dans le processus de validation.
Puis
par hasard en cliquant sur "Modifier" dans la section "Adresse", je me
suis rendue compte qu'il y avait un autre numéro de téléphone ici, qui
correspondait à mon ancien numéro. Après avoir changé celui-ci j'ai
enfin pu valider mon numéro de téléphone.
Ca peut
paraître bête, mais le support AdSense n'a jamais pu me renseigner, et
les gens concernés sur les forums n'ont jamais pu apporter de solution.
Tout ça pour un champ bien caché !
lundi 3 juin 2013
Mise en place de Varnish avec Symfony2
Libellés :
Optimisation,
Symfony2
Après une mise en place un peu laborieuse, voici un petit
récapitulatif de ce que j'ai fait pour faire fonctionner Varnish avec
Symfony 2.
La configuration utilisée : Ubuntu 11.10, Varnish 3.0.0-4, Symfony 2.0
Ouvrir le terminal et taper :
Ouvrir et modifier le fichier de configuration de Varnish, par exemple :
Surcharger les méthodes vcl_recv (réception des données), vcl_hash (construction de la clé unique qui correspondra à une entrée de cache donnée) et vcl_fetch :
hash_data(regsub( req.http.Cookie, "^.*?locale=([^;]*);*.*$", "\1" ));
}
permet de gérer un cache par langue, dans le cas où la langue n'est pas spécifiée dans l'URL. Par défaut, Varnish prend pour hash l'URL de la page, donc si votre langue est en session, vous obtiendrez le même contenu pour toutes vos langues. Mettre la locale en cookie, puis ici ajouter sa valeur au hash règle ce problème.
Nous verrons plus bas comment mettre votre locale en cookie.
Après avoir modifié ce fichier, redémarrez Varnish :
Pour cacher un bloc, il faut que celui-ci soit rendu par une action :
La locale sert à gérer le cache par langue, du fait que ce paramètre se retrouve dans l’url interne et donc dans le hash utilisé par Varnish. Si la langue n’est pas encore dans le cookie, le le hash ne contiendra pas la locale ni fr, ni en, mais sera vide. Il est donc mieux de faire :
L’option 'standalone': true va faire que ce bloc deviendra un tag ESI.
Le tag ESI ressemblera à :
Dans l’action qui rend le bloc :
-> Même fonctionnement pour les pages complètes.
Pour ne pas mettre en cache les blocs utilisant par exemple la session, mettre les headers adéquats dans la réponse :
Comme on l'a vu plus haut, si votre locale est dans votre session et non dans l'URL, il faut créer un cookie contenant la locale, au moment où vous changez votre locale ; dans une action changeLocaleAction par exemple.
Lorsque vous vous apprêtez à retourner l'objet Response :
Créer un fichier de test qui fait un CURL sur une URL passée en paramètre GET avec le header “Surrogate-Capability:abc=ESI/1.0”
-> celà permet de voir les balises ESI dans le code source (par exemple en inspectant avec Firebug).
Par exemple web/testvarnish.php
Enfin, vous pouvez tester les performances avec un outil tel que JMeter.
La configuration utilisée : Ubuntu 11.10, Varnish 3.0.0-4, Symfony 2.0
Installation
Ouvrir le terminal et taper :
sudo apt-get install varnish
Configuration de Varnish
Ouvrir et modifier le fichier de configuration de Varnish, par exemple :
sudo vi /etc/varnish/default.vcl
Surcharger les méthodes vcl_recv (réception des données), vcl_hash (construction de la clé unique qui correspondra à une entrée de cache donnée) et vcl_fetch :
sub vcl_recv {
set req.http.Surrogate-Capability = "abc=ESI/1.0";
if (req.restarts == 0) {
if (req.http.x-forwarded-for) {
set req.http.X-Forwarded-For =
req.http.X-Forwarded-For + ", " + client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}
}
if (req.request != "GET" &&
req.request != "HEAD" &&
req.request != "PUT" &&
req.request != "POST" &&
req.request != "TRACE" &&
req.request != "OPTIONS" &&
req.request != "DELETE") {
/* Non-RFC2616 or CONNECT which is weird. */
return (pipe);
}
if (req.request != "GET" && req.request != "HEAD") {
/* We only deal with GET and HEAD by default */
return (pass);
}
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
#return (pass);
}
return (lookup);
}
set req.http.Surrogate-Capability = "abc=ESI/1.0";
permet de dire à Varnish de prendre en charge le langage ESI, qui est
un langage de balisage qui s'insère dans le code HTML, et déclenche des
traitement de construction de la page.set req.http.Surrogate-Capability = "abc=ESI/1.0";
if (req.restarts == 0) {
if (req.http.x-forwarded-for) {
set req.http.X-Forwarded-For =
req.http.X-Forwarded-For + ", " + client.ip;
} else {
set req.http.X-Forwarded-For = client.ip;
}
}
if (req.request != "GET" &&
req.request != "HEAD" &&
req.request != "PUT" &&
req.request != "POST" &&
req.request != "TRACE" &&
req.request != "OPTIONS" &&
req.request != "DELETE") {
/* Non-RFC2616 or CONNECT which is weird. */
return (pipe);
}
if (req.request != "GET" && req.request != "HEAD") {
/* We only deal with GET and HEAD by default */
return (pass);
}
if (req.http.Authorization || req.http.Cookie) {
/* Not cacheable by default */
#return (pass);
}
return (lookup);
}
sub vcl_hash {
### these 2 entries are the default ones used for vcl. Below we add our own.
hash_data(req.url);
hash_data(req.http.host);
if( req.http.Cookie ~ "locale" ) {
hash_data(regsub( req.http.Cookie, "^.*?locale=([^;]*);*.*$", "\1" ));
}
return (hash);
}
if( req.http.Cookie ~ "locale" ) {### these 2 entries are the default ones used for vcl. Below we add our own.
hash_data(req.url);
hash_data(req.http.host);
if( req.http.Cookie ~ "locale" ) {
hash_data(regsub( req.http.Cookie, "^.*?locale=([^;]*);*.*$", "\1" ));
}
return (hash);
}
hash_data(regsub( req.http.Cookie, "^.*?locale=([^;]*);*.*$", "\1" ));
}
permet de gérer un cache par langue, dans le cas où la langue n'est pas spécifiée dans l'URL. Par défaut, Varnish prend pour hash l'URL de la page, donc si votre langue est en session, vous obtiendrez le même contenu pour toutes vos langues. Mettre la locale en cookie, puis ici ajouter sa valeur au hash règle ce problème.
Nous verrons plus bas comment mettre votre locale en cookie.
sub vcl_fetch {
if (beresp.http.surrogate-control ~ "ESI/1.0") {
unset beresp.http.surrogate-control;
set beresp.do_esi = true;
}
if (beresp.ttl <= 0s ||
beresp.http.Set-Cookie ||
beresp.http.Vary == "*") {
/*
* Mark as "Hit-For-Pass" for the next 2 minutes
*/
set beresp.ttl = 120 s;
return (hit_for_pass);
}
return (deliver);
}
if (beresp.http.surrogate-control ~ "ESI/1.0") {
unset beresp.http.surrogate-control;
set beresp.do_esi = true;
}
if (beresp.ttl <= 0s ||
beresp.http.Set-Cookie ||
beresp.http.Vary == "*") {
/*
* Mark as "Hit-For-Pass" for the next 2 minutes
*/
set beresp.ttl = 120 s;
return (hit_for_pass);
}
return (deliver);
}
Après avoir modifié ce fichier, redémarrez Varnish :
sudo service varnish restart
Configuration de Symfony2
app/config/config.yml
framework:
templating: { engines: ['twig'] }
session:
default_locale: fr
auto_start: false # Pour ne pas générer le PHPSESSID à chaque page (cache multi user)
esi: true # Pour utiliser les tags ESI dans les templates Twig
templating: { engines: ['twig'] }
session:
default_locale: fr
auto_start: false # Pour ne pas générer le PHPSESSID à chaque page (cache multi user)
esi: true # Pour utiliser les tags ESI dans les templates Twig
app/config/routing.yml
_internal:
resource: "@FrameworkBundle/Resources/config/routing/internal.xml"
prefix: /_internal
-> pour la prise en charge des routes internes de Symfony2 dans les tags ESIresource: "@FrameworkBundle/Resources/config/routing/internal.xml"
prefix: /_internal
web/app.php
//$kernel = new AppCache($kernel);
-> On commente cette ligne pour passer par Varnish et
non plus par le système de cache de Symfony2. (voir s’il y a une
possibilité de gérer ça autrement car ce n'est pas très propre !)Mise en place des blocs et pages cachées dans Symfony2
Pour cacher un bloc, il faut que celui-ci soit rendu par une action :
{% render "NomDeBundle:Test:monAction" with {'locale': app.session.locale}, {'standalone': true} %}
La locale sert à gérer le cache par langue, du fait que ce paramètre se retrouve dans l’url interne et donc dans le hash utilisé par Varnish. Si la langue n’est pas encore dans le cookie, le le hash ne contiendra pas la locale ni fr, ni en, mais sera vide. Il est donc mieux de faire :
{% if app.session.locale %}
{% render "NomDeBundle:Test:monAction" with {'locale': app.session.locale}, {'standalone': true} %}
{% else %}
{% render "NomDeBundle:Test:monAction" with {'locale': app.session.defaultLocale}, {'standalone': true} %}
{% endif %}
{% render "NomDeBundle:Test:monAction" with {'locale': app.session.locale}, {'standalone': true} %}
{% else %}
{% render "NomDeBundle:Test:monAction" with {'locale': app.session.defaultLocale}, {'standalone': true} %}
{% endif %}
L’option 'standalone': true va faire que ce bloc deviendra un tag ESI.
Le tag ESI ressemblera à :
<esi:include src="http://example.com/1.html" onerror="continue"/>
Dans l’action qui rend le bloc :
/**
* Renders the user cart block on the top right of the page
* ESI block
*
* @Extra\Template("NomDeBundle:Test:esi_header_top.html.twig")
*/
public function cartBlockAction() {
$response = new Response();
$response->setContent($this->renderView('NomDeBundle:Test:esi_header_top.html.twig', array()));
$response->setSharedMaxAge(600); # en secondes, donc environ 10 minutes
$response->setPublic();
return $response;
}
-> On ajoute les bons headers à la réponse, où setSharedMaxAge est le temps en secondes de la durée de vie du cache.* Renders the user cart block on the top right of the page
* ESI block
*
* @Extra\Template("NomDeBundle:Test:esi_header_top.html.twig")
*/
public function cartBlockAction() {
$response = new Response();
$response->setContent($this->renderView('NomDeBundle:Test:esi_header_top.html.twig', array()));
$response->setSharedMaxAge(600); # en secondes, donc environ 10 minutes
$response->setPublic();
return $response;
}
-> Même fonctionnement pour les pages complètes.
Pour ne pas mettre en cache les blocs utilisant par exemple la session, mettre les headers adéquats dans la réponse :
$response->setMaxAge(0);
$response->setPrivate();
$response->setPrivate();
Cookie de langue
Comme on l'a vu plus haut, si votre locale est dans votre session et non dans l'URL, il faut créer un cookie contenant la locale, au moment où vous changez votre locale ; dans une action changeLocaleAction par exemple.
Lorsque vous vous apprêtez à retourner l'objet Response :
$response->headers->setCookie(
new Cookie(
'locale',
$votreLocale,
time() + 600));
new Cookie(
'locale',
$votreLocale,
time() + 600));
Pour faire vos tests
Créer un fichier de test qui fait un CURL sur une URL passée en paramètre GET avec le header “Surrogate-Capability:abc=ESI/1.0”
-> celà permet de voir les balises ESI dans le code source (par exemple en inspectant avec Firebug).
Par exemple web/testvarnish.php
<?php
$url = $_GET["url"];
$ret = curl_init($url);
curl_setopt($ret, CURLOPT_HTTPHEADER, array(
'Surrogate-Capability:abc=ESI/1.0'
));
echo curl_exec($ret);
?>
$url = $_GET["url"];
$ret = curl_init($url);
curl_setopt($ret, CURLOPT_HTTPHEADER, array(
'Surrogate-Capability:abc=ESI/1.0'
));
echo curl_exec($ret);
?>
Enfin, vous pouvez tester les performances avec un outil tel que JMeter.
lundi 22 octobre 2012
Réduire le temps de chargement d'un site web
Libellés :
Optimisation
Aujourd'hui avec internet nous avons l'habitude d'obtenir l'information recherchée immédiatement.
A une époque où l'on ne veut pas attentdre voici plusieurs pistes à explorer pour réduire le temps de chargement d'un site web, le but de cet article n'étant pas de rentrer dans les détails de chaque technique, mais de proposer des débuts de solution à méditer.
A une époque où l'on ne veut pas attentdre voici plusieurs pistes à explorer pour réduire le temps de chargement d'un site web, le but de cet article n'étant pas de rentrer dans les détails de chaque technique, mais de proposer des débuts de solution à méditer.
- Réduire le nombre de requêtes HTTP
- Réduire la taille des données téléchargées
- Optimiser son code
Réduire le nombre de requêtes HTTP
Supprimer les scripts et CSS chargés en doublon
Pour vérifier que vos JS et CSS sont bien chargés une seule fois, vous pouvez regarder les ressources chargées dans l'onglet "Réseau" de Firebug.Utiliser la technique des CSS sprites pour les images
Il s'agit de regrouper un certain nombres de petites images les unes à côté des autres sur un même fichier. Par exemple vous utilisez plein de petites icones sur votre site et les chargez une par une : ce sont autant de requêtes HTTP que d'icones. En les regroupant sur un même fichier vous reduisez le chargement à une seule requête. Le découpage de chaque picto se fera ensuite en CSS.Associer les scripts
Cette technique est à prendre avec des pincettes. Celà peut être bénéfique de regrouper plusieurs fichiers javascripts pour n'avoir plus qu'une seule requête HTTP ; cependant attention à la taille finale du script qui peut mettre énormément de temps à se charger également.Charger les JS en fin de page
Celà peut permettre d'afficher plus rapidement la page, mais cette technique ne fonctionne que si les scripts concernés n'ont pas besoin d'être chargés plus tôt.Utiliser le cache navigateur
Utiliser les en-têtes HTTP à bon escient peut éviter de redemander des ressources inutilement.Utiliser un système de cache (par exemple Varnish)
Varnish vient se placer entre le client est le serveur. Si le client demande une ressource qui est déjà dans le cache, Varnish la renvoie sans faire appel au serveur. De nombreuses requêtes sont ainsi évitées. Vous pouvez bien entendu recharger certaines parties de code à la demande, grâce au langage ESI.Réduire la taille des données téléchargées
(peut être en contradiction avec les préconisations précédentes, tout celà est à adapter en fonction des cas spécifiques)Gzipper les fichiers
JS, CSS, HTML ou encore les fichiers XML/Texte seront compressés par le serveur avant envoi.Réduire le poids des images quand celà est possible
Réduire le nombre de couleurs dans photoshop, tout en “dosant”
Utiliser un logiciel d’optimisation d’image, par exemple Caesium pour Windows
Minifier les fichiers JS et CSS
En supprimant les caractères non nécessaires ainsi que les commentaires et les espaces, la taille des fichiers est ainsi réduite et le temps de réponse est amélioré.Optimiser son code
Encore une fois, vous trouverez dans cette partie quelques exemples de choses à faire pour optimiser votre code. Ces bonnes pratiques sont à avoir au moment du développement de votre projet, et sont de bonnes habitudes à prendre pour la suite.- PHP : utiliser des simples quotes à la place des doubles quotes
- PHP : $array[‘key’] est 7 fois plus rapide que $array[key]
- PHP : éviter les fonction dans les boucles : for($i=0;$i=count($array);$i++) la perte de temps est multipliée par le nombre d’itération
- PHP : utiliser des chemins absolus évite le calcule du chemin d’un fichier
- PHP : certaines fonctions sont plus rapides que d’autres : préférer str_replace à preg_replace, explode à preg_split, etc...
- SQL : réduire le nombre de requêtes
- SQL : bien structurer sa base de données : mettre les types adéquats, la bonne longueur de champ...
- SQL : mettre en place des index pour accélérer la recherche de l'information en privilégiant les accès au fichier d'index
et ainsi de suite...
dimanche 14 octobre 2012
Les qualités d'un bon développeur
Libellés :
Business,
Développeur
Un bon développeur n'est pas seulement un développeur qui maîtrise ses technologies, sa façon de réflechir et son approche du travail sont tout autant importantes.
Une des qualités recherchées chez un développeur est le fait d'apprendre vite. Quelqu'un qui appréhende bien les problématiques, quelqu'un qui s'adapte facilement partira déjà avec un avantage. Néanmoins, cela peut être comblé par un travail supplémentaire qui permettra de développer cet aspect de la personnalité.
On dit toujours qu'un bon développeur est un feignant. A mon sens, c'est vrai et faux à la fois. Vrai car notre feignantise nous pousse toujours à développer pour nous faciliter la vie en automatisant certaines tâches répétitive par exemple. Et faux car pour devenir un bon développeur, il faut apprendre constamment, et pratiquer. Vous contenter de faire vos 35 heures et rentrer chez vous ne vous empêchera pas dêtre un bon technicien, mais ceux qui poussent plus loin la connaissance, la curiosité, se rapprocheront d'avantage que vous de l'excellence.
N'attendez pas que votre patron vous offre des formations, prenez votre carrière en main et devenez meilleur. Soyez curieux, c'est à mon sens une des qualités les plus importantes dans ce métier. tenez vous au courant des dernières techno, et mettez les en oeuvre. Ce n'est qu'en pratiquant qu'on saisi parfaitement les différentes problématiques que l'on peut rencontrer.
Une autre des qualités les plus importantes et la rigueur, et l'organisation. Ne soyez pas brouillon. Faîtes en sorte que votre travail soit homogène, adoptez des normes logiques et constantes, commentez votre code, faîtes des tests. Si vous ne savez pas si vous êtes rigoureux, penchez vous sur le code de quelqu'un d'autre, si vous vous sentez contrarié, c'est que vous êtes rigoureux !
Etre excellent techniquement et maîtriser ses technos ne suffit pas. Il faut savoir prendre un certain recul par rapport à ce que l'on fait ou ce que l'on va faire. Est-ce que ça répond au besoin ? est-ce que c'est logique ? est-ce que c'est réutilisable ? Cet aspect vient généralement avec l'expérience.
Pour conclure je dirais qu'être ou devenir un bon développeur est avant tout une question de caractère. Ce caractère peut être développé avec l'expérience, bien sûr on ne peut pas être parfait immédiatement. Prenez le temps d'élargir vos connaissances et développer celle que vous avez déjà. Mettez vous en place des protocoles de travail et essayez de les mettre en oeuvre.
dimanche 7 octobre 2012
Les emplacements essentiels des mots-clés sur votre site web
Libellés :
SEO
Pour avoir du traffic sur votre site web, il faut que vos pages soient optimisées pour les mots-clés. Il est donc important de savoir où placer ces mots-clés.
Si un moteur de recherche tel que Google fourni des résultats si efficaces, c'est parce qu'il est capable de déterminer en fonction des termes recherchés quels résultats sont les plus appopriés. C'est là que vous web marketers et web développeurs entrez en jeu.
Terminés, les métas keywords
Les "keywords" dans les métas ne sont plus pris en compte par le moteur de recherche. L'époque où l'on pouvait bourrer sa balise meta keyword de mots-clés pour gagner un avantage est révolue. L'objectif étant de fournir des résultats pertinents, le moteur de recherche ne se laisse plus abuser. D'ailleurs cette pratique n'était pas toujours à votre avantage et pouvait jouer contre vous si elle était mal utilisée.
Voici donc sur quoi vous devriez vous concentrer.
La balise "title"
Cette balise doit contenir le titre du contenu de votre page, le choix du contenu est donc très important, d'autant plus qu'il s'agit du titre qui apparaitra dans les résultats du moteur de recherche.
Cette balise devra contenir environ une douzaine de mots, qui doivent bien illustrer le sujet de votre page. Les termes les plus importants devront se trouver si possible au début du titre et devront donner envie à l'internaute de cliquer dessus dans le moteur de recherche.
Ne mettez pas le même titre sur toutes les pages, et personnalisez le plus possible en fonction de vos différentes pages. Celà permettra d'avoir un maximum de mots-clés, mais également d'éviter les filtres de duplication de contenu.
De jolies URL
Des URL parlantes permettront à l'internaute (mais également au moteur de recherche) d'avoir une idée du contenu qu'il trouvera dans vos pages, et donc d'avoir envie d'y jeter un oeil.
Par exemple :
http://www.monsitedactus.com/les-emplacements-essentiels-des-mots-cles-sur-votre-site-web.html vaut mieux que :
http://www.monsitedactus.com/article.php?id=3
Cette URL peut être le slug du titre de votre page.
La balise "h1"
Sans en abuser, vous pouvez mettre plusieurs balises h1 dans vos pages. Avec l'arrivée du HTML5 et ses nouvelles balises, vous pouvez par exemple maintenant imaginer avoir une balise h1 en en-tête de vos balises section.
La balise h1 étant la plus importante des balises de titre (h1, h2, h3, etc...), elle indique au moteur de recherche que les mots-clés qu'elle contient sont plus importants que les autres termes employés dans le contenu de votre page.
Le contenu de votre page
Le contenu de votre page doit rester pertinent. N'essayez donc pas de placer plus de mots-clés que de raison, ou alors c'est la qualité de votre contenu qui en patira. Si les termes viennent naturellement lors de l'écriture de votre contenu, très bien, mais ne tentez pas le diable en introduisant des couches et des couches de mots-clé.
Les images et leur attribut alt
Il ne faut pas oublier que les images aussi peuvent jouer dans les résultats de recherche, celà vaut donc la peine de passer un peu de temps à optimiser les votres avec les bons mots-clés. Rappelez-vous les jolies URL, celà fonctionne de la même façon. Privilégiez par exemple cathedrale-de-paris.png à img42.png.
Renseignez l'attribut alt avec du texte que vous aimeriez voir s'afficher si votre image n'était pas accessible. Par exemple : alt="Photo de la cathédrale de Paris". "alt" est l'abbréviation de "alternative", c'est le texte qui s'affiche lorsque l'image est "cassée", ou pas encore chargée.
N'oubliez pas que beaucoup d'internautes recherchent des images seules, celà peut valoir le coup si celà peut permettre de vous rapporter quelques visites.
Si un moteur de recherche tel que Google fourni des résultats si efficaces, c'est parce qu'il est capable de déterminer en fonction des termes recherchés quels résultats sont les plus appopriés. C'est là que vous web marketers et web développeurs entrez en jeu.
Terminés, les métas keywords
Les "keywords" dans les métas ne sont plus pris en compte par le moteur de recherche. L'époque où l'on pouvait bourrer sa balise meta keyword de mots-clés pour gagner un avantage est révolue. L'objectif étant de fournir des résultats pertinents, le moteur de recherche ne se laisse plus abuser. D'ailleurs cette pratique n'était pas toujours à votre avantage et pouvait jouer contre vous si elle était mal utilisée.
Voici donc sur quoi vous devriez vous concentrer.
La balise "title"
Cette balise doit contenir le titre du contenu de votre page, le choix du contenu est donc très important, d'autant plus qu'il s'agit du titre qui apparaitra dans les résultats du moteur de recherche.
Cette balise devra contenir environ une douzaine de mots, qui doivent bien illustrer le sujet de votre page. Les termes les plus importants devront se trouver si possible au début du titre et devront donner envie à l'internaute de cliquer dessus dans le moteur de recherche.
Ne mettez pas le même titre sur toutes les pages, et personnalisez le plus possible en fonction de vos différentes pages. Celà permettra d'avoir un maximum de mots-clés, mais également d'éviter les filtres de duplication de contenu.
De jolies URL
Des URL parlantes permettront à l'internaute (mais également au moteur de recherche) d'avoir une idée du contenu qu'il trouvera dans vos pages, et donc d'avoir envie d'y jeter un oeil.
Par exemple :
http://www.monsitedactus.com/les-emplacements-essentiels-des-mots-cles-sur-votre-site-web.html vaut mieux que :
http://www.monsitedactus.com/article.php?id=3
Cette URL peut être le slug du titre de votre page.
La balise "h1"
Sans en abuser, vous pouvez mettre plusieurs balises h1 dans vos pages. Avec l'arrivée du HTML5 et ses nouvelles balises, vous pouvez par exemple maintenant imaginer avoir une balise h1 en en-tête de vos balises section.
La balise h1 étant la plus importante des balises de titre (h1, h2, h3, etc...), elle indique au moteur de recherche que les mots-clés qu'elle contient sont plus importants que les autres termes employés dans le contenu de votre page.
Le contenu de votre page
Le contenu de votre page doit rester pertinent. N'essayez donc pas de placer plus de mots-clés que de raison, ou alors c'est la qualité de votre contenu qui en patira. Si les termes viennent naturellement lors de l'écriture de votre contenu, très bien, mais ne tentez pas le diable en introduisant des couches et des couches de mots-clé.
Les images et leur attribut alt
Il ne faut pas oublier que les images aussi peuvent jouer dans les résultats de recherche, celà vaut donc la peine de passer un peu de temps à optimiser les votres avec les bons mots-clés. Rappelez-vous les jolies URL, celà fonctionne de la même façon. Privilégiez par exemple cathedrale-de-paris.png à img42.png.
Renseignez l'attribut alt avec du texte que vous aimeriez voir s'afficher si votre image n'était pas accessible. Par exemple : alt="Photo de la cathédrale de Paris". "alt" est l'abbréviation de "alternative", c'est le texte qui s'affiche lorsque l'image est "cassée", ou pas encore chargée.
N'oubliez pas que beaucoup d'internautes recherchent des images seules, celà peut valoir le coup si celà peut permettre de vous rapporter quelques visites.
Inscription à :
Articles (Atom)