Flash n'est pas toujours justifié

(reprise du message précédent)

Seoplayer a écrit :
ni pour la methode packer (avec l'eval) ni pour le gzip, car comme tu l'indique on gagne surement en loading mais après faut que le nav' bosse et c'est du coup une optimisation pas nécessaire

Oui pour packer, qui demande pas mal de boulot au navigateur parait-il. Par contre, la décompression du gzip est gérée non pas par l'interpréteur javascript, mais par des parties bien plus performantes du navigateur (du code compilé qui va vite), donc c'est presque négligeable (parait-il, une fois de plus). Pour les scripts JS, JSMin + compression gzip, c'est bien (et c'est ce qui donne le chiffre de 15 Ko annoncé par jQuery).

Pour rajouter mon grain de sel par rapport au packer : je n'emploie pas ce type de compression car cela me pose plusieurs problèmes :

1/ Impossible à débugguer. A la rigueur ça "peut" être utile pour une bibliothèque externe, mais pas pour ses propres scripts

2/ Problèmes d'interpretation des regexp. Tous les packer que j'ai essayés ont du mal avec les regexp à un moment où à un autre

3/ J'utilise un systeme qui cumule tous mes fichiers JS en un seul et les passent à JSMin ensuite avant de les rendre gzippé (tout ça pour accelerer le chargement et ne faire qu'un seul hit serveur), et ça ne fait pas bon ménage avec si j'ai un fichier packé dans le tas.
Ce n'est peut-être que propre à mon application et mon système de compression cela dit.

Florent V. a écrit :

J'ai trouvé deux inconvénients majeurs de beaucoup de sites en flash (mais pas inhérents à la technologie), qui sont les suivants:

1. Une URL qui n'est pas mise à jour. Depuis l'accueil, on peut charger chaque page du portfolio avec son URL propre, et c'est bien (notamment pour le référencement). Mais une fois sur une page de portfolio, le changement de page ne fait pas bouger l'URL. Donc problème pour bookmarquer, envoyer le lien, etc.

Très juste en effet, je n'ai pas géré 2 choses sur le portfolio, le directlink et le back navigateur, cela dit je vais très certainement revoir cette partie du site quand j'aurais une minute (en même temps j'apporterais des améliorations).

Florent V. a écrit :
2. Les animations, le mouvement, c'est bien... quand ça a un sens. Un élément qui bouge avec à travers la page ou vibre, ça peut servir à attirer l'attention sur un contenu qui est modifié, par exemple. C'est ce que tu fais dans les pages portfolio. Par contre, sur la page d'accueil:
- pourquoi ça prend trois plombes à se mettre en place? ça veut dire quoi ce chargement progressif?
- pourquoi quand je charge un contenu ça replie tout, passe au noir, et déploie d'autres blocs? ça veut dire quoi tout ça?

Bon, c'est peut-être moi, mais ce genre de transition inutile (sauf pour en mettre plein la vue) m'insupporte. Et je pense que ça nuit à l'ergonomie des sites qui les emploient, qu'ils soient en Flash ou en HTML/CSS/JS.

(Sinon bien dans l'ensemble, techniquement réussi même si un peu gourmand en CPU sur mon iMac neuf..., design très sympa.)

Je suis parfaitement d'accord avec toi beaucoup de choses inutiles ou sans réel sens effectivement, seulement au départ ce site est pour moi une base qui va me permettre de dire "Flash n'est pas forcément indispensable, regardez ce qu'il est possible de faire en HTML/CSS/JS". Alors en effet j'ai du "exagérer" sur pas mal de choses... m'enfin le site n'est pas figer et quand çà va me prendre il évoluera

De toute manière le site globalement va évoluer sous peu pour passer entièrement en ajax et ne pas avoir de changements de page, là c'est une solution temporaire, mais merci pour tes remarques elles sont très pertinentes.
Modifié par Seoplayer (05 Oct 2008 - 16:37)

Florent V. a écrit :

Oui pour packer, qui demande pas mal de boulot au navigateur parait-il. Par contre, la décompression du gzip est gérée non pas par l'interpréteur javascript, mais par des parties bien plus performantes du navigateur (du code compilé qui va vite), donc c'est presque négligeable (parait-il, une fois de plus). Pour les scripts JS, JSMin + compression gzip, c'est bien (et c'est ce qui donne le chiffre de 15 Ko annoncé par jQuery).

Je vais voir çà pour le gzip c'est certainement une bonne idée, on m'en avait déjà parlé

Tymlis a écrit :
Pour rajouter mon grain de sel par rapport au packer : je n'emploie pas ce type de compression car cela me pose plusieurs problèmes :

1/ Impossible à débugguer. A la rigueur ça "peut" être utile pour une bibliothèque externe, mais pas pour ses propres scripts

2/ Problèmes d'interpretation des regexp. Tous les packer que j'ai essayés ont du mal avec les regexp à un moment où à un autre

3/ J'utilise un systeme qui cumule tous mes fichiers JS en un seul et les passent à JSMin ensuite avant de les rendre gzippé (tout ça pour accelerer le chargement et ne faire qu'un seul hit serveur), et ça ne fait pas bon ménage avec si j'ai un fichier packé dans le tas.
Ce n'est peut-être que propre à mon application et mon système de compression cela dit.

Moi aussi j'ai déjà eu des problèmes en essayant la méthode packer ...

A propos de compression Gzip, comment la mettre en place ? (il ne suffit pas de gziper son fichier et de l'envoyer sur le ftp je suppose...)

Seoplayer a écrit :
De toute manière le site globalement va évoluer sous peu pour passer entièrement en ajax et ne pas avoir de changements de page

Avec une URL unique dans ce cas non ? (ce n'est pas pour critiquer, la problématique m'intéresse)
Modifié par SolMJ (07 Oct 2008 - 13:29)

Pour gzip c'est très simple et parfaitement expliqué chez Yahoo (avec d'autres moyens d'améliorer le chargement).

Il suffit de mettre dans ton .htaccess le code suivant pour initier le gzippage de certains types de fichier (les fichiers texte surtout -html, js, css-)

<IfModule mod_deflate.c>
	AddOutputFilterByType DEFLATE text/html text/x-json text/css text/javascript application/x-javascript text/js
	<IfModule mod_headers.c>
		Header append Vary User-Agent
	</IfModule>
</IfModule>

Il faut bien sur ton serveur sache faire du gzip et que le navigateur sache le comprendre, sinon rien ne se passera.

SolMJ a écrit :
A propos de compression Gzip, comment la mettre en place ? (il ne suffit pas de gziper son fichier et de l'envoyer sur le ftp je suppose...)



Avec une URL unique dans ce cas non ? (ce n'est pas pour critiquer, la problématique m'intéresse)

Oui et non, car si je veux pouvoir gérer le directlink (liens direct vers une partie du site) je dois passer des paramètres dans l'url...

Ce qui veut dire en gros qu'au lieu d'avoir des urls du type :
-www.site.com?page=mypage

J'aurais des pages avec des urls du type :
-www.site.com#page=mypage

Ce qui permet de pas avoir de changement de pages à chaque fois qu'un visiteur cliquera sur un lien.
Modifié par Seoplayer (08 Oct 2008 - 08:56)

Seoplayer a écrit :


Oui et non, car si je veux pouvoir gérer le directlink (liens direct vers une partie du site) je dois passer des paramètres dans l'url...

Ce qui veut dire en gros qu'au lieu d'avoir des urls du type :
-www.site.com?page=mypage

J'aurais des pages avec des urls du type :
-www.site.com#page=mypage

Ce qui permet de pas avoir de changement de pages à chaque fois qu'un visiteur cliquera sur un lien.

Ok et au niveau référencement, ça marche aussi bien qu'avec de "vrais" liens ?

L'ideal est d'avoir la double navigation

- www.site.com?page=mypage pour les moteurs (avec une récriture d'url en prime, c'est toujours mieux) et donc un accès direct à chaque ressource, même sans Javascript.

- www.site.com#page=mypage pour la navigation en javascript, l'adresse changeant (en js) à chaque nouveau chargement.

Seoplayer a écrit :


Moi aussi j'ai déjà eu des problèmes en essayant la méthode packer ...

quand on code proprement, et qu'on ne pack que du code non compressé à l'avance, ça passe très bien.

Un conseil, passe ton code sous JSLint et corrige le en écoutant les conseils, tu n'auras aucun problème ainsi.

Tymlis a écrit :
L'ideal est d'avoir la double navigation

- www.site.com?page=mypage pour les moteurs (avec une récriture d'url en prime, c'est toujours mieux) et donc un accès direct à chaque ressource, même sans Javascript.

- www.site.com#page=mypage pour la navigation en javascript, l'adresse changeant (en js) à chaque nouveau chargement.

seoplayer, la méthode que te décris Tymlis est exactement la même que celle utilisée par SWFAdress, peut-être qu'en disant cela tu comprends mieux

SolMJ a écrit :


Ok et au niveau référencement, ça marche aussi bien qu'avec de "vrais" liens ?

Comme le dis Tymlis au niveau SEO il te faut la double navigation.

Gatsu35 a écrit :


seoplayer, la méthode que te décris Tymlis est exactement la même que celle utilisée par SWFAdress, peut-être qu'en disant cela tu comprends mieux

Je connais SWF Adress et je n'ai pas besoin de comprendre ce que dis Tymlis vu que je sais déjà faire ce dont il parle

Gatsu35 a écrit :

quand on code proprement, et qu'on ne pack que du code non compressé à l'avance, ça passe très bien.

Un conseil, passe ton code sous JSLint et corrige le en écoutant les conseils, tu n'auras aucun problème ainsi.

çà dépend ce que tu appelle coder proprement en fait, mais bon de toute façon balancer un eval au navigateur c'est pas très sexy je trouve.

Sinon j'avais passé mon code sous JSLint et il me donne des erreurs de syntaxe qui s'avère ne pas être des erreurs

Seoplayer a écrit :


çà dépend ce que tu appelle coder proprement en fait, mais bon de toute façon balancer un eval au navigateur c'est pas très sexy je trouve.

Sinon j'avais passé mon code sous JSLint et il me donne des erreurs de syntaxe qui s'avère ne pas être des erreurs

edit : je retire ce que j'ai dit, ça reste assez propre.

Il y a juste l'imbrication de fonctions (jusqu'à 15 imbriquées), je ne pense pas que le chain s'utilise de cette manière.

mais sinon concernant la compression de JS
tu peux tester la puissance des compresseurs (et au passage utiliser l'outil pour compresser ton JS) :
http://compressorrater.thruhere.net/
Modifié par Gatsu35 (08 Oct 2008 - 16:37)

Gatsu35 a écrit :


edit : je retire ce que j'ai dit, ça reste assez propre.

Il y a juste l'imbrication de fonctions (jusqu'à 15 imbriquées), je ne pense pas que le chain s'utilise de cette manière.

mais sinon concernant la compression de JS
tu peux tester la puissance des compresseurs (et au passage utiliser l'outil pour compresser ton JS) :
http://compressorrater.thruhere.net/

En fait si le chain s'utilise de cette manière, j'aime pas du tout la cascade d'imbrications que j'ai du faire mais je vois pas comment faire autrement (enfin ya d'autre méthodes comme le time out mais çà va être encore plus pourrit je pense) parce que de toute façon à un moment donné je suis obligé de faire appel à toutes ces fonctions les unes à la suite des autres, cela dit j'ai pris le soin d'initialiser dès le départ les fonctions d'effets pour que çà tourne un peu plus droit mais je suis parfaitement d'accord avec toi c'est très naze ce genre d'imbrication à la con çà fait un peu bourrin, faudrait voir avec des flasheurs comment ils font en AS mais il me semble qu'ils font des clips directement.

Très intéressant ton outil compressor rater merci je connaissais pas

PS : Au passage je suis en recherche d'une nouvelle agence web pour un CDI si vous avez des pistes.

Ou alors pour les 50 imbrications la solutions serait éventuellement de découper les effets par groupes/blocs et faire des appels différemment mais au final le résultats serait le même yaura de toute manière autant d'appels successifs... Mais si t'as une idée çà m'intéresse

Bien, propre, bon boulot.
Juste une chose: je rejoins tout à fait Florent sur son deuxième point:

Florent V. a écrit :

2. Les animations, le mouvement, c'est bien... quand ça a un sens. Un élément qui bouge avec à travers la page ou vibre, ça peut servir à attirer l'attention sur un contenu qui est modifié, par exemple. C'est ce que tu fais dans les pages portfolio. Par contre, sur la page d'accueil:
- pourquoi ça prend trois plombes à se mettre en place? ça veut dire quoi ce chargement progressif?
- pourquoi quand je charge un contenu ça replie tout, passe au noir, et déploie d'autres blocs? ça veut dire quoi tout ça?

Bon, c'est peut-être moi, mais ce genre de transition inutile (sauf pour en mettre plein la vue) m'insupporte. Et je pense que ça nuit à l'ergonomie des sites qui les emploient, qu'ils soient en Flash ou en HTML/CSS/JS.

Je rejoins aussi son avis ce n'est pas la manière la plus judicieuse avec laquelle j'aurais pu exploiter les possibilités de mootools, mais encore une fois c'est l'effet flash-like qui en met plein la vue dans tous les sens qui était recherché dans un but argumentatif.

Cela dit je dois encore parfaire mon expérience à ce niveau car effectivement il y a des façons beaucoup plus censé, ergonomique, créative et interactive d'exploiter les tweens JS et je vais travailler encore dans ce sens.

En tout cas, comme je l'ai dit précédemment c'est un avis très pertinent et pour le coup on sent de suite l'expérience de Florent en matière de web design. J'm'attendais pas à avoir cette remarque ici en fait, j'avais surement une vision différente des membres d'alsacréation, du coup j'vais repasser un peu plus souvent je pense.

Seoplayer > Vu que tu as l'air de bien maîtriser les librairies d'effets JS, je suis confronté à une problématique depuis peu : j'ai ajouté quelques effets d'ouvertures JQuery sur un site pour tester, le problème c'est qu'au 1er chargement les effets rament, mais plus au n+1ème chargement, dois-je en conclure que c'est le chargement des bibliothèques qui produisent le ralentissement de mes effets ?

C'est d'autant plus embêtant qu'à terme, je compte garder cet effet pour le 1er chargement de la page uniquement... Aurais-tu un conseil à me donner pour résoudre ce problème) ?