Some tips about the eZ Publish debug

The eZ Publish debug is probably one of the most useful tool for the eZ developer. It is recommended to always activate it during development as you should read in it only debug or notice messages (and perhaps some translations warnings).

Enable the debug ouput

I usually activate it by putting those lines in the site.ini.append.php of the siteaccess I work on :

[DebugSettings]
DebugOutput=enabled
 
[TemplateSettings]
ShowUsedTemplates=enabled

Those settings activate the debug and display the templates used to render the page which is often a very useful information.

Don't show debug to everybody

It is also possible to restrict the generation of the debug by IP or by user id. This feature can be useful to monitor a live sites or to not annoy your colleagues when developing a site. With the following settings, the debug is only displayed for users visiting the site with the IP 10.2.2.157 :

[DebugSettings]
DebugOutput=enabled
DebugByIP=enabled
DebugIPList[]=10.2.2.157

Comment the line beginning by DebugIPList will make the debug disappear for everybody.

What happen before the redirection ?

DebugRedirection setting lets the developer read debug messages before an HTTP redirect. Instead of being directly redirected, you have to click on a button to view the next page. It can be useful to debug workflow events, content edit handler or extensions with modules and views... It is also possible to specify paths in this setting to enable this feature for only some pages, but this feature is undocumented for the moment.

Place the debug to not break your page

The default behaviour of eZ Publish is to replace the string <!-- DEBUG_REPORT --> by the debug output. If the string is not in the HTML code of the page, the debug will be placed at the end of the page. So depending on the HTML code, it's important to place correctly the string <!-- DEBUG_REPORT --> to not break the page with the debug.

Disable the debug for some special pages

As seen just before, <!-- DEBUG_REPORT --> is replaced by the debug output, so it's easy to comment <!-- DEBUG_REPORT --> another time in the pagelayout so that the debug is commented in some special pages for example in AJAX parts of a page or in exports based on a special layout. More details in Disable debug for custom layouts (/layout/set/xyz) topic in eZ.no forums.

Output something in the debug from a template

debug-log is an undocumented template operator that lets the developer output a variable and/or a message to the debug output. It's just an eZDebug::writeDebug call. It is sometimes easier to read and less obtrusive than using the attribute() operator, I use it in eZ Class Lists 1.0 to display the hash used to filter objects list with something like :

{debug-log msg='template fetch filter' var=$filter_hash}

Livre : "High Performances Web Sites"

Only 10-20% of the end user response time is spent downloading the HTML document. The other 80-90% is spent downloading all the components in the page.

Traduction libre :

Seulement 10 à 20% du temps de réponse ressenti par l'utilisateur provient du téléchargement du document HTML. Les 80 à 90% restant viennent du téléchargement des autres composantes de la page.

Voila la Performance Golden Rule qui sert de base à ce court mais excellent bouquin High Performances Web Sites de Steve Souders (employé chez Yahoo!) expliquant 14 règles pour améliorer la rapidité d'affichage d'un site web. En fait ce livre reprend les 14 premières bonnes pratiques listées par Yahoo! pour améliorer les performances générales d'un site web. Ces points sont applicables à quasiment tous les sites (à part peut être l'utilisation d'un Content Delivery Network qui est hors de porté du commun des mortels...) quelque soit la technologie employée puisqu'il s'agit essentiellement de configuration au niveau du serveur web ou dans la construction des pages.

Ces 14 règles sont les suivantes :

  1. Limitez le nombre de requêtes HTTP
  2. Utilisez un content delivery network
  3. Ajoutez l'entête Expires
  4. Compressez avec gzip
  5. Placez les feuilles de styles en haut de page
  6. Placez les scripts javascript en bas de page
  7. Évitez les expressions CSS
  8. Externalisez les feuilles de styles et les scripts Javascript
  9. Réduisez les résolutions DNS
  10. Réduisez la taille les scripts Javascripts
  11. Évitez les redirections
  12. Supprimez les scripts en double
  13. Configurez l'entête ETags
  14. Rendez vos appels AJAX cachables

En plus de ces règles, le livre explique succintement quelques concepts du protocole HTTP liés aux performances et propose une analyse des 10 plus gros sites américains (MSN, Google, Yahoo!, CNN, Wikipedia, MySpace...). Si ces règles sont assez connues (et pour certaines de l'ordre du bon sens), l'intérêt principal du livre réside dans la quantification des gains éventuels ainsi que dans les explications amenant à ces règles sur le fonctionnement des navigateurs sur la construction d'une page, la parallélisation des téléchargements ou le cache DNS.

Bref, il s'agit vraiment d'un très bon livre pour tout développeur ou administrateur où la plupart des recettes sont applicables en quelques minutes seulement pour un résultat immédiat et assez spectaculaire.

Flux RSS des billets

Flux RSS des billets

Rechercher sur pwet.fr

À retenir

Derniers commentaires

Archives

Nuage de tags

Bioutifoul photos

Quelques liens

Licence d'utilisation

Contenu sous Licence Creative Commons By-Sa

Sauf mentions spécifiques, les billets et les photos publiés sur ce site sont placés sous la licence Creative Commons by-sa.

Pour toute utilisation dépassant le cadre de cette licence, merci de me contacter par e-mail.