#19102

Optimiser et accélérer les pages web - lehollandaisvolant.net

J’ai mis à jour cette page.

J’ai ajouté :

L’utilisation du CSS font-display pour les polices d’écriture.
Il gère la façon dont le le navigateur affiche/attend le chargement de la police.
C’est à cause de ça que, parfois, les pages affichent un texte vide tant que la police n’est pas chargée.

On peut contrôler ça :

font-display: fallback;

réduit à 100 ms le temps d’attente avec le premier affichage de texte. Si la police est chargée, elle l’utilise ; sinon, elle utilise la police fallback (une police système de préférence). Pour le corps du texte, c’est ce qu’il y a de mieux.

font-display: block;

force l’attente du chargement de la police. C’est utile si vous utilisez les webfont pour vos icônes. Sans ces polices, les icônes ne s’affichent pas et aucune police système ne les remplacera. Il faut donc l’attendre.

D’autres valeurs sont possible, voyez là.

L’utilisation des src-set pour les images.

Cela permet de dire au navigateur quelle image charger pour quel taille d’écran. Ça oblige d’avoir plusieurs tailles de chaque image sur le serveur, mais ça évite à un mobile en 3G de charger image en 4K de 3 Mo là où une image de 640px suffit.

Bien-sûr, si la taille de l’écran change, il peut arriver que ça fait plus de données à afficher. Mais soyons sérieux : est-ce que vous changez souvent la taille de votre écran/fenêtre ? Et sur mobile, passez-vous toute la journée de paysage à portrait et inversement ?

L’ajout de l’attribut loading sur les images.
C’est le projet du lazyload natif en HTML. Ajoutez juste ça sur vos images et iframes :

<img src="" alt="" loading="lazy" />

Ce n’est pas encore supporté partout, juste sur Chrome/Opera, mais c’est en bonne voie et il ne faut pas s’en priver.

https://lehollandaisvolant.net/tuto/pagespd/

#18643

Everything You Ever Wanted to Know About inputmode | CSS-Tricks

Oh !!

L’attribut « inputmode » permet de choisir quel clavier sera affiché (surtout pour mobile et claviers virtuels) : clavier alphanumérique, clavier téléphonique, numérique, décimal…

C’est similaire à mettre « type="numeric" » ou « type="email" » (au lieu de « type="text" »), sauf que inputmode ne modifie que le clavier, pas ce qu’on tape avec.
On peut donc très entrer « bonjour » dans un champ avec « inputmode="email" » : ça sera valide, car ça reste un type text.

Aussi, il est possible (à tester) que le navigateur ne modifie pas le design du champ (par exemple Safari ou Chrome utilisent un champ/bouton spécifique pour les champs de type="search", ce qui est très chiant parfois).

https://css-tricks.com/everything-you-ever-wanted-to-know-about-inputmode/

#18640

Note : astuce d’accessibilité en HTML

Quand on mettez un texte alternatif sur les images (attribut « alt ») ou les vidéos (directement dans l’élément <video></video>), mettez une phrase : avec une majuscule et un point.

Comme ça, les lecteurs d’écrans vont lire ça correctement, et pas juste comme 2 ou 3 mots sortis de nulle part.

(Bien-sûr, pour ça faut déjà mettre un texte alternatif à la base, n’est-ce pas ¬_¬.)

https://lehollandaisvolant.net/?mode=links&id=20190521231649

#17957

Timo sur Twitter : "Et si je transformais mes outils (https://t.co/jSVtwXWTTy) en webapps ?"

Bon, Timo vient de trouver comment faire des PWA, des « progressives web app ».

En gros, ce sont des pages web qui sont mis en cache sur le téléphone (ou l’ordinateur, hein). C’est donc à la limite entre la page web et l’application.

L’intérêt est multiple :
– la partie mise en cache se lance instantanément (elle est déjà sur le tél), seule est chargée la partie dynamique. Pour un blog, par exemple, les menus sont statiques et les articles sont chargés. Ça limite ainsi le transfert de données.
– la partie mise en cache est utilisable offline !
– la page est en plein écran
– c’est toujours juste du JS/HTML/CSS, donc a priori cross-browser
– c’est exécuté dans le navigateur (celui que vous voulez, du moment qu’il a un bon support des technos).

On peut imaginer un fichier HTML/CSS reprenant l’interface de votre blog, et un petit bout de JS/CSS qui récupère un flux RSS/ATOM (ou même les flux en JSON, qui sont destinés à ça). Et hop, on a une application mobile en 15 minutes.
Il y a possibilité de stoquer les données également dans un cache local.

Pour les outils web qui fonctionnent entièrement en JS (vous me voyez venir ?), il y a possibilité d’en faire assez simplement des PWA !

Je viens de commettre ça du coup : https://lehollandaisvolant.net/TEST/WEBAPPS/noteswall

C’est mon mur de notes en JS !

1) visitez la page dans votre smartphone
2) dans Firefox mobile, vous cliquez sur la petite maison dans la barre d’adresse : ça va l’ajoute au bureau, comme une app (sinon allez dans le menu > page > ajouter sur la page d’accueil)
3) c’est bon, c’est installé : online, offline : ça marche !

Pour la virer, virez juste l’icône.

Cette app en particulier est totalement offline.
Aucune requête n’est jamais faite sur mon site (sauf au moment de l’installer). Donc vos notes sont safe ^^

Oh et l’app reste parfaitement utilisable telle qu’elle dans un navigateur desktop : c’est juste une page web mise en cache, un peu plus durement que d’habitude.

Mon mur de notes est très simple et basique comme app (même pour un mur de notes). Mais les possibilités sont immenses ! J’hésitais a apprendre à faire des app android. En fait je vais apprendre mon JS et faire ça. Au moins je saurais faire des app pour toutes les plateformes en même temps

Je sens que je vais m’amuser \o/

(oui je suis un gosse qui vient de découvrir comment marcher :D)

https://twitter.com/lehollandaisv/status/1065710442650247168

#17750

Don't Use Checkboxes

+1.

Si le titre est un peu fort, il donne de bons exemples de mauvais emplois des checkbox.

Si vraiment l’usage d’une checkbox pour ces exemples n’est pas évitable, on peut phraser ça autrement : « sort names by last names instead of first name [_] ». Tout est une question de formulation. Comme ça on sait quel est le comportement par défaut.

https://www.teamten.com/lawrence/programming/checkboxes/

#17648

The Bullshit Web — Pixel Envy

À lire, pour ceux qui font des sites web.

Given the assumption that any additional bandwidth offered to web developers will immediately be consumed, there seems to be just one possible solution, which is to reduce the amount of bytes that are transmitted. For some bizarre reason, this hasn’t happened on the main web, because it somehow makes more sense to create an exact copy of every page on their site that is expressly designed for speed. Welcome back, WAP — except, for some reason, this mobile-centric copy is entirely dependent on yet more bytes. This is the dumbfoundingly dumb premise of AMP.

Haha, oui, c’est totalement ça : AMP, le truc de Google pour pister tout le mo… accélérer les pages web, c’est :
– 80 ko de JS
– pour afficher du HTML
– dans une mise en page minimale et moche

(Là où juste du HTML et ~15 lignes de CSS suffisent pour faire quelque chose de joli).

https://pxlnv.com/blog/bullshit-web/

#17630

Why You Shouldn't Use A Web Framework - DEV Community 👩‍💻👨‍💻

It's easier for beginners to use a framework

Sure, if you're a Sith.

Déjà que JS lui même vient, de base dans les navigateurs, avec une panoplie énorme de fonctionnalités, donc les 3/4 ne seront jamais utilisés dans quelque programme que ce soit, alors ajoute une sur-couche pour reformuler toutes ces fonctions de façon différente, à quoi bon ?

https://dev.to/gypsydave5/why-you-shouldnt-use-a-web-framework-3g24

#17373

What’s wrong with CSS-in-JS? | Brad Frost

J'ai jamais été fan du full-CSS-in-JS, et je rejoins ce que disait Daniel Glazman ici : les arguments généralement invoqués pour dire "non au CSS" ne tiennent juste pas debout et tendent même plutôt à démontrer que CSS a de bon nombre de points communs avec des langages de programmation !

Le mieux quand on vient se greffer sur un projet déjà existant c'est évidement de respecter la structure de l'existant, mais s'il est nécessaire de tout recommencer ou de créer un truc nouveau, je préfère utiliser les différentes techno pour ce qu'elles ont été prévues :

- HTML pour le code source de la page et le contenu
- CSS pour la décoration
- JS pour l'interaction et l'interface .

On peut utiliser JS pour modifier le CSS ou le HTML, mais généralement c'est à éviter.
Quand il faut modifier ce qui s'affiche à l'écran, je ne touche pas aux éléments HTML : je fais switcher des classes et je laisse le CSS faire le reste.

Ça me semble être la solution la plus propre : sans CSS le HTML s'affiche et le contenu est visible, et sans JS aussi, donc le contenu reste accessible. Ce n'est pas toujours la solution la plus légère par contre...

http://bradfrost.com/blog/link/whats-wrong-with-css-in-js/

#16980

The HTML Hell Page

Une énorme page comme mon top : « You Know You're In Design Hell When You See... ».

http://catb.org/esr/html-hell.html