Meilleure façon d'intégrer image SVG

Bonjour,

Je souhaite refaire toutes les icônes de mon site de manière à pouvoir les intégrer en SVG.

En effet, mon site étant basé principalement sur la géolocalisation & google ayant abandonné le support d'ie8, je peux profiter du SVG qui apparait comme la solution pour les écrans rétina et autres futures ratio d'écran. Le support est possible avec un fichier .png, mais ici ça me ferait perdre du temps pour rien, le svg faisant gagner énormément de temps de création (Finit illustrator ou Photoshop Ex: Faticon) .

Je veux donc tout, et j'ai l'impression que ce n'est pas possible :

1/ que mon SVG s'adapte aux différents ratio d'écran (jusqu'ici pas de problème c'est son métier)
2/ que mon SVG soit modifiable en JS/CSS (adieu implémentation par la balise img et background-image)
3/ que mon SVG puisse être mis en cache (sans img ou background-image, la tache s'avère impossible ?)
4/ Ne pas utiliser les web font SVG qui selon moi, seront emmenés à devenir obsolètes (accessibilité, pas fait pour à la base, requête pour chaque icone en +, js en plus pour le chargement, ... ) ou du moins remplacé à terme par une technologie plus avantageuse.
5/ Que l'on puisse gérer l'utilisation multiple d'un SVG sans pour autant copier tout le code à chaque fois (en cas d'intégration direct avec la balise <svg>)
6/ Ne faire qu'un appel pour tous les SVG (un sprite css SVG à la rigueur)

Alors d'après mes conclusions j'ai choisis :

L'intégration des svg en balise inline dans une fonction que j'appel pour savoir quel svg aller chercher à chaque fois. C'est le mieux que j'ai pus faire :

Avantages :
1/ ok
2/ ok
4/ ok
5/ ok

Par contre on ne résous pas l'inconvénient principal :

3/ Mettre en cache ce SVG
6/ impossible de cette manière

C'est impossible, puisse qu'il s'agit d'une fonction dynamique. J'avais pensé à un sprite CSS regroupant tous les SVG, mais en plus d'avoir un support limite limite, on ne peux pas interagir avec les SVG en JS/CSS...

Vu que je dois avoir 30 icônes à changer sur le site, disons que les SVG en question vont ajouter environ 50ko

Ma question :

Cela vaut t'il le coup d'avoir 50ko chargé en + pour chaque connexion afin d'alléger le serveur de 30 requêtes une première fois (vu que en img ça aurait été mis en cache par la suite) et d'avoir une réel solution avec un réel support au ratio des écrans + transformation en CSS/JS ? Sans compter que pour l'instant il ne s'agit que de 30 images, mais quand il y en aura 300..

A première vu je dirais oui, mon site étant quasiment entièrement en ajax, chargé une fois, les rechargements de page sont rares, mais peut-être existe t'il une solution meilleure qui pourrait en plus mettre en cache ?

J'ai vu une solution intéressante également pour éviter de charger de tous les SVG alors qu'on en à pas forcément besoin : file_get_content('mon_svg'), qui va récupérer le contenu du svg et l'intégrer. Mais dans ses cas là, on rajoute une requête au serveur, non ? Peut-être pas d'ailleurs, puisse qu'il ne s'agit pas d'une requête client mais serveur, cela est peut-être casi-instantané ? Est-ce que dans ses cas là, le SVG peut être mis en cache ? Personnellement je ne pense pas, puisse qu'il s'agit du serveur qui va s'occuper de récupérer le contenu du SVG, mais bon sait-on jamais avec un cache spécial style Varnish ?

En tout cas, merci pour vos réponses, comme vous pouvez le constater, ma réflexion est déjà bien aboutie, je désire seulement savoir s'il est possible d'améliorer en plus le tout (surtout au niveau du cache).

Pour l'instant l'utilisation de file_get_content('mon_svg') me semble être la plus avantageuse (pour éviter de charger tous les SVG unitilement). On pourrait même créer une fonction pour avoir des comportement différent via l'id pour des SVG similaires (pour éviter que 2 svg identiques s'activent en même temps en cas d'utilisation avec le JS/CSS) ex :

$MonSVG = file_get_content('mon_svg') ; 

fonction addSVG($idSVG , $SVGelement)
{
SVGelement = str_replace('id=""' , 'id="'.$idSVG.'"' , SVGelement)
} 

// Mon premier SVG qui doit faire une animation
addSVG('MonSVG1', $MonSVG) ; 

// Mon ddexième SVG qui représente la même chose 
addSVG('MonSVG2', $MonSVG) ; 

Après si ont veut on peut donc cibler l'un sans impacter sur l'autre :

<script>
document.getElementById('MonSVG1').style.display = 'none' ; 
// Ne fera disparaitre que le premier SVG 
</script>

A méditer à l'amélioration donc.

Bonne journée/soirée à tous !

Kevin.
Modifié par kevinlourenco (17 Jun 2016 - 21:08)

kevinlourenco a écrit :
En tout cas, merci pour vos réponses, comme vous pouvez le constater, ma réflexion est déjà bien aboutie, je désire seulement savoir s'il est possible d'améliorer en plus le tout (surtout au niveau du cache).

Si la question se résume à charger une ressource et optimiser sa mise en cache, je te suggérerais :
- l'utilisation de la balise LINK avec l'attribut @rel = prefetch
- le recours à la forme data URI pour fournir le flux de données représentant le SVG et ne faisant pas appel à une requête HTTP
Pas sûr toutefois que ceci réponde à ton interrogation actuelle, car j'ai été vite perdu dans le jeu des questions / réponses de ton sujet .

Merci pour ton retour,

Malheureusement impossible d'utiliser ta technique, puisque principalement utilisé sur des fichiers .php qui ne sont pas mis en cache, donc eux-non plus. Ce qui ne change rien par rapport à l'intégration du SVG directement au niveau de la mise en cache si on en croit ce morceau :

"Les ressources identifiées par data-URI se retrouvent partie intégrante du fichier dans lequel elles se trouvent. Ce faisant, elles seront mise en cache avec leur fichier parent. Il ne serait donc pas judicieux d'intégrer des éléments data-URI au sein d'un fichier dont la mise en cache n'est pas permise à long terme par votre serveur (comme des fichiers HTML ou PHP)."

Je pense que c'est surtout un avantage dans un fichier .js ou .css

Difficile en plus de modifier le contenu dynamiquement (pour changer l'id, ou même la taille du svg en fonction des besoins) comme montré plus haut puisque le tout est encodé en base-64 ( en tout cas moins simple qu'un str_replace())

Sur le tuto s'est bien précisé : "Finalement, comme l'encodage base64 ajoute environ 10% au poids total d'un fichier. Si on fait un calcul simple, 10% de 100 octets est abordable, mais l'ajout de 10% de 200 Ko est plus considérable en terme de poids. Ce faisant, il n'est pas recommandé d'utiliser data-URI pour des fichiers pesant plus de 4 Ko; en dessous, aucun problème. (4 Ko est environ l'équivalent d'une requête HTTP supplémentaire)"

En sachant, si je ne me trompe pas, que l'injection du contenu en PHP n'ajoute pas de requête HTTP supplémentaire (puisque requête serveur) , l'intérêt est donc nul, à part augmenter le poids du SVG de 10% si j'ai bien suivis.

Méthode + complexe et pas forcément + utile, mais merci pour le raisonnement.

PS : il est vrai que j'ai formulé mon argumentaire comme si je réfléchissais en même temps, c'était avant tout pour montrer comment j'en étais arrivé à ma conclusion, le sujet SVG étant assez complexe si on veut réunir le maxime d'avantages.
Modifié par kevinlourenco (17 Jun 2016 - 22:45)