Reprise du message précédent :
Déterrage, à tout hasard.
 
Vous avez trouvé une solution ultime pour gérer les images en html/css (php si besoin) pour répondre au mieux aux problématiques de taille d'écran (mobile, tablette, ordi, retina ou non) et au support des navigateurs ?
 
Là je planche sur un portfolio et un site pure diy et j'avoue que ça commence à être le bronx :
- avif / webp / jpg (j'ai fait un truc pour générer les 3 via php/imagick)
- quelques tailles d'écran : en "petit" (2 colonnes sur grand écran) soit environ 500px de large, puis en grand sur "petit" écran (960px de large) et un vrai grand (2048px de large)...  
- sauf que sur un smartphone récent avec un bel écran, c'est pas parce que l'écran dit qu'il fait "320px css" de large qu'on doit lui afficher une image de 320px max. retina staïle
- sauf que les utilisateurs de smartphones et tablette les tournent
- sauf que parfois les utilisateurs de smartphones sont sur un réseau 3G pourri, parfois sur un 4G qui va plus vite que l'adsl de leur ordi
- que les utilisateurs d'ordi ont de plus en plus des "upscales" (genre 1920x1080p sur un ordi portable de 15 pouces + réglage à 150% dans Windows), les Mac vont être en 2x ...
- ...
 
C'est quoi le tuto ultime pour les enterrer tous ?
 
N'empêche que j'ai découvert l'avif au passage, et que c'est impressionnant, j'ai des images ou j'ai divisé le poids par 3 ou 4 avec un impact vraiment minime sur la qualité perçue à 100%.

Ben srcset dans img
 
https://www.alsacreations.com/artic [...] rcset.html
 

ouais mais pour l'instant je n'ai jamais vu de mise en œuvre pratique avec plusieurs formats de fichiers, plusieurs tailles et plusieurs densités. Sans compter la problématique de la capacité en terme de connexion.

La composante "bande passante", tu n'as pas a t'en soucier. C'est le navigateur qui prendra le plus adapté parmi les variantes dispo et matchant les autres critères (format, dimensions)

En HTML, t'as un truc pour proposer différentes tailles d'images en fonction de la taille de l'écran dans la balise <img /> :
https://forum.hardware.fr/hfr/Progr [...] 8204_1.htm

Je me demande si tu as lu les réponses avant

En fait c'est pas une question de bande passante, mais de servir l'image en fonction du device, là où src-set est là

Bha srcset gère l'aspect bande passante pour nous quoi, mais c'est bien un des critères de choix de la variante finale utilisée

Quand j'ai commencé à rédigé mon msg, y'avait rien. J'ai mis du temps à retrouver l'attribut srcset (je me souvenais d'un topic qui était passé là-dessus)  

A la grosse, il prendra l'image adapté à l'écran et par la même occasion, le poids de l'image dépendra de ses dimensions.
Après la chose à faire en général c'est que tu peux dans ton src afficher une image de mauvaise qualité ultra basse résolution et ensuite déclarer les bonnes images debonne qualité dans le src-set.
 
Et par la même occasion ajoute  loading="lazy"  sur les tags img que tu ne veux pas qu'ils se chargent tout de suite.
 
Si ton site est en longueur bah tout ce qui est en dessous n'a rien à foutre au chargement.
 
Je bosse sur un site en ce moment où il y a pas mal d'images et aussi des appels ajax (xhr) pour charger des articles de blogs. (ou autre)
Ben tout ce qui n'apparaît pas dans l'écran n'est pas chargé, et je le charge que lorsque le bordel s'affiche sur l'écran.

Honte à toi, je t'ai mis sur la page des hallofshame du html

Mais par exemple si on met une contrainte a "jusqu'à 320px" un smartphone qui simule une largeur de 320px mais avec une densité de malade (retina) il va charger quoi ? Le 320 ? une image au dessus qui correspone au moins au double ?

Rtfm  

Beaucoup d'infos dans un gros projet d'images réalisé dans ma boîte précédente : https://tech.decitre.fr/posts/refon [...] generation

Intéressant comme REX

 
Génial et super intéressant, ça fait partie des infos que je cherchais, un vrai retour d'expérience et pas juste quelques principes théoriques.

 
je pense que les outils comme https://imulus.github.io/retinajs/ ou http://dense.rah.pw/ répondent à une partie de ton problème, à savoir que ton user charge une image avec une réso standard, et si sa résolution est "retina staïle", il cherche à charger la même image mais suffixée par "@2x" (retina.js) ou "_2x" (dense)...
 
EDIT:   by plein de monde au dessus, avec srcset que je ne connaissais pas, merci

j'aime bien l'utilisation avec la balise picture, que je trouve plus claire que juste un img, mais malgré tout ça devient vite le bordel avec 3 formats d'images (avif/webp/jpg) + leurs tailles.
Un truc que je n'ai jamais trop vu abordé, c'est la réflexion sur "quelle taille générer" quand on veut faire des images qui seront 100% de la largeur du navigateur.
 
L'article de decitre est aussi intéressant sur un point :
sur écran retina, la qualité perçue est meilleure en ayant en amont une image 2x plus large/haute que le viewport, quitte à compresser plus violemment pour limiter le poids et la précision "inutile" (n'améliore pas le rendu perçu). OK
 
Par contre si on n'utilise pas la notation 2x mais qu'on donne uniquement des règles en pixels (genre affiche cette image si résolution d'écran > x, façon media query css), on va utiliser la même image par exemple pour :
- un smartphone avec un écran 1080p sur 6 pouces, donc où on a tout intérêt à utiliser certes une haute résolution mais une compression de barbare
- un écran d'ordi de 32 pouces où on aurait tout intérêt à avoir une compression moins barbare pour un meilleur rendu (car 1x et non pas 2 ou 3x)
 
Je ne sais pas si je suis clair, mais c'est là où je trouve que c'est un peu le bordel entre densité (haute densité = besoin de grande image mais une compression forte est ok) vs résolution (haute résolution mais faible densité = besoin de grande image mais avec une compression faible).

 
Les autres articles de la séries sont aussi intéressants à lire.

Bon alors si tu veux une méthode ultime, il te reste à faire ça :  
 
https://developer.mozilla.org/fr/do [...] ive_images
 
Donc à la grosse :  
 

 
Bon à la grosse tu devras créer un objet "image" dans le langage que tu utilises et celui-ci devra être capable de générer le code HTML nécessaire au bon fonctionnement.
 
et sinon  voilà les attributs que tu peux foutre sur <source>
https://www.w3schools.com/tags/tag_source.asp
 
Je t'invite à lire les specs/docs.
 
 
En gros je viens d'apprendre pas mal de trucs, merci

Je ne savais pas que <source> pouvait se mettre dans un <picture>. Je connaissais juste srcset comme attribut d'img.
J'aurai aussi appris des trucs

Nous chez Decitre au final, ça donnait ça :

<picture title="L'empire du vampire" class="lozad" data-iesrc="https://products-images.di-static.com/image/jay-kristoff-l-empire-du-vampire/9782378762230-45x70-1.jpg">
    <source type="image/webp" data-srcset="https://products-images.di-static.com/image/jay-kristoff-l-empire-du-vampire/9782378762230-45x70-1.webp 1x,https://products-images.di-static.com/image/jay-kristoff-l-empire-du-vampire/9782378762230-45x70-2.webp 2x" class="lozad" />
    <source type="image/jpeg" data-srcset="https://products-images.di-static.com/image/jay-kristoff-l-empire-du-vampire/9782378762230-45x70-1.jpg 1x,https://products-images.di-static.com/image/jay-kristoff-l-empire-du-vampire/9782378762230-45x70-2.jpg 2x" class="lozad" />
    <img src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDACAWGBwYFCAcGhwkIiAmMFA0MCwsMGJGSjpQdGZ6eHJmcG6AkLicgIiuim5woNqirr7EztDOfJri8uDI8LjKzsb/2wBDASIkJDAqMF40NF7GhHCExsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsb/wgARCAAUAA4DASIAAhEBAxEB/8QAGAAAAgMAAAAAAAAAAAAAAAAAAAECAwT/xAAVAQEBAAAAAAAAAAAAAAAAAAAAAf/aAAwDAQACEAMQAAABzKSWoA//xAAYEAADAQEAAAAAAAAAAAAAAAAAAQIQEf/aAAgBAQABBQKUUdG9/8QAFREBAQAAAAAAAAAAAAAAAAAAEBH/2gAIAQMBAT8Bh//EABQRAQAAAAAAAAAAAAAAAAAAABD/2gAIAQIBAT8BP//EABQQAQAAAAAAAAAAAAAAAAAAACD/2gAIAQEABj8CX//EABkQAQEBAQEBAAAAAAAAAAAAAAERACEQQf/aAAgBAQABPyEJ3A5LhyCZEL88u//aAAwDAQACAAMAAAAQxg//xAAVEQEBAAAAAAAAAAAAAAAAAAAQMf/aAAgBAwEBPxCD/8QAFREBAQAAAAAAAAAAAAAAAAAAEBH/2gAIAQIBAT8Qp//EABwQAQADAAIDAAAAAAAAAAAAAAEAETEhQVFxkf/aAAgBAQABPxDtl+uH7PFWNlQp5ArIbMTtLa2Kdn//2Q==" alt="L'empire du vampire" title="L'empire du vampire" height="65" width="45" class="lozad-placeholder"/>
</picture>
<noscript>
    <img src="https://products-images.di-static.com/image/jay-kristoff-l-empire-du-vampire/9782378762230-45x70-1.jpg" alt="L'empire du vampire" title="L'empire du vampire" height="65" width="45"/>
</noscript>

Ca permettait de gérer :

• le lazyloading (à l'époque c'était pas assez supporté en natif donc on utilisait lozad)
• le LQIP
• les formats jpeg et webp
• le retina
• le noscript pour le SEO vu qu'on était dépendant du JS pour le lazyloading (ce qui ne serait pas forcément nécessaire aujourd'hui vu le support natif : https://caniuse.com/loading-lazy-attr)

Et tout ça pour plusieurs millions de produits  

Mince j'avais commencé mon message hier mais j'ai oublié d'appuyer sur "valider". Donc entre temps j'ai une réponse supplémentaire
 
J'ai pas encore testé si on peut bien mettre plusieurs images possibles dans le srcset de la balise <source>, c'est pas super clair -> visiblement c'est possible youhou !
 
mais si ça marche il doit en effet y avoir moyen de faire un truc du genre
 
<picture>
  <source type="image/avif" media="(max-width:649px)" srcset="pyramidBD.avif, pyramidBD2x.avifx2">
  <source type="image/avif" media="(min-width:650px)" srcset="pyramidHD.avif, pyramidHD2x.avifx2">
  <source type="image/webp" media="(max-width:649px)" srcset="pyramidBD.webp, pyramidBD2x.webp x2">
  <source type="image/webp" media="(min-width:650px)" srcset="pyramidHD.webp, pyramidHD2x.webp x2">
  <source type="image/jpeg" media="(max-width:649px)" srcset="pyramidBD.jpg, pyramidBD2x.jpg">
  <source type="image/jpeg" media="(min-width:650px)" srcset="pyramidHD.jpg, pyramidHD2x.jpg">
  <img src="pyramidBD.jpg" alt="onvayarriver" loading="lazy" title="xxx">
</picture>
 
--> donc ça doit fonctionner.
 
J'aime bien aussi les "low quality placeholders" de l'article de decitre, c'est sympa, il faut juste en effet générer le data et le stocker en bdd en amont... encore que dans l'absolu si les perfs ne sont pas critiques (dans mon cas c'est pour un site peu visité, c'est surtout pour optimiser le SEO via des temps de chargements optimums + apprendre au passage) ça peut même être un bête fichier texte à côté des jpeg, wepb et compagnie et charger le contenu en php et l'écrire dans le html rendu.
 
En tout cas merci ratibus (et les autres) pour les précisions.

Il y a aussi la décision de la génération initiale ou à la demande.
J'ai vu que de plus en plus sur le web on trouve des trucs du genre <img src="toto.php?image=machin.jpg&size=1500">
 
J'aime bien hacker ces trucs pour récupérer des images en plus grand parfois. En général ça marche assez bien
 
Pour un site à petite fréquentation la question se pose de générer à la demande (+stockage des fichiers générés bien sûr).
 
Je n'arrive plus à retrouver l'article, mais j'avais souvenir de quelqu'un qui avait fait un truc assez cool du genre réutiliser les erreurs 404 pour gérer ça proprement.
En gros il affichait l'image direct, genre <img src="toto_1500.jpg"> et si le jpg allait générer un 404, ça redirigeait vers un script qui générait le jpg en question, le stockait et retournait son contenu (et un code 200 OK, pas 404). Comme ça l'appel suivant, hop le fichier existait déjà et évitait tout test d'existence supplémentaire, passage par php...
 
Si ça dit quelque chose à quelqu'un, je veux bien qu'il linke l'article.
 
Edit :  
Trouvé : https://lehollandaisvolant.net/?d=2 [...] -phpapache
 
Je trouve ça assez élégant comme technique. Ca peut éviter de passer par toute une moulinette plus ou moins manuelle pour générer les déclinaisons d'images (je rappelle que je pars d'un site "statique", à l'ancienne, php/html (pas de wordpress & co).

le soucis de la 404 c'est que ça te pourri les logs après

Combiné à un CDN ou autre serveur externe pour gérer tes assets, je vois pas en quoi cela pourrit les logs

J'avais utilisé exactement cette technique dans ma deuxième boite, y a plus de 10 ans (ça me rajeunit pas...), ça fonctionnait bien et effectivement ça me permettait de squeezer le hit sur mon applicatif Django quand l'image existait vu que c'était nginx qui servait directement l'image depuis le dossier statique (et sans devoir prégénérer à l'avance toutes les images)

Par contre faut du coup bien monitorer à coté, parce que si t'as un problème sur le truc qui copie tes miniatures vers ton dossier statique (genre plus de place sur le disque et tu report mal l'erreur), bin tu ne peux pas compter sur une alerte sur le nombre de hits en 404 de tes miniatures pour détecter un problème de ce coté là.

@gatsu35: Il me semble (mais ça date donc je me souviens plus bien) que j'avais justement modifié la configuration du reporting 404 sous nginx pour le dossier contenant ces images, justement pour pas polluer les logs.

@skylight: Si tu te bases sur le handler 404 de ton frontal web pour déclencher la génération des images si elles n'existent pas, si tu ne changes pas la configuration de tes logs, ça va par définition te faire une 404 dans tes logs à chaque "sous version" qui n'existe pas... Alors qu'en vrai c'est pas une "vrai" 404 si c'est juste le fait que ta miniature n'a pas encore été générée.

Moi je gère les redimensionnement avec un .htacces dans le dossier de ma mediatheque du genre:

Du coups à la racine j'ai un fichier php qui reçoit l'url demandé quand elle n'existe pas déjà, et la je vérifié si le dossier existe dans les gabarits de taille possible (thumbnail, newsletter, product) qui lui même définit des tailles pour vérifier qu'on ne demande pas n'importe quoi...
Si c'est une demande légitime je génère le fichier, l'écrit dans le bon dossier pour la prochaine requête et je le sert avec les bons en-tête pour que même le 1er hit soit servis.  

Et au niveau du script de l'upload de fichier il y'a bien sur un clearcache des dossiers redimensionné lors du changement du fichier original.
 
Par contre je ne me suis encore jamais pris la tête a gérer des balises picture avec whatmill source, mais c'est très intéressant, je me garde ça de coté !

mechkurt : oui ça me semble un excellente manière de procéder. Par contre j'aime bien l'ajout du hollandais volant :
RewriteCond %{REQUEST_URI} ./gravatar/(.*)$
RewriteCond %{REQUEST_URI} !./gravatar/$
Pour ne gérer QUE ce qui est dans un dossier spécifique (ici /gravatar) et donc éviter de rediriger toutes les 404 vers ce script. Des 404 on en a toujours à la pelle généré par le bots qui tentent de hacker les sites en permanence.
Ca peut aussi être une regex pour ne cibler que ce qui se termine en jpg, png, ...
 
Sinon j'ai un peu joué avec les LQIP... ben ça a l'air un peu mort avec la balise picture et/ou les srcset si on ne veut pas passer par du javascript.
 
En fait à partir du moment où on déclare un format plus adapté que le img src de base, c'est ce fichier qui est chargé et jamais le src du img, donc le LQIPn'est jamais utilisé, c'est à la fois logique si c'est un fichier externe, mais dommage dans le cas présent.
 
en gros un machin comme ça :

 
ça ne fonctionne pas
 
J'imagine qu'il faudrait un bricolage en JS, du genre afficher les LQIP dans des balises image normales + passer en hidden la balise picture, et au document ready faire  l'inverse : cacher les LQIP et afficher à la place la balise picture.
C'est un peu du bricolage.
A la grosse louche pour une centaine d'images en 20x20 maxi, en jpeg base64 ça rajoute 100 ko, donc autour de 1 ko par image.
Sur une fiche produit ou truc du genre ça peut être sympa, sur une galerie d'images en lazy load ça rajoute pas mal de poids pour pas grand chose

J'ai bien précisé sur mon fichier .htaccess était dans le sous dossier dans le quel sont mes fichiers medias uploadable (img, pdf, etc.), donc il n'est impacté que par les requête les concernant.
 
J'ai l'id du fichier demandé dans la requête.
En gros mes fichiers c'est /dossier medias/type de fichier caché (ou taille généré)/mot clef de referencement-identifiant du fichier.format attendu pour l'export.
par exemple : /medias/thumbnail/mon-super-produit-123.jpg
qui correspondrait via la base de donnée à /medias/master/uid sjgnsudhgioqshdgk 123.png
Si thumbnail n'est pas un vrai gabarit de redimensionnement ou 123 une image valide, je renvoie une erreur.
 
Ce n'est au final pas pas plus lourd qu'une requête sur d'autres pages du site (panier par exemple, ou pire les pages de recherches ^^) ou je serais forcé de faire plusieurs requêtes SQL et ce bien souvent dans différentes tables... ^^

ah oui pardon, j'avais zappé l'histoire du htaccess dans le dossier.
 
Bon j'ai commencé à jouer un peu avec un fichier qui génère via les 404, c'est vaaachement pratique pour faire plein de formats comme on veut. J'ai spécifiquement autorisé quelques types de formats (avif, webp, jpg) et résolutions (100, 200, 500, ...) pour ne pas justement que tout le monde joue avec
 
Par contre c'est un poil lent pour générer à la volée s'il y a pas mal d'images
 
Su la partie portfolio du site, clairement il faut que j'anticipe la génération, sinon c'est genre 1 minute l'affichage de la page ))

C'est inéluctable, sache que la plus part du temps le navigateur ne fait pas plus de 10 requête simultané au serveur (il attend un retour avant d'en refaire une) et un redimensionnement d'image peut mettre moins d'1s on bien plusieurs dizaine suivant la méthode utilisé et le fichier de départ.
 
Dans ce genre de cas et si utilises ma méthode, tu peux très bien générer "coté admin" tes différentes taille de fichier "légitime" lors de l'upload...

Bon ben il se passe des trucs super chelous.
Sur mon ordi (window.devicePixelRatio de 1, vérifié) dans un div de 500 pixels de large, avec un srcset qui fait le split entre 500 et 501 et au dessus, ça me charge l'image d'au dessus.
wtf ?
 
le code c'est en gros :

 
Le problème est le même pour les photos chargées plus tard (en scrollant, via le lazyloading) qui sont donc clairement dans un div de largeur bien établie vu que tout le css est bien chargé
 
Et à l'inverse, dans chrome/"inspecter" en mettant en mode "mobile" j'ai un devicePixelRatio de 3, un viewport de 390px de large (simulation iPhone 12 Pro)... et ça me charge l'image de 500 pixels de large (alors qu'en théorie ça devrait charger le srcset de + de 500 pixels non ?) je croyais que justement le navigateur gérait ça tout seul...

Tu peux reproduire le bug sur un jsfiddle ou codepen qu'on puisse tester ?
 
Tu peux utiliser un hébergeur d'image comme le rehost hfr ou un générateur de placeholder comme celui-ci par exemple : https://dummyimage.com/

J'ai pas de compte, mais sur www.codepen.com tu mets ça dans le html :

 
et tu vois que ça charge l'image de 1000px de large !
 
Edit : j'ai l'impression que le test de min-width prend en compte la largeur totale du navigateur, pas celle du div ! Je vais aller rtfm...
Edit 2 : oui c'est bien ça ! A priori même chose si on met plusieurs fichiers dans le srcset avec 500w, 1000w
 
Donc dans le cas de mon portfolio sur 2 colonnes avec maxi 500px de large, ça marche mieux en faisant un srcet de 500 et 1000 en spécifiant "x2".
Quand il est sur 1 seule colonne sur mobile ça continue à charger l'image de 1000 pixels de large, même si le viewport fait 390px de large, ce qui est cohérent (390x2 est > 500).
 
Bon pour une image pleine largeur, bizarrement aussi ça n'a pas l'air de gérer le automatiquement 2x sauf à le spécifier expressément. Cad que le même code qu'au dessus dans l'inspecteur de chrome en mode mobile mais en spécifiant un div de 100% et une image de max-width 100%... ben il charge l'image de 500px !

Tu utilises media, qui correspond à la largeur de ta fenêtre total (qui se fout complétement de la taille du conteneur ou de la taille affiché de l'image), ton exemple fonctionne si tu redimensionne ton écran à moins de 500px de large.
Si tu veux tester en mettant un div conteneur contraint il faut modifier ton code :
 
Pas besoin de compte* sur Jsfiddle : https://jsfiddle.net/ymr9vhuw/1/

 
*Mais avoir un compte sur l'un ou l'autre et très pratique. ^^

ce bordel, plus je creuse moins je comprends c'est la fin de la semaine.
 
Bon déjà j'ai délégué le choix avif/webp/jpeg côté php, via http accept, comme ça je peux faire src="toto.$meilleure_extension_geree" (pseudo code hein) ce qui évite de tout tripler dans le html
 

ça c'est fait

Hello ici,
 
Je pense que ce thread n'est pas trop mon sujet, mais je tente quand même.  
 
Connaissez-vous une alternative à Adobe Express qui permette de créer une page web (vraiment juste une page, pas un site) avec des fonctionnalités un chouïa plus avancées, comme une mise en page un peu plus riche et  l'intégration de codes HTML par exemple et/ou de balise iframe ?
 
Merci par avance
 
PS : un exemple d'une page créée avec Adobe Express : https://express.adobe.com/page/SC4HY25FoaDBm/

C'est la cat prog ici, du coup, les pages web, on les code
Et en général, on est pas fan des outils de génération auto de pages web car souvent, ça fait du code merdique
 
Avec les CMS type Wordpress, aujourd'hui, on n'a plus trop à s'embêter avec ce genre d'outil comme frontpage, dreamweaver et compagnie

Je m'en doutais
 
Le truc c'est que notre CMS n'est pas banal et qu'on ne peut vraiment rien faire en dehors et pour les besoins ergonomiques et esthétiques d'un projet, on aurait besoin de le faire héberger sur ce type de support pour avoir plus de flexibilité en termes d'ergo et d'esthétique. Même si je ne suis pas codeur et ou même intégrateur/webmaster, ça m'emmerde de ne pas pouvoir avoir un peu plus de place pour le créatif.

Reprise d'un truc sur Hubspot : pourquoi ça ?