Reprise du message précédent :

Merci, j'ai compris.
 
Il faut regarder le Viewport Size  
https://yesviz.com/viewport/
 
J'ai un site où on affiche des images en 320 px de large sur smartphone.  
Mais ça ne parait plus du tout adapté aux tailles actuelles. J'ai donc des affichages bien crados.
 
Il faudrait le passer à 440px, vu que ça semble le max d'aujourd'hui.

Il faut essayer de ne plus trop raisonner en pixels. Tu ne peux pas partir du principe que tu pourras afficher des pixels parfaitement pour chaque smartphone/tablette/ordinateur/...
Donc pour une image comme la une du monde, ils vont définir des groupes de tailles en fonction des résolutions des devices. Donc tu vas faire un groupe pour tout ce qui est smartphones et utliser une image en réalité bien plus grosse (par exemple 1500x1000 pixels et l'afficher à 100% de largeur pour tous les devices qui ont un viewport < 500px (par exemple).
 
Pour ça apprend ce que sont les "media queries" en CSS
 
Nota : les usages sont différents aussi, sur smartphone tu vas souvent faire du pinch zoom, donc c'est pas idiot d'avoir une image avec une résolution assez grosse même si on l'affiche initialement de manière assez petite. A l'inverse sur un navigateur sur PC, on peut être plus proche genre si on prévoit un espace qui fera de l'ordre de 500px de large, alors utiliser une image de 500px est plutôt cohérent.
Tu vas aussi découvrir le monde fabuleux des Mac à écran retina, qui aimeraient bien qu'on leur donne (toujours dans ce genre de situation) une image 2x plus grande que l'espace prévu.
Des heures d'émerveillement en vue.
et ton bête <img src="toto.jpg"> va se transformer en balise picture avec 5 cas différents + 20 lignes de media queries

Ou alors on s'emmerde pas trop parce que c'est vite lourd à gérer, et on utilise du Webp à 2x, ça prend pas trop de ressources, et ça sera aussi bien sur desktop que sur mobile (les iPhones sont plus proches du 3x que du 2x).
Avez le lazy load c'est assez économe en regard du temps passé à générer les images adéquats et le code source plus lourd.

Un article sur le sujet des images web lors d'un gros projet mené dans une de mes précédentes équipes : https://tech.decitre.fr/posts/refon [...] generation
 
Ca parle notamment de la gestion des écrans à haute densité (mais pas que ).

 
Super intéressant merci

Et depuis le webp est massivement développé, il est probable qu'on puisse carrément dégager le jpeg

au mieux si tes pages sont générées ou dynamique tu peux créer une fonction/composant "image" qui te génère un tag image avec différents srcset et yolo
le webp c'est la vie

This

jpg, webp, tout ça c'est trop lourd, le top c'est les visuels en svg...

moi j'attends avec hâte que tout le monde supporte l'avif pour gratter encore un peu

Alors j'avais tenté un max les SVG, mais parfois, ben le SVG qu'on te file en fait il contient un PNG en base64 dedans, donc tu as plus vite fait de faire du webp

Edit : et je vois pas de quoi tu vois de bien conçu, le truc a une build un peu pourrave

Vous parlez de logos non ?

Pour un site "static", c'est rudement bien fait et facile à mettre à jour, un de mes trucs préféré c'est l'ajout de svg dans un dossier qui intègre ça une typo avec la css qui vas bien pour faire des .icon-nom-du-fichier-svg.
Mais y'a plein d'autres trucs facile, la génération des images auto, les liens vers les pdf qui prennent le contenu de la page, et bien sur tout ce qui est component réutilisable auquel on prend vite gout.
 

@Plamcorp la majorité des visuel du site sont de vrai svg, le logo dans le header c’est encore mieux, c'est le nom de la boite avec la typo, on peut difficilement faire plus léger.  

On peut, tout en pur CSS, interdiction d’utiliser les background-image et mask-image, par contre t’as le droit d’utiliser les animations et pseudos-elements. Voilà

De mémoire j'avais quelques SVG que j'avais essayé de réduire avec oMG SVG et aussi j'avais fait un comparer avec webp et le webp était plus léger que le SVG

 
Bah tout dépend de la complexité du SVG. Tu as des SVG qui contiennent même du raster, et aussi des vectorisations d'images raster qui sont tellement complexes qu'elles en deviennent plus lourd que l'image originale. Mais pour des images simples à base de figures géométriques avec très peu de nodes, le SVG est absolument imbattable. Avec le SVG, tu peux aussi mettre des backgrounds complexes avec des dégradés etc...

Oui j'ai mal formulé la phrase, je voulais dire que j'ai quelques SVG complexes qui au final en WebP étaient plus petit.  
Mais on est dans des cas extrêmes.

Hello
Je suis en train de mettre en place un système de monitoring sur les sites de mes clients.
(Ça peut être du WP, du PS, du custom...)

2 méthodes (dans chaque sens)

1 - Mon tableau de bord qui va se connecter (via cURL ou autre méthode) à chaque site, récup les infos et enregistrer tout ça
2 - Chaque site qui va régulièrement (via un cron) envoyer de la data sur un endpoint de mon tableau de bord

J'hésite :

1 -
   Pro : Implémentation unique au sein de mon tableau de bord
   Cons : je peux pas récupérer toutes les infos (version des plugins, etc..)

2 -
 Pro : je peux envoyer toutes les infos (versions du serveur / plugins), et ce même si c'est sur un réseau interne (requête sortante)
 Cons : nécessité de mettre cette fonctionnalité sur chaque site

Quelle approche vous prendriez

1 & 2 en même temps.
Le cron ne sera pas toujours simple à mettre en oeuvre au niveau de 2, donc je penses qu'il vaux mieux que la demande de donnée se fasse par 1.
Par contre il est obligatoire d'avoir un script au niveau de 2 qui vas chercher les informations pertinente, tu te prépares un script que tu poses à la racine (ou dans un dossier un peu caché) et qui parse les fichier de config pour avoir accès à la bdd, pour WP ça peut même être un plugin qui écoute une url et sort un json...
 
Par contre sécurise le bien ton script !

Je vois pas trop en quoi l'option 1 est limitative sur les informations renvoyées. Tu peux expliquer ?

Vous conseillerez quoi comme CMS Opensource, gratuit et minimaliste/lowtech? Un CMS qui consomme le moins de ressource. Qu'est-ce qui est le plus utilisé en ce moment? Je dois m'orienter vers un CMS flat file je supppose? merci

Tu veux faire quoi exactement?

Je ne peux pas récupérer via des simples requêtes http les infos serveur facilement, et même si je peux parser sans problème la liste des extensions et deviner les versions de chaque module + noyau du CMS, ça reste relativement "light".
Je ne peux pas non plus checker des sites qui ne sont pas accessibles de l'extérieur.

C'est ce que je pense faire au final, la solution 2, chaque site aura sa propre clef d'API, et pour les sites non accessibles de l'extérieur, un cron sera mis en place pour exécuter le script et envoyer les infos.

Pour ton premier point, ça dépend ce que tu interroges. Par exemple, si t'as un script qui te fait un phpinfo(), t'auras bien des infos serveur. Tu peux très bien te faire un script custom qui répond ce que tu veux (dans un format à définir).
 
Pour le second point, effectivement, c'est bloquant dans ce sens là.

Attention au phpinfo(), genre ne pas faire un phpinfo.php à la racine du site qui fait phpinfo() dedans.
- si l'url du fichier est évidente à tester elle sera testée par de scripts/bots qui scannent le web en permanence
- dedans tu as plein d'infos qui peuvent servir à savoir si ton serveur est vulnérable (telle version de telle extension avec une vuln connue)
- nettement pire, si tu utilises des variables d'environnement pour passer des trucs genre mots de passe, clés, ... elles seront affichées en clair dans le phpinfo().
 
Après, perso je préfère l'approche 1, parce que sur certaines plateformes mettre en place un cron n'est pas forcément possible et tu peux varier le degré d'infos, parfois un simple ping est suffisant, parfois tu fais un curl et tu t'assures que tu récupères bien quelques détails du footer, ce qui suffit à te dire que le site est globalement ok, parfois tu peux aller plus loin avec du code spécifique hébergé sur le site en question. Mais si tu as des sites non accessibles depuis l'extérieur c'est mort.
Donc j'imagine que la bonne réponse c'est de prévoir les 2 cas.
En solution 1, rien ne t'empêche de prévoir par exemple un fichier php type, avec les sécurités que tu veux (passage de clé dans l'appel https typiquement), à héberger sur la majorité des sites et qui te génère un joli json avec les infos que tu veux.
Tu parses, et tu stockes en bdd locale
 
Pour les sites non accessibles depuis l'extérieur tu fais l'inverse, en push vers chez toi, en essayant d'avoir une structure identique, genre ça te pushe le même json que ce que tu récupères en pull.

Hello. J'espère être au bon endroit pour poser ma question.

Je suis en train de coder une petite appli Web en node/js avec une partie des data qui passe par websocket.

Je me demande si pour l'autre partie des data qui n'a pas forcément besoin de passer en websocket, il serait mieux en termes de performances et de charge sur le serveur de rester en websocket ou de faire des appels http "classiques".
J'ai compris que le websocket est un peu plus lourd parce qu'il garde une connexion ouverte en permanence. Mais une fois qu'il est ouvert, est ce que c'est pas plus léger de tout faire passer par là, plutôt que de rouvrir des connexions http classiques ?

Merci pour vos éclairages

on en fait pas mal  
les websockets sont bien performantes mais un peu pénible pour les connexion fragiles
 
si par contre tu dois envoyer des fichiers => fais le par HTTP

vous faites du websocket avec socket.io ? c'est pas mal d'avoir une lib qui gere des failback

Oui là je suis parti sur socket.io
Effectivement il a plein de méthodes pour se reconnecter ou pour gérer les navigateurs qui veulent/peuvent pas gérer les websocket. (c'est peut être plus rare qu'il y a quelques années)

 
non natif
le fallback n'est vraiment plus utile depuis 10 ans

il peut arriver que des réseaux bloquent les websockets (cas de ma boite dans certains contextes)

En 2025, on a quoi comme solution pour garder un utilisateur connecté à une webapp ?
Toujours les cookies ?
Je pensais au LocalStorage, mais c'est pas hyper secure, Webkit a une durée de rétention fixe, et sans parler que tous les scripts y ont accès...

Cookie httpOnly avec flag Secure (que sur HTTPS). Le mieux étant de laisser faire une vraie stack, surtout si tu as de l'oauth derrière.

Mon site est open !
Les CGI sont fonctionnelles !
Le résulta efficient !
Les tarifs sont indiqués.
 
Si vous avez du taf, j'ai du temps de libre !

le nombre de phauttes d'aurtaugrafe sur ton cite est allussinant

 
Ouais ; Mais t'es intelligent !  0 = 0.  

D'autant plus que c'est un site dont l'equipe formées de professionnels de la communication et du commerce proclame :  
" Riches de notre usage francophone des expressions et locutions du langage de France, nous pouvons éventuellement concevoir ou améliorer vos messages. "
Faudrait commencer par le site

Vous vous souvenez de notre copain "développeur" ?
Bah à plus je creuse pour modéliser la nouvelle appli (j'ai tout brûlé, pas moyen que je garde un truc de l'existant ), à plus j'ai des surprises.
 
Comme là, dans la même table, 2 champs date.
Bah le mec s'est dit que c'était bien de stocker les dates dans un format différent.

 
 

J’aime bien le “/“ avec un ordre YMD, mais le “-“ (généralement utilisé pour le format ISO-8601) en DMY