Publier un ZIP HTML en site web en ligne

Un site compressé se trouve dans un état étrange, entre les deux : il est terminé, mais enfermé dans un fichier. Envoyer le ZIP par e-mail oblige le destinataire à le télécharger, le décompresser, chercher l'index.html et l'ouvrir en local, où la moitié des liens risquent de casser, car ils ont été écrits pour un serveur web. Publier le ZIP évite tout cela. Importez-le une fois et vous obtenez un lien qui ouvre le vrai site, navigable, dans le navigateur de n'importe qui, sans téléchargement ni décompression. C'est la différence entre envoyer un site web à quelqu'un et lui envoyer une URL.

Les ZIP créés sur de vrais ordinateurs sont rarement bien rangés. Compressez un dossier sur Mac et vous obtenez un dossier __MACOSX caché et des fichiers .DS_Store ; sous Windows, vous obtenez souvent un seul dossier englobant portant le nom du dossier d'origine. Nous gérons les deux cas discrètement, en ignorant ces métadonnées inutiles et en regardant au-delà d'un dossier englobant unique pour servir depuis la vraie racine de votre site. Vous n'avez pas besoin de recompresser vos fichiers d'une façon particulière ni d'aplatir vos dossiers au préalable. Compressez votre site comme vous le faites d'habitude, et cela fonctionne tout simplement.

Ce n'est pas un aperçu à fichier unique, c'est un site multipage. Votre index.html peut créer un lien vers about.html et contact.html, ces pages peuvent partager un dossier /css et charger des images depuis /images, et tout se résout correctement car nous préservons votre structure et servons depuis la propre racine de votre site. Une feuille de style à assets/site.css, un script à js/app.js, une image à images/hero.jpg, chacun se charge avec le bon type, si bien que la page a exactement l'apparence et le comportement que vous avez construits.

Le lien par défaut fonctionne partout, mais pour tout ce qui est public, vous voudrez qu'il porte votre propre nom. Connectez un domaine ou un sous-domaine et nous configurons le HTTPS automatiquement, si bien que le site s'affiche comme le vôtre dans la barre d'adresse. Chaque offre inclut aussi un lien personnalisé et lisible, ainsi qu'un mot de passe et une date d'expiration lorsque vous partagez quelque chose qui ne devrait pas être grand ouvert. Un site d'événement hébergé, un support de cours, une page de petite entreprise, une documentation, tout cela en ligne sur une URL que vous contrôlez.

La version que vous avez partagée est rarement la dernière. Plutôt que de créer une nouvelle URL à chaque fois que vous corrigez une faute de frappe ou ajoutez une page, et laisser l'ancien lien mort dans la boîte de réception de quelqu'un, vous importez simplement un nouveau ZIP. La même adresse diffuse le site mis à jour, si bien que chaque lien déjà distribué continue de fonctionner et affiche simplement le contenu le plus récent. Pas d'étape de redéploiement, pas de git, pas de serveur de build : remplacer le ZIP remplace le site.

Votre site est servi sous forme de fichiers statiques avec le bon type de contenu, depuis son propre espace isolé, son JavaScript s'exécute donc dans son propre univers et ne peut pas atteindre l'application qui l'entoure. Nous n'exécutons jamais de code côté serveur, et nous refusons les exécutables et scripts qui n'ont rien à faire dans un site web, en vérifiant chaque fichier par ses octets réels plutôt qu'en faisant confiance au ZIP. Cela garde l'hébergement sûr pour vous et pour les visiteurs. La limite honnête est le revers de cette sécurité : si votre site a besoin d'un backend, d'une base de données ou de pages rendues côté serveur, l'hébergement statique n'est pas le bon outil, apportez des fichiers statiques déjà construits, et cela conviendra parfaitement.