Les applications Web progressives (PWAS) essaient de chevaucher les mondes des applications Web mobiles et des applications mobiles natives en offrant les meilleures fonctionnalités de chacun aux utilisateurs mobiles.
Ils offrent une expérience utilisateur en forme d'application (écrans d'éclaboussure et icônes d'écran d'accueil), ils sont servis à partir de serveurs sécurisés HTTP Conditions, et ils ont un support hors ligne, un chargement instantané et des notifications push. Le concept de PWAS a été introduit pour la première fois par Google, et est toujours pris en charge par de nombreuses fonctionnalités chromées et d'excellents outils, tels que Lighthouse, un outil open-source pour l'accessibilité, les performances et l'audit de la progressivité que nous examinerons un peu plus tard.
Tout au long de ce cours intensif, nous construirons un PWA à partir de zéro avec ES6 et réagirons et l'optimiserons étape par étape avec Lighthouse jusqu'à ce que nous obtenions les meilleurs résultats en termes d'UX et de performances.
Le terme progressif signifie simplement que les PWA sont conçus d'une manière telle qu'ils peuvent être progressivement améliorés dans les navigateurs modernes où de nombreuses nouvelles fonctionnalités et technologies sont déjà prises en charge, mais devraient également fonctionner bien dans les anciens navigateurs avec Aucune fonctionnalité de pointe.
Une application native est distribuable et téléchargeable à partir de l'App Store respectif du système d'exploitation mobile. Les applications Web mobiles, en revanche, sont accessibles à partir d'un navigateur Web en entrant simplement leur adresse ou URL. Du point de vue de l'utilisateur, le lancement d'un navigateur et la navigation vers une adresse est beaucoup plus pratique que d'aller sur l'App Store et de télécharger, d'installer, puis de lancer l'application. Du point de vue du développeur / propriétaire, payer des frais uniques pour obtenir un compte App Store, puis télécharger leurs applications pour devenir accessible aux utilisateurs du monde entier est mieux que d'avoir à gérer les complexités de l'hébergement Web.
Une application native peut être utilisée hors ligne. Dans le cas des données distantes qui doivent être récupérées à partir d'un serveur API, l'application peut être facilement conçue pour prendre en charge une sorte de mise en cache SQLite des dernières données accessibles.
Une application Web mobile est indexable par des moteurs de recherche comme Google, et grâce à l'optimisation des moteurs de recherche, vous pouvez atteindre plus d'utilisateurs. Cela est également vrai pour les applications natives, car les magasins d'applications ont leurs propres moteurs de recherche où les développeurs peuvent appliquer différentes techniques - communément appelées optimisation de l'App Store - pour atteindre plus d'utilisateurs.
Une application native se charge instantanément, au moins avec un écran d'éclaboussures, jusqu'à ce que toutes les ressources soient prêtes à exécuter l'application.
Ce sont les différences perçues les plus importantes. Chaque approche de la distribution des applications présente des avantages pour l'utilisateur final (concernant l'expérience utilisateur, la disponibilité, etc.) et le propriétaire de l'application (concernant les coûts, la portée des clients, etc.). En prenant cela en considération, Google a introduit les PWA pour apporter les meilleures fonctionnalités de chaque côté dans un concept. Ces aspects sont résumés dans cette liste introduite par Alex Russell, un ingénieur Google Chrome. (Source: rarement noté.)
Lighthouse est un outil pour auditer les applications Web créées par Google. Il est intégré aux outils Chrome Dev et peut être déclenché à partir du panneau Audits.
Vous pouvez également utiliser le phare comme un outil CLI Nodejs:
<span>npm install -g lighthouse </span>
Vous pouvez ensuite l'exécuter avec:
lighthouse https://sitepoint.com/
Lighthouse peut également être installé comme une extension chromée, mais Google recommande d'utiliser la version intégrée à Devtools et d'utiliser l'extension si vous ne pouvez pas utiliser les Devtools.
Veuillez noter que vous devez faire installer Chrome sur votre système pour pouvoir utiliser le phare, même si vous utilisez la version basée sur la CLI.
Dans cette section, nous créerons une application Web progressive à partir de zéro. Tout d'abord, nous créerons une application Web simple à l'aide de l'API de React et Reddit. Ensuite, nous ajouterons des fonctionnalités PWA en suivant les instructions fournies par le rapport du phare.
Veuillez noter que l'API Reddit public sans authentification a activé les en-têtes CORS afin que vous puissiez le consommer à partir de votre application côté client sans serveur intermédiaire.
Avant de commencer, ce cours supposera que vous avez une configuration d'environnement de développement avec NodeJS et NPM installé. Si vous ne le faites pas, commencez par la propriété Impressionnée Improved, qui exécute les dernières versions de chacun et est prête pour le développement et les tests hors de la boîte.
Nous commençons par installer Create React App, un chauffeur de projet créé par l'équipe React qui vous sauve des tracas de la configuration de WebPack.
<span>npm install -g lighthouse </span>
Le shell d'application est un concept essentiel d'applications Web progressives. C'est simplement le code HTML, CSS et JavaScript minimal responsable de l'interface utilisateur.
Ce shell d'application présente de nombreux avantages pour les performances. Vous pouvez mettre en cache le shell d'application afin que lorsque les utilisateurs visitent votre application la prochaine fois, il sera chargé instantanément car le navigateur n'a pas besoin de récupérer des actifs à partir d'un serveur distant.
Pour construire une interface utilisateur simple, nous utiliserons l'interface utilisateur de matériaux, une implémentation de Google Material Design in React.
Installons le package à partir de NPM:
lighthouse https://sitepoint.com/
Ouvrez ensuite src / app.js puis ajoutez:
<span>npm install -g create-react-app </span>create-react-app react-pwa <span>cd react-pwa/ </span>
Ensuite, nous devons récupérer les articles Reddit en utilisant deux méthodes fetchFirst () et fetchNext ():
<span>npm install material-ui --save </span>
Vous pouvez trouver le code source dans ce référentiel GitHub.
Avant de pouvoir exécuter des audits par rapport à votre application, vous devrez créer une version et servir votre application localement à l'aide d'un serveur local:
<span>import <span>React, { Component }</span> from 'react';
</span><span>import <span>MuiThemeProvider</span> from 'material-ui/styles/MuiThemeProvider';
</span><span>import <span>AppBar</span> from 'material-ui/AppBar';
</span><span>import <span>{Card, CardActions, CardHeader,CardTitle,CardText}</span> from 'material-ui/Card';
</span><span>import <span>FlatButton</span> from 'material-ui/FlatButton';
</span><span>import <span>IconButton</span> from 'material-ui/IconButton';
</span><span>import <span>NavigationClose</span> from 'material-ui/svg-icons/navigation/close';
</span>
<span>import logo from './logo.svg';
</span><span>import './App.css';
</span>
<span>class App extends Component {
</span>
<span>constructor(props) {
</span> <span>super(props);
</span>
<span>this.state = {
</span> <span>posts: []
</span> <span>};
</span> <span>}
</span>
<span>render() {
</span> <span>return (
</span>
<span><MuiThemeProvider>
</span> <span><div>
</span> <span><AppBar
</span> title<span>={<span >React PWA</span>}
</span>
iconElementLeft<span>={<IconButton><NavigationClose /></IconButton>}
</span> iconElementRight<span>={<FlatButton onClick={() => this.fetchNext('reactjs', this.state.lastPostName)} label="next" />
</span> <span>}
</span> <span>/>
</span>
<span>{this.state.posts.map(function (el<span>, index</span>) {
</span> <span>return <Card key={index}>
</span> <span><CardHeader
</span> title<span>={el.data.title}
</span>
subtitle<span>={el.data.author}
</span> actAsExpander<span>={el.data.is_self === true}
</span> showExpandableButton<span>={false}
</span> <span>/>
</span>
<span><CardText expandable={el.data.is_self === true}>
</span> <span>{el.data.selftext}
</span> <span></CardText>
</span> <span><CardActions>
</span> <span><FlatButton label="View" onClick={() => {
</span> <span>window.open(el.data.url);
</span> <span>}} />
</span>
<span></CardActions>
</span> <span></Card>
</span> <span>})}
</span>
<span><FlatButton onClick={() => this.fetchNext('reactjs', this.state.lastPostName)} label="next" />
</span> <span></div>
</span> <span></MuiThemeProvider>
</span>
<span>);
</span> <span>}
</span><span>}
</span>
<span>export default App;
</span>Cette commande invoque le script de construction dans package.json et produit une version dans le dossier react-pwa / build.
Vous pouvez maintenant utiliser n'importe quel serveur local pour servir votre application. Sur Homestead Amélioration, vous pouvez simplement pointer l'hôte virtuel Nginx dans le dossier de construction et ouvrir Homestead.app dans le navigateur, ou vous pouvez utiliser le package de service via Nodejs:
<span>fetchFirst(url) {
</span> <span>var that = this;
</span> <span>if (url) {
</span> <span>fetch('https://www.reddit.com/r/' + url + '.json').then(function (response) {
</span> <span>return response.json();
</span> <span>}).then(function (result) {
</span>
that<span>.setState({ posts: result.data.children, lastPostName: result.data.children[result.data.children.length - 1].data.name });
</span>
<span>console.log(that.state.posts);
</span> <span>});
</span> <span>}
</span> <span>}
</span> <span>fetchNext(url<span>, lastPostName</span>) {
</span> <span>var that = this;
</span> <span>if (url) {
</span> <span>fetch('https://www.reddit.com/r/' + url + '.json' + '?count=' + 25 + '&after=' + lastPostName).then(function (response) {
</span> <span>return response.json();
</span> <span>}).then(function (result) {
</span>
that<span>.setState({ posts: result.data.children, lastPostName: result.data.children[result.data.children.length - 1].data.name });
</span> <span>console.log(that.state.posts);
</span> <span>});
</span> <span>}
</span> <span>}
</span> <span>componentWillMount() {
</span>
<span>this.fetchFirst("reactjs");
</span><span>}
</span>Avec le service, votre application sera servie localement à partir de http: // localhost: 5000 /.
Vous pouvez auditer votre application sans aucun problème, mais au cas où vous souhaitez le tester dans un appareil mobile, vous pouvez également utiliser des services comme Surge.sh pour le déployer avec une seule commande!
<span>npm run build </span>
Ensuite, exécutez la surtension à partir de n'importe quel répertoire pour publier ce répertoire sur le Web.
Vous pouvez trouver la version hébergée de cette application à partir de ce lien.
Maintenant, ouvrez Chrome Devtools, accédez au panneau Audits et cliquez sur Effectuer un audit.
D'après le rapport, nous pouvons voir, nous avons déjà un score de 45/100 pour l'application Web progressive et 68/100 pour les performances.
Sous l'application Web progressive, nous avons 6 audits ratés et 5 audits passés. En effet
En vertu de la performance, nous avons des diagnostics et différentes mesures calculées, telles que la première peinture significative, l'indice de vitesse interactif, constamment interactif et perceptuel et la latence d'entrée estimée. Nous les examinerons plus tard.Lighthouse suggère d'améliorer les performances de charge de page en réduisant la durée des chaînes de rendu critiques soit en réduisant la taille de téléchargement ou en reportant le téléchargement de ressources inutiles.
Veuillez noter que le score de performance et les valeurs de métriques peuvent changer entre différentes sessions d'audit sur la même machine, car elles sont affectées par de nombreuses conditions variables telles que votre état de réseau actuel et également votre état de machine actuel.
Selon DoubleClick (une société de publicité Google), 53% des visites de sites mobiles sont abandonnées s'il faut plus de 3 secondes pour charger la page. En optimisant les performances et la vitesse de chargement des pages, les PWA offrent des expériences Web instantanées aux utilisateurs via un ensemble de techniques et de stratégies que nous examinerons ensuite.
La majorité des applications côté client sont construites en utilisant une sorte de bibliothèque ou de cadre JavaScript tels que React, Preact, Angular, Vue, etc. Ou, en d'autres termes, une bibliothèque conçue pour le Web mobile en premier lieu. Sinon, l'optimisation de votre application pour les performances sera une mission impossible.
Vous devez utiliser différents outils de test, comme Chrome Devtools, Lighthouse, Google Pagespeed et autres, pour tester votre application dans des conditions de réseau différentes et simulées, afin que vous puissiez optimiser avec succès les performances de charge de votre page d'application.
Vous pouvez utiliser Lighthouse pour mesurer et optimiser les performances de chargement de votre application avec différentes mesures, diagnostics et opportunités.
Lighthouse utilise différentes mesures. Couvrons-les un par un:
La première peinture significative est une mesure qui indique simplement le temps auquel l'utilisateur peut voir un contenu significatif ou principal à l'écran. Plus cet audit est faible, meilleur est les performances perçues de votre application.
Voici cette métrique pour notre application.
Nous voyons qu'à partir de 1,3, le navigateur a commencé à rendre l'arrière-plan vide, puis à partir de 2s, le navigateur a commencé à rendre l'en-tête, 2,4S les deux boutons de l'en-tête et du bas sont rendus. Ce n'est qu'à la troisième seconde que les messages sont rendus. L'ensemble du processus a pris 3,4 secondes et la première peinture significative est égale à 2,340 ms - lorsque l'en-tête sans le bouton Suivant est rendu.
Une première peinture significative dépend vraiment de ce que nous pouvons considérer comme significatif, ce qui peut être différent entre les différents utilisateurs. Si un utilisateur n'est intéressé qu'à lire les messages, la première peinture significative pour eux est après la marque de 3 secondes. Vous pouvez voir comment Google calcule cette métrique à partir de ce document.
Il s'agit d'un autre film pour la même application où Lighthouse a rapporté le FMP comme 2,560 ms à la dernière capture d'écran où les titres du post sont complètement affichés dans la zone ci-dessus.
Deuxièmement, vous pouvez voir que la page est rendue progressive, pas à la fois, ce qui est une bonne indication des performances.
Vous pouvez optimiser cette mesure en optimisant le chemin de rendu critique.
Le chemin de rendu critique est un concept lié à la façon dont les navigateurs Web rendent les pages - c'est-à-dire du premier moment de la réception des actifs HTML, CSS et JavaScript à l'étape où le navigateur traite et rend un contenu significatif réel. Pour optimiser le chemin de rendu critique, vous devez accorder une priorité plus élevée au contenu lié à l'action actuelle de l'utilisateur. Autrement dit, s'ils sont sur le point de visiter votre application, vous pouvez commencer par afficher d'abord la partie visible de l'interface utilisateur, ou ce qu'on appelle la zone ci-dessus.
Pour plus de détails, vous pouvez lire «Optimiser le chemin de rendu critique».
Vous pouvez également voir cette liste d'outils organisés pour l'inlinaison des actifs CSS critiques. Vérifiez également ces outils pour le javascript et d'autres actifs:
Les chaînes de demande critiques sont un concept lié au chemin de rendu critique et peuvent être représentés par un diagramme qui décompose les ressources critiques pour rendre une page, combien de temps chaque ressource prend et combien d'octets télécharger pour chaque ressource. Vous pouvez utiliser le diagramme des chaînes de requête critique pour mieux comprendre les ressources critiques pour éliminer, différer ou marquer comme asynchrone. Voici une capture d'écran de notre exemple de rapport PWA:
Essayons maintenant de résoudre ce problème en utilisant la source en ligne et en ligne-source-Cli:
<span>npm install -g lighthouse </span>
Nous naviguons ensuite à l'intérieur du dossier de construction et ouvrons index.html, puis ajoutons le mot-clé en ligne aux éléments
lighthouse https://sitepoint.com/
Inlitons ces ressources:
<span>npm install -g create-react-app </span>create-react-app react-pwa <span>cd react-pwa/ </span>
En inclinant les actifs CSS et JavaScript, nous avons réduit les chaînes de demande critiques à 2.
Ces deux mesures indiquent toutes deux le temps pour l'utilisateur pour pouvoir interagir avec l'application. Les deux métriques expriment la capacité et la convivialité, mais il y a une différence entre eux. Première mesure interactive lorsque la page est peu interactive, tandis que les mesures cohérentes interactives lorsque la page est entièrement interactive.
Vous pouvez optimiser le temps d'être interactif en optimisant le chemin de rendu critique.
L'indice de vitesse perceptuelle est une métrique qui mesure les performances visuelles ci-dessus d'une page tout en tenant compte de la stabilité de la disposition (pas de déplacement soudain des éléments d'interface utilisateur). Il indique simplement à quelle vitesse le contenu de la page est visiblement peuplé.
psi est une version modifiée de la métrique SI ou index de vitesse, qui est le temps moyen auquel la zone ci-dessus (visible) est affichée sans prendre en compte la stabilité visuelle.
Vous pouvez également optimiser cette métrique en optimisant le chemin de rendu critique.
la latence d'entrée estimée est une métrique qui indique quand le thread principal devient prêt à traiter l'entrée.
Vous pouvez en savoir plus sur cette métrique et comment la passer ici.
wikipedia définit TTFB comme:
Le temps de premier octet (TTFB) est une mesure utilisée comme indication de la réactivité d'un serveur Web ou d'une autre ressource réseau. TTFB mesure la durée de l'utilisateur ou du client faisant une demande HTTP au premier octet de la page reçue par le navigateur du client.
Vous pouvez utiliser des outils tels que WebPageTest et Lighthouse pour mesurer TTFB de votre PWA. Pour plus d'informations, consultez ce lien.
Voyons maintenant un ensemble de concepts et de techniques communes utilisées par les développeurs pour optimiser ces métriques.
L'écosystème JavaScript a considérablement changé ces dernières années, avec de nouveaux outils tels que des groupes de modules comme WebPack et Browserify, qui sont utilisés pour regrouper tous les scripts en un seul fichier. Ceci est considéré comme une bonne pratique, car il aide à réduire les demandes de réseau pour plusieurs fichiers de script à une seule demande (pour obtenir l'ensemble du bundle), en optimisant le chemin de rendu critique (pas d'actifs JavaScript et CSS à long blocage). Mais le problème est que, pour les grandes applications, le bundle aura une taille plus grande, ce qui rend le processus de téléchargement du bundle, le traitement, puis le démarrage de l'application très inefficace, ce qui affecte l'expérience Web instantanée (augmenter le temps pour le premier significatif peindre et le temps pour que l'interface utilisateur devienne interactive).
En tant que solution pour ce problème, différentes applications utilisent le fractionnement du code et le section basée sur l'itinéraire (division du code en morceaux qui ne sont requis que pour chaque itinéraire). Ainsi, le navigateur n'a besoin que de télécharger le premier morceau nécessaire pour rendre la première page / l'itinéraire, puis Lazy charge les morceaux restants lorsque l'utilisateur navigue sur d'autres itinéraires.
Le rendu côté serveur est le processus de rendu du contenu initial sur le serveur au lieu du navigateur - qui peut, dans de nombreuses situations, améliorer les performances de chargement de la page, car le navigateur peut afficher le contenu (html simple) immédiatement après son téléchargement .
Le rendu côté serveur n'aidera pas beaucoup à optimiser le temps pour que l'utilisateur soit interactif, car les actifs JavaScript doivent être téléchargés et démarrés.
PRPL est un modèle de performance qui utilise des concepts tels que la poussée du serveur HTTP / 2, les en-têtes de précharge, les travailleurs de service et le chargement paresseux pour améliorer les performances de la livraison et du lancement PWA.
PRPL signifie:
Source: Google Web Fundamentals
La mise en cache est le processus de maintien des données fréquemment demandées dans un emplacement de stockage étroit. Pour le Web, c'est la mémoire ou la base de données du navigateur. Un navigateur a en fait un emplacement de cache spécialement conçu pour la mise en cache des réponses du réseau, mais les développeurs peuvent également tirer parti d'autres mécanismes de stockage tels que l'API de stockage locale HTML5 et indexéddb.
Vous pouvez mettre en cache le shell d'application (actifs responsables du rendu de l'interface utilisateur), des données ou idéalement les deux. La mise en cache de l'interface utilisateur est cruciale pour obtenir une expérience Web instantanée. Mais qu'en est-il des données?
Nous pouvons considérer deux catégories d'applications ici. Des applications qui n'ont besoin que d'une connexion réseau pour obtenir des actifs responsables de la rendu de l'interface utilisateur et / ou en ont besoin pour fournir la fonctionnalité de base. Pensez, par exemple, d'une application qui fournit une comptabilité personnelle pour les utilisateurs, qui ne dépend que des algorithmes et des calculs (CPU local).
La deuxième catégorie sont des applications qui dépendent des serveurs distants pour obtenir des informations mises à jour. Vous vous demandez peut-être pourquoi vous devez mettre en cache des données, étant donné qu'il deviendra bientôt obsolète et que les utilisateurs ont principalement besoin d'informations mises à jour. Le fait est que, dans de nombreuses régions du monde, le problème n'est pas l'interruption permanente de la connexion réseau, mais l'état fluctuant du réseau entre les signaux lents et les bons, et c'est ce qui affecte l'expérience utilisateur même si l'application est déjà chargée.
L'application peut utiliser la mise en cache des données (profitant de l'API de synchronisation de fond) pour garantir son service lorsque les utilisateurs naviguent entre les pages, ou même s'ils partent et reviennent sur l'application dans un court laps de temps, par Regarder en continu l'état du réseau, puis reprendre la récupération / envoyer des données sans interrompre l'utilisateur.
Résolvons maintenant les problèmes ratés pour de meilleurs scores.
Le premier audit échoué indique que l'application n'enregistre pas de travailleur de service. Avant de changer cela, comprenons d'abord les travailleurs du service et les fonctionnalités connexes.
Un travailleur de service est une technologie de navigateur moderne qui peut être utilisée comme proxy côté client qui permet à votre application (en interceptant les demandes de réseau) d'implémenter la mise en cache pour ajouter des fonctionnalités telles que le chargement instantané et le support hors ligne, etc.
Les travailleurs de service peuvent également être utilisés pour implémenter les mises à jour et s'engager avec les notifications push.
Les travailleurs du service ne peuvent pas accéder à la page DOM, mais peuvent communiquer avec un client (une fenêtre, un travailleur ou un travailleur partagé) via la méthode postMessage ().
De nombreuses API de navigateur sont disponibles pour une utilisation à l'intérieur des travailleurs du service, tels que:
Un travailleur de service a de nombreux événements de cycle de vie qui doivent être gérés correctement.
Le projet React contient déjà un travailleur de service. Nous pouvons soit l'utiliser ou en créer un nouveau afin que nous puissions avoir une meilleure idée du fonctionnement des travailleurs du service.
Dans le dossier public, créons un nouveau fichier nommé Service-worker.js, puis enregistrons-le à partir du fichier public / index.html en ajoutant le code suivant avant :
<span>npm install -g lighthouse </span>
Ce morceau de code vérifie d'abord si les travailleurs de service sont pris en charge dans le navigateur, puis écoute l'événement de chargement de page. Lorsque la page est chargée, il invoque la méthode Navigator.Serviceworker.Register pour enregistrer public / service-worker.js.
Maintenant, nous devons créer un fichier javascript public / service-worker.js et ajouter ce code pour configurer la mise en cache:
<span>npm install -g lighthouse </span>
Dans l'événement d'installation du travailleur des services, nous ouvrons d'abord le cache avec la méthode cache.open (), puis nous utilisons fetch () pour amener le fichier actif-manifest.json généré par webpack pour mapper des actifs hachés à leur original noms. Ensuite, nous invoquons Cache.Addall () pour ajouter ces actifs au cache d'application:
lighthouse https://sitepoint.com/
Ce code intercepte chaque demande de réseau en écoutant l'événement Fetch et en répondant avec la réponse en cache si elle existe dans le cache d'application (en utilisant la méthode cache.match ()). Sinon, nous appelons normalement fetch () pour obtenir l'actif:
<span>npm install -g create-react-app </span>create-react-app react-pwa <span>cd react-pwa/ </span>
Lorsque l'application est activée, nous supprimons l'ancien cache s'il est différent de celui actuel.
Il s'agit d'un simple travailleur de service pour la mise en cache des actifs statiques. Nous pouvons également utiliser des outils avancés pour générer des travailleurs de services tels que:
Si nous exécutons des audits contre notre application maintenant, nous devrions obtenir un score PWA de 91.
L'application peut désormais inciter les utilisateurs à l'installer sur l'écran d'accueil ou l'étagère d'un appareil.
Nous avons un audit raté, qui dit que nous devons rediriger le trafic HTTP vers HTTPS, mais c'est un peu en dehors du champ d'application de ce post. Une fois que nous avons fait cela, cependant, ce sont les résultats finaux de la performance:
En réduisant les chaînes de demande critiques via JavaScript et CSS, nous avons optimisé le chemin de rendu critique , sur lequel la plupart des métriques de performance que nous avons vues dépendent auparavant. Mais gardez à l'esprit que ce PWA est très simple; Il n'a qu'une seule page, et React est conçu avec les performances à l'esprit. C'est la raison pour laquelle nous avons obtenu un score de 95/100 pour les performances si rapidement.
Afin de couvrir tous les principes de base des applications Web progressives, je vais également expliquer les audits passés dans le rapport du phare.
Puisque nous audions l'application localement (origine: http: // localhost), Lighthouse suppose qu'il est sécurisé, donc l'audit HTTPS est marqué comme réussi, mais cela ne se produira pas une fois que vous utiliserez un hôte réel et liez un lien A Nom de domaine de niveau supérieur, sauf si vous avez réellement un certificat SSL. (Notez que les travailleurs du service ne sont desservis uniquement à partir d'origine sécurisée, sauf dans le cas de la local.)
Vous pouvez héberger votre application avec des pages GitHub qui vous donne un sous-domaine sécurisé HTTPS (github.io). Vous pouvez également utiliser l'hébergement Firebase avec un sous-domaine sécurisé ou une surtension (Surge.sh) qui est également livré avec un certificat SSL de base gratuitement.
Si vous décidez de relier votre propre domaine de haut niveau, vous avez également la possibilité d'obtenir un certificat SSL gratuit avec Let’s Encrypt ou CloudFlare.
Pour ce cours, nous n'avons pas vraiment besoin d'héberger l'application avec un serveur sécurisé HTTPS, car le phare passe cet audit lors des tests localement.
Un manifeste d'application Web est un fichier JSON qui fournit des informations sur un PWA, comme le nom, les icônes et la description, entre autres choses. Il permet aux utilisateurs d'installer l'application Web sur l'écran d'accueil tout comme les applications natives, mais sans passer par une boutique d'applications.
Un manifeste de l'application Web doit être référencé à partir d'un fichier index.html à l'aide d'une balise
Par exemple, l'application REACT générée simple a un fichier public / manifest.json avec le contenu suivant:
<span>npm install -g lighthouse </span>
Il est référencé par public / index.html:
lighthouse https://sitepoint.com/
n'avaient pas de support pour les écrans PWA Splash avant, donc lorsque les utilisateurs exécutent l'application à partir de l'icône de l'écran d'accueil, ils passent souvent par un écran blanc pendant quelques secondes avant de pouvoir voir l'interface utilisateur réelle de l'application. À partir de Chrome 47, les utilisateurs peuvent voir un écran d'éclaboussures, ce qui augmente les performances perçues et transitions l'utilisateur de taper l'icône de l'écran d'accueil à la première peinture d'une application.
En termes simples, les performances perçues sont une mesure plus liée à la perspective et à l'expérience d'un utilisateur que la vitesse de chargement / pages réelle - fournissant des informations sur la vitesse de votre application se sent aux utilisateurs finaux.
Vous pouvez lire l'article de perception de la performance pour en savoir plus à ce sujet.
Cet écran Splash est construit pour votre application dynamiquement à partir des informations du manifeste Web, mais (selon le phare), vous devez avoir une icône d'au moins 512 × 512 Écran d'éclaboussure.
Alors, préparez simplement une icône d'au moins 512 × 512, puis ajoutez ce qui suit à votre manifeste.json sous le tableau des icônes:
<span>npm install -g create-react-app </span>create-react-app react-pwa <span>cd react-pwa/ </span>
L'un des principes de base des PWA est une amélioration progressive, qui fait référence à la capacité des PWA à fonctionner sur différents navigateurs mais ne fournit des fonctionnalités plus avancées que si elles sont prises en charge.
Vous pouvez également lire «le contrecoup de dépendance en JavaScript: amélioration progressive du mythe» pour mieux comprendre l'amélioration progressive.
Un exemple simple d'amélioration progressive est lorsqu'une application est exécutée dans un navigateur qui ne prend pas en charge JavaScript, ou du moins lorsque JavaScript est désactivé. Au lieu de ne rien montrer, vous pouvez utiliser la balise HTML
<span>npm install -g lighthouse </span>
Chrome est le premier navigateur avec le support officiel des PWA. En tant que tel, les Devtools de Chrome ont d'excellentes fonctionnalités pour le débogage des PWA, spécifiquement contenu dans deux panneaux - le panneau d'audit et le panneau d'application.
Sous le panneau d'audit, vous pouvez trouver l'outil de phare que nous avons vu précédemment. Dans le cadre du panneau d'application, vous pouvez trouver de nombreux outils utiles pour déboguer les aspects principaux des PWA, tels que:
Dans de nombreuses régions du monde, les appareils mobiles sont connectés via des réseaux lents et squameux, donc afin de fournir une meilleure expérience utilisateur et un temps de chargement acceptable - ou, mieux encore, pour des expériences Web instantanées pour une grande base d'utilisateurs avec Vitesses de réseau variables - vous devez optimiser votre application dans des conditions potentiellement différentes. Grâce au panneau de réseau Chrome Devtools, vous pouvez imiter plusieurs conditions de réseau telles que la 3G lente, la 3G rapide et l'état hors ligne, et vous pouvez même créer des profils personnalisés avec vos propres valeurs personnalisées pour Télécharger , Télécharger et latence Paramètres.
Le panneau réseau fournit d'autres fonctionnalités telles que la désactivation du cache, la désactivation de l'état hors ligne et la prise de captures d'écran d'application en temps de chargement.
La désactivation du cache et l'activation de l'état hors ligne sont particulièrement utiles pour le débogage des PWA.
Pour plus d'informations, consultez la «référence d'analyse du réseau» de Google.
Une PWA n'est pas seulement une autre application axée sur les performances. C’est plus que ça! Grâce aux grands acteurs de l'industrie du logiciel - Google, Microsoft, etc. - ils deviennent des applications de première classe sur plusieurs plates-formes.
Mis à part les avantages de performance que vous pouvez également intégrer dans n'importe quelle application Web, même si vous n'avez pas l'intention de créer un PWA entièrement qualifié, les PWA fournissent ce qui suit:
Espérons que ce cours intensif vous a aidé à démarrer avec PWA-I-Ichen votre propre application Web!
Les applications Web progressives (PWAS) offrent plusieurs avantages par rapport aux applications Web traditionnelles. Premièrement, ils sont très réactifs, ce qui signifie qu'ils peuvent s'adapter à n'importe quel facteur de forme, ordinateur de bureau, mobile, tablette ou formulaires à émerger. Deuxièmement, ils sont indépendants de la connectivité, ce qui signifie qu'ils peuvent travailler hors ligne ou sur des réseaux de faible qualité. Les PWA sont également semblables à l'application, ce qui signifie qu'ils utilisent le modèle d'application pour fournir une navigation et des interactions de style application. Ils sont également frais, toujours à jour grâce au processus de mise à jour des travailleurs du service. Les PWA sont sûrs, servis via HTTPS pour éviter l'espièglerie et s'assurer que le contenu n'a pas été falsifié. Enfin, ils sont découvrables, identifiables comme des «applications» grâce aux manifestes W3C et à la portée d'enregistrement des travailleurs de service, permettant aux moteurs de recherche de les trouver.
PWAS Améliorez considérablement l'engagement des utilisateurs en offrant une expérience immersive et en plein écran via un fichier manifeste d'application Web et peut même réengager les utilisateurs avec des notifications push Web. Le manifeste de l'application Web vous permet de contrôler comment votre application apparaît et comment elle est lancée. Vous pouvez spécifier les icônes de l'écran d'accueil, la page à charger lorsque l'application est lancée, l'orientation de l'écran et même s'il faut afficher ou non le navigateur Chrome. Ce niveau de contrôle améliore l'engagement des utilisateurs en fournissant une expérience utilisateur similaire aux applications natives.
Les PWA ne sont pas liés à un langage de programmation spécifique. Ils sont construits à l'aide de technologies Web standard, notamment HTML, CSS et JavaScript. Cependant, ils s'exécutent dans un navigateur Web standard. Cela signifie que vous pouvez utiliser n'importe quelle technologie pour créer un PWA tant qu'il peut s'exécuter dans un navigateur Web et peut être servi sur un réseau.
PWAS Peut travailler hors ligne en utilisant des travailleurs de services, un type de travailleur Web. Les travailleurs de service fonctionnent comme un proxy de réseau, interceptant les demandes de réseau pour fournir des réponses programmatiques ou basées sur le cache. Ils sont axés sur les événements et exécutent uniquement en cas de besoin, ils ne consomment donc pas de ressources lorsqu'ils ne sont pas utilisés. Cela permet aux PWA de mettre en cache ou d'enregistrer du contenu et de le servir directement à partir du cache lorsqu'il n'y a pas de connexion réseau.
Oui, les PWA sont conviviaux. Ils sont découvrables par les moteurs de recherche car ils sont construits avec des technologies Web standard, et ils utilisent des travailleurs de service, qui leur permettent de se charger instantanément, quel que soit l'état du réseau. Cette charge rapide et la capacité de fonctionner hors ligne peuvent conduire à plus de temps passé sur l'application et à la baisse des taux de rebond, ce qui peut avoir un impact positif sur le référence Améliorez les performances en utilisant les travailleurs de service pour mettre en cache des actifs et d'autres données. Cela permet au PWA de se charger instantanément et de fournir une expérience utilisateur fluide. L'utilisation du motif PRPL (push, rendu, pré-cache, charge paresseuse) aide également à améliorer les performances des PWA. Ce modèle permet le chargement et le rendu efficaces des ressources critiques, améliorant la vitesse globale de l'application.
Oui, les PWA peuvent accéder et utiliser beaucoup Caractéristiques de l'appareil telles que la géolocalisation, la caméra et même les notifications push, similaires aux applications natives. Ceci est possible grâce à l'utilisation d'API Web. Cependant, la mesure dans laquelle un PWA peut accéder aux fonctionnalités des périphériques dépend de la prise en charge du navigateur pour ces API.
tandis que les PWA et les applications natives peuvent offrir Des fonctionnalités similaires, elles diffèrent de plusieurs manières. Les PWA sont construits à l'aide de technologies Web et exécutées dans un navigateur Web, tandis que les applications natives sont développées pour des plates-formes spécifiques en utilisant des langages comme Swift pour iOS ou Java pour Android. Les PWA sont généralement plus faciles et plus rapides à développer et à mettre à jour que les applications natives. Ils sont également plus légers et ne nécessitent pas que les utilisateurs téléchargent quoi que ce soit à partir d'un magasin d'App.
L'avenir des PWA semble prometteur. Avec les progrès des technologies Web et l'amélioration du support de navigateur, les PWA deviennent une alternative viable aux applications natives. Ils offrent le potentiel d'un développement et d'un déploiement plus rapides et plus efficaces, et une expérience utilisateur meilleure et plus transparente. Alors que de plus en plus d'entreprises reconnaissent ces avantages, il est probable que l'utilisation des PWA continuera de croître.
Il existe de nombreux exemples de PWA réussis dans diverses diverses industries. PWA de Twitter, Twitter Lite, est l'un des exemples les plus notables, offrant une expérience plus rapide et plus économe en données pour les utilisateurs. D'autres exemples incluent Starbucks, qui permet aux clients de parcourir le menu, de personnaliser leurs commandes et d'ajouter des articles à leur panier, tout en étant hors ligne. La PWA de la chaîne météorologique fournit des informations météorologiques fiables avec une amélioration de 80% du temps de chargement par rapport à leur expérience Web mobile précédente.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Principales utilisations du système d'exploitation Linux
Pièces sous-évaluées à thésauriser en 2024
Méthode de réparation des erreurs Kernelutil.dll
Introduction aux fonctions d'ordre supérieur de Python
Comment définir les deux extrémités pour qu'elles soient alignées en CSS
gestionnaire de démarrage de Windows
Combien de temps faut-il pour que la recharge Douyin arrive ?
Explication détaillée de l'utilisation de la commande netsh
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
