La conception Web réactive et adaptative sont deux méthodes pour créer des sites Web conviviaux pour plusieurs appareils qui fonctionnent bien avec une variété de tailles d'écran. Si la conception Web réactive est recommandée par Google et qu’elle est la plus populaire des deux approches, ces deux méthodes de conception Web multi-périphériques ont leurs forces et leurs faiblesses.
Examinons les différences entre la conception Web adaptative et réactive, en nous concentrant spécifiquement sur ces domaines clés:
- Facilité de développement
- Le niveau de contrôle que vous avez sur la conception
- Portée de l'appareil / écran
- Comment futur la solution est
- Vitesse de téléchargement globale et performances du site
Quelques définitions
Avant de procéder à des comparaisons côte à côte de la conception Web adaptative et réactive, prenons un moment pour examiner une définition de haut niveau de ces deux approches.
Les sites Web réactifs ont une présentation fluide qui change et s’adapte quelle que soit la taille de l’écran utilisé. Les requêtes de média permettent aux sites sensibles de changer même «à la volée» si le navigateur est redimensionné.
La conception adaptative utilise des tailles fixes basées sur des points d'arrêt prédéterminés pour fournir la version de présentation la mieux adaptée à la taille d'écran détectée lors du premier chargement de la page.
Avec ces définitions générales en place, passons à nos principaux domaines d’intervention.
Facilité de développement
La différence la plus significative entre la conception Web adaptative et réactive réside dans la manière dont ces solutions sont appliquées à un site Web. Étant donné que la conception réactive crée une mise en page totalement fluide, il est préférable de l'utiliser dans les projets dans lesquels vous redessinez le site à partir de zéro. Essayer de mettre à jour le code d’un site Web existant pour qu’il devienne réactif est souvent une affaire épuisant, car vous n’avez tout simplement pas le niveau de contrôle que vous auriez si vous développiez ce code à partir de zéro et tenez compte de la conception réactive dès les premières étapes de ce processus. Cela signifie que lorsque vous adaptez un site à la réactivité, vous êtes obligé de faire des compromis afin de rester dans cette base de code existante.
Si vous travaillez avec un site Web existant à largeur fixe, une approche adaptative signifie que vous pouvez conserver la taille pour laquelle le site a été conçu et conserver des points d'arrêt adaptatifs supplémentaires en fonction des besoins. Dans certains cas, si le budget d'un projet est petit et qu'il ne peut prendre en charge qu'un petit travail de développement, vous pouvez choisir d'ajouter uniquement de nouveaux points d'arrêt adaptatifs pour des tailles d'écran centrées / mobiles plus petites. Cela signifie que vous autoriseriez tous les écrans plus grands à utiliser la même présentation - peut-être une version à points d'arrêt 960 qui correspondait à la conception originale de ce site.
L'avantage d'une approche adaptative est que vous pouvez mieux exploiter le code d'un site existant, mais l'un des inconvénients est que vous créez des modèles de présentation différents pour chaque point d'arrêt que vous choisissez de prendre en charge. Cela aura un impact sur la charge de travail requise pour développer et maintenir cette solution à long terme.
Contrôle de la conception
L'un des points forts des sites Web réactifs est que leur fluidité leur permet de s'adapter et de prendre en charge toutes les tailles d'écran, par opposition aux seuls points d'arrêt prédéfinis déterminés dans une approche adaptative. La réalité, cependant, est que les sites réactifs peuvent sembler superbes avec certaines tailles d’écran clés (généralement des tailles qui correspondent aux appareils populaires disponibles sur le marché), mais la conception visuelle se décompose souvent entre ces résolutions courantes.
Par exemple, un site peut sembler génial à la disposition d'écran large de 1400 pixels, à la taille d'écran intermédiaire de 960 pixels et au petit écran à 480 pixels, mais qu'en est-il des états intermédiaires de ces tailles? En tant que designer, vous n’avez pratiquement aucun contrôle sur ces tailles intermédiaires et l’aspect visuel de la page à ces tailles est souvent loin d’être idéal.
Avec un site Web adaptatif, vous avez beaucoup plus de contrôle sur la conception des différentes mises en page utilisées car elles ont une taille fixe en fonction de vos points d'arrêt établis. Ces états intermédiaires délicats ne sont plus un problème, car vous avez soigneusement conçu chaque "look" (signifiant l'affichage de chaque point d'arrêt) qui sera livré aux visiteurs.
Aussi attrayant que ce niveau de contrôle de la conception puisse paraître, vous devez être conscient du prix. Oui, vous avez un contrôle total sur l'apparence de chaque point d'arrêt, mais cela signifie que vous devez investir le temps de conception nécessaire à la conception de chacune de ces dispositions uniques. Plus vous choisissez de concevoir des points d'arrêt, plus vous devrez consacrer de temps à ce processus.
Ampleur du soutien
La conception Web adaptative et réactive bénéficie d’un support assez robuste, en particulier dans les navigateurs modernes.
Les sites Web adaptatifs nécessitent des composants côté serveur ou Javascript pour la détection de la taille de l'écran. Évidemment, si un site adaptatif nécessite Javascript, cela signifie qu'un navigateur doit l'activer pour que ce site fonctionne correctement. Cela peut ne pas être une préoccupation majeure pour vous car la plupart des gens auront Javascript dans leurs navigateurs, mais chaque fois qu'un site a une dépendance critique sur quoi que ce soit, il convient de le noter.
Les sites Web réactifs et les requêtes des médias qui les alimentent fonctionneront bien dans tous les navigateurs modernes. Les seuls problèmes que vous rencontrerez concernent les versions les plus anciennes d'Internet Explorer, car les versions 8 et suivantes ne prennent pas en charge les requêtes de média. Pour contourner ce problème, un polyfill Javascript est souvent utilisé, ce qui signifie qu'il existe une dépendance à Javascript ici aussi, du moins pour les versions obsolètes d'IE.Encore une fois, cela ne vous préoccupera peut-être pas, en particulier si les analyses de votre site montrent que vous ne recevez pas beaucoup de visiteurs utilisant ces versions de navigateur plus anciennes.
Future convivialité
La nature fluide des sites Web réactifs leur confère un avantage par rapport aux sites adaptatifs en termes de convivialité future. En effet, ces sites réactifs ne sont pas conçus pour prendre en charge uniquement un ensemble de points d'arrêt préalablement établi. Ils s'adaptent pour s'adapter tous les écrans , y compris ceux qui peuvent ne pas être réellement sur le marché aujourd'hui. Cela signifie que les sites réactifs n'auront pas besoin d'être «réparés» si une nouvelle résolution d'écran devient soudainement populaire.
Compte tenu de l'incroyable diversité du paysage des appareils (en août 2015, il y avait plus de 24 000 appareils Android distincts sur le marché), il est essentiel de disposer d'un site capable de prendre en charge de manière optimale cette large gamme d'écrans. En effet, il est peu probable que ce paysage devienne moins diversifié dans le futur, ce qui signifie que concevoir des écrans ou des tailles spécifiques va devenir impossible, si nous n’avons pas déjà atteint cette réalité.
De l’autre côté de ce scénario de comparaison, si un site est adaptatif et ne prend pas en charge les nouvelles résolutions susceptibles de devenir importantes sur le marché, vous pouvez être forcé d’ajouter ce point d'arrêt aux sites que vous avez créés. Cela ajoute du temps de conception et de développement aux projets et signifie que ces sites adaptatifs doivent être surveillés de manière cohérente afin de garantir qu'aucun nouveau point d'arrêt n'a été introduit sur le marché, mais qu'il doit être ajouté au site. Là encore, avec la diversité des périphériques, le fait de devoir vérifier en permanence de nouvelles tailles et de les adapter éventuellement avec de nouveaux points de rupture est un défi permanent qui aura une incidence sur le travail que vous devez effectuer pour prendre en charge un site et le coût de cette maintenance la société ou l'organisation pour laquelle le site est destiné.
Performance
La conception Web réactive a longtemps été accusée (injustement dans bien des cas) d’être une mauvaise solution du point de vue de la vitesse de téléchargement / des performances. Cela est dû en grande partie au fait qu’au début de cette approche, de nombreux concepteurs Web ont simplement ajouté des requêtes multimédia sur un petit écran au CSS existant d’un site. Cela a forcé les images et les ressources destinées aux grands écrans à être transmises à tous les appareils, même si ces écrans plus petits ne les utilisaient pas dans leur mise en page finale. Le design réactif a parcouru un long chemin depuis ces jours et la réalité est que les sites réactifs de qualité ne souffrent pas de problèmes de performances.
Les vitesses de téléchargement lentes et les sites Web surchargés ne sont pas un problème de site Web réactif - c'est un problème qui peut être trouvé sur tous les sites Web. Des images trop lourdes, des médias sociaux, des scripts excessifs, etc., et alourdissent un site. Toutefois, les sites Web réactifs et adaptatifs peuvent être conçus pour un chargement rapide. Bien sûr , ils peuvent également être construits de manière à ne pas donner la priorité à la performance, mais il ne s'agit pas d'un trait de la solution elle-même, mais plutôt d'une réflexion sur l'équipe impliquée dans le développement du site lui-même.
Au-delà de la mise en page
L'un des aspects les plus convaincants de la conception Web adaptative réside dans le fait que vous contrôlez non seulement la conception du site pour les points d'arrêt définis, mais également les ressources livrées pour ces versions de site. Par exemple, cela signifie que les images de la rétine ne peuvent être envoyées qu'à des périphériques de la rétine, tandis que les écrans non rétiniens obtiennent des images plus appropriées dont la taille de fichier est plus petite. Les autres ressources du site (fichiers Javascript, styles CSS, etc.) ne peuvent être intelligemment livrées que lorsqu'elles sont nécessaires et seront utilisées.
Cette utilisation de la conception Web adaptative va bien au-delà de la simple équation de «si vous adaptez un site Web, l’adaptation peut être une approche plus facile à utiliser». Tous les sites, y compris les refontes complètes, peuvent bénéficier d’une approche plus intelligente pour une expérience plus personnalisée.
Ce scénario montre la nature nuancée de ce débat «réactif contre adaptatif». S'il est vrai qu'une approche adaptative peut être mieux adaptée que la réactivité pour la modernisation de sites, elle peut également s'avérer une excellente solution pour une refonte complète. De même, dans certains cas, une approche réactive peut être ajoutée à la base de codes d’un site existant, donnant à ce site tous les avantages d’une approche entièrement réactive.
Quelle approche est la meilleure?
En ce qui concerne la conception Web réactive par opposition à la conception Web adaptative, il n’ya pas de «gagnant» clair, bien que l’approche réactive soit certainement la plus populaire. En réalité, la "meilleure" approche dépend des besoins d'un projet spécifique. De plus, il n'est pas nécessaire que ce soit une situation «soit / ou». De nombreux professionnels du web construisent des sites alliant le meilleur de la conception web réactive (largeurs de fluide, support futur) aux atouts de la conception adaptative (meilleur contrôle de la conception, chargement intelligent des ressources du site).
Communément appelée RESS (conception Web réactive avec des composants côté serveur), cette approche montre qu’il n’existe vraiment pas de solution unique pour tous. La conception Web réactive et la technologie adaptative ont leurs forces et leurs défis. Vous devez donc déterminer laquelle fonctionnera mieux pour votre projet spécifique, ou si une solution hybride peut réellement vous convenir le mieux.
