Quelqu’un a-t-il remarqué quelque chose d’étrange lorsque l’aperçu ci-dessus s’est chargé sur l’écran de votre téléphone portable ?
Pourquoi l’image a-t-elle mis si longtemps à remplir complètement le carré d’aperçu ?
C’est parce que c’est une très grande image !
Alors pourquoi une très grande image doit-elle engloutir le forfait de données de l’utilisateur, prendre autant de temps alors qu’un tout petit aperçu serait apparu avant même que vous ne le remarquiez ?
Non, je ne suis pas tout à fait sûr de qui blâmer.
Non. Ce n’est pas un bug. L’image arrive plus tôt ou plus tard. Je dis juste que c’est une mauvaise expérience utilisateur. L’utilisateur pense que personne ne se soucie de son forfait de données, et la page ne se charge pas aussi rapidement que les autres pages.
Pas si vite. Vous, dans votre tour d’ivoire dans votre pays du premier monde, ne feriez jamais la différence. Mais moi, dans ma tour non d’ivoire, dans mon pays non du premier monde, je remarque très bien la différence !
Utilisez les outils de développement, définissez le pays sur deuxième ou troisième monde, , désactivez le cache et rechargez la page.
Votre plainte concerne donc votre FAI et son peering ?
Pour être clair, l’image originale fait 3,4 Mo, cette miniature est servie par Cloudfront, mesure 690x460 et pèse 164 Ko.
Quoi qu’il en soit, que proposez-vous ? Que Cloudfront soit un mauvais CDN pour les utilisateurs de votre région ? Que Discourse n’ait pas téléchargé et créé les images optimisées assez rapidement ?
Dans votre pays non-tour d’ivoire où les données coûtent 8 fois moins cher qu’aux États-Unis et sont encore 2,5 fois moins chères qu’en Europe ? (source) ou voulez-vous dire dans votre pays non-tour d’ivoire avec l’Internet haut débit le plus rapide au monde (source) ? Ou peut-être vouliez-vous dire votre pays non-tour d’ivoire qui, pour les données mobiles, se classe toujours 28ème, bien au-dessus de nombreux pays du premier monde ? (source)
On dirait que vous avez juste besoin d’un téléphone plus grand.
À en juger par les publications précédentes, Jidanni possède un Galaxy A13 5G et un Zenfone 3 :
Galaxy A13 5G : 6,5 pouces, 1600 x 720
Asus Zenfone 3 : 5,5 pouces, 1920 x 1080
Comme la miniature optimisée est de 690x460, et que ses dimensions sont encore plus restreintes par la onebox, elle n’est pas plus grande que leur écran. Ils utilisent cependant la mise à l’échelle du navigateur, donc qui sait
Je me trompe peut-être, mais je pense que cela a du sens.
Si vous regardez le srcset HTML, les images suivantes sont servies en fonction du rapport de pixels de l’appareil (x1, x1,5, x2).
Habituellement, les mobiles ont un rapport x2 (ou plus) car ils ont une densité de pixels plus élevée.
Vous voudrez donc servir des images avec une résolution plus élevée.
Rapport de pixels de l'appareil
Le rapport de pixels de l’appareil (DPR) est un nombre donné par les fabricants d’appareils et il est utilisé pour les écrans HiDPI (High Dots Per Inch) ou Retina (marque déposée d’Apple), qui font partie des smartphones, tablettes et même certains ordinateurs portables et moniteurs modernes.
Le DPR est en corrélation directe avec la densité de pixels de l’écran, plus la densité est élevée, plus la valeur du DPR est grande.
Le DPR est le rapport entre les pixels physiques (de l’appareil) et les pixels logiques (CSS) dans la direction horizontale (largeur) ou verticale (hauteur) d’un écran.
En d’autres termes, le DPR est un nombre utilisé pour calculer la résolution CSS de l’écran. À partir du DPR, nous pouvons voir directement combien de pixels matériels réels composent un pixel CSS.
Exemple :
Apple iPhone 12
Résolution en pixels de l’appareil (physiques) : 1170 x 2532
DPR : 3
Largeur : 1170/3 = 390, Hauteur : 2532/3 = 844
Par conséquent, résolution en pixels CSS : 390 x 844
Puisque le DPR est de 3, dans la grille de pixels : 3 (largeur) x 3 (hauteur) = 9 ; 9 pixels physiques sont utilisés pour former un pixel CSS.
oui, je ne pense pas que ce soit un bug. mon iPad en vue mobile charge des photos haute résolution que mon ordinateur de bureau car il le peut. je pourrais me tromper, mais j’ai cru comprendre que cela dépend des capacités de l’appareil, et non de la taille de l’écran.
De plus, je ne sais toujours pas si ce sujet concerne la miniature de la boîte unique elle-même ou la photo réelle qui se charge lorsque vous cliquez sur le lien de la boîte unique ?
Vous ne remarquerez probablement pas une image de résolution inférieure sur les smartphones en raison de la taille de leur écran, et je pense qu’en général, ils sont plus susceptibles d’avoir une connexion Internet plus lente via le réseau mobile qu’une connexion Internet domestique. À cet égard, je ne m’attendrais pas à ce qu’une expérience mobile charge une image plus grande que sur un ordinateur de bureau.
Mais scrset dicte quelle image charger pour quel ratio de pixels.
Ce n’est certainement pas un bug, je vais le déplacer vers UX
Oui, nous parlons d’une miniature de 500 kilo-octets.
Que penserait Tim Berners-Lee ?
Okay, j’ai fait une recherche sur le web et en effet, c’est une taille raisonnable pour une miniature – si vous l’envoyez sur YouTube.
Je veux dire, ça doit être une miniature holographique fantastique en 50 dimensions ou quelque chose comme ça. Êtes-vous sûr de ne pas pouvoir faire la même chose avec environ 5000 octets ? L’utilisateur pourrait-il détecter une différence ? Non, je ne blâme personne pour la crise énergétique ou le ralentissement du web. Je pense juste qu’avec une destination étant un petit téléphone portable, quelque chose pourrait être amélioré.
Je veux dire, il doit y avoir un point où le simple ajout d’octets supplémentaires, quel que soit l’appareil de la taille d’un téléphone portable, ne fera aucune différence pour les êtres humains, à moins qu’ils n’aient des yeux d’aigle, mais ce ne sont pas des aigles, ce sont des humains.
Je suis d’accord, quelque chose ne va pas, c’est sûr… cette image est beaucoup trop grande. Notre implémentation onebox demande une image surdimensionnée alors qu’une beaucoup plus petite suffirait.
Nous allons examiner cela au cours du mois prochain environ.