L'écosystème Java backend a beaucoup évolué. Trois frameworks illustrent bien cette trajectoire, chacun représentant une époque et une philosophie différentes :
- Spring Boot : le standard actuel
- Quarkus : l'approche cloud-native
- Struts 2 : le legacy encore très présent en entreprise
Plutôt que de comparer documentation et promesses marketing, j’ai voulu mesurer sur un cas volontairement simple et reproductible. Même application, même modèle métier, trois implémentations. J’ai comparé cinq critères : temps de démarrage, occupation mémoire, temps de réponse, dépendances embarquées et taille des artefacts produits.
L'objectif n'est pas de désigner un vainqueur. Mais de mettre des chiffres sur des questions concrètes :
Quarkus démarre-t-il vraiment plus vite ? Spring Boot embarque-t-il beaucoup plus de dépendances ? Struts reste-t-il dans la course ?
Voyons cela.
Présentation du benchmark
Pour comparer les frameworks dans des conditions identiques, chaque implémentation repose sur exactement le même besoin métier.
Le domaine choisi est volontairement simple : une API de gestion d'auteurs et d'articles.
Une relation un-à-plusieurs relie les auteurs à leurs articles.
Les modèles et endpoints seront détaillés dans chaque implémentation. Les routes exposées sont identiques dans les trois cas :
GET /authors
GET /authors/{id}
GET /authors/{id}/articles
GET /articles
GET /articles/{id}
POST /articlesCe périmètre reste volontairement limité. L'objectif n'est pas de benchmarker la logique métier mais bien le framework lui-même : démarrage du runtime, exposition HTTP, sérialisation JSON, accès base de données, gestion des dépendances.
Environnement de test
Toutes les mesures ont été réalisées sur la même machine.
| Paramètre | Valeur |
|---|---|
| Machine | MacBook Pro |
| OS | macOS Tahoe 26.5 |
| Puce | Apple M3 Pro |
| Java | Java 21.0.8 |
| Maven | 3.9.11 |
| Base | H2 en mémoire |
| Jeu de données | 10 auteurs, 100 articles |
Chaque mesure a été exécutée plusieurs fois, JVM froide puis JVM chaude. Les résultats présentés correspondent à la moyenne et à la médiane sur 10 itérations.
Présentation rapide des frameworks
Spring Boot
Spring Boot est devenu le standard de fait du backend Java moderne. Son objectif : réduire la configuration au minimum pour permettre de lancer rapidement une application prête pour la production.
Points forts :
- auto-configuration
- intégration très poussée avec l'écosystème Spring
- excellente documentation
- forte adoption en entreprise
En contrepartie : runtime plus lourd, beaucoup de dépendances embarquées, abstraction parfois très importante.
Pour nos articles sur Spring Boot, c'est par ici :
Erwan Le Tutour
Quarkus
Quarkus adopte une approche différente en misant fortement sur l'optimisation au build, la rapidité de démarrage, une faible empreinte mémoire et le cloud-native. Il cible particulièrement Kubernetes, les conteneurs et le serverless.
Sa promesse : Java avec un comportement plus léger et plus rapide.
Note : Quarkus supporte également la compilation native via GraalVM. Ce benchmark se limite au mode JVM pour rester dans des conditions comparables avec les deux autres frameworks.
Pour nos articles sur Quarkus, c'est par là :
Erwan Le TutourStruts 2
Apache Struts appartient à une génération plus ancienne du web Java. Avant Spring Boot, il a longtemps été un standard dans de nombreuses applications web d'entreprise et reste présent dans de nombreuses applications legacy.
Ses points forts : architecture explicite, framework historiquement très répandu, conventions limitées.
En revanche : moins orienté API REST moderne, configuration plus manuelle, moins d'outillage contemporain.
Le comparer avec Spring Boot et Quarkus est intéressant non pour opposer des générations, mais pour quantifier concrètement l'évolution du backend Java.
Temps de démarrage
Temps mesuré entre le lancement de la JVM et la première requête acceptée.
| Framework | Moyenne | Médiane |
|---|---|---|
| Spring Boot | 1,5205 s | 1,4745 s |
| Quarkus | 1,0168 s | 1,023 s |
| Struts | 3,323 s | 3,315 s |
Sans surprise, Quarkus est le plus rapide au démarrage. Même en mode JVM, sans compilation native, il prend l'avantage grâce à son travail d'optimisation au build. Une partie de ce que Spring Boot ou Struts initialisent au runtime est préparée plus tôt dans le cycle de vie de l'application.
Spring Boot reste très correct avec un démarrage autour d'une seconde et demie. C'est plus lent que Quarkus, mais cela reste largement acceptable pour une application backend classique, surtout dans un contexte où l'application reste démarrée longtemps.
Struts est nettement derrière. Il faut toutefois nuancer la comparaison : ici, Spring Boot et Quarkus sont lancés via leur JAR applicatif, hors dev mode, alors que Struts est lancé comme application WAR via Jetty.
Le temps mesuré côté Struts inclut donc le démarrage du serveur servlet, le déploiement de l'application web et l'initialisation du framework. C'est justement représentatif d'une partie du monde legacy Java : le framework n'est pas seul, il dépend davantage du conteneur dans lequel il est déployé.
La tendance reste claire : plus le framework est récent, plus le démarrage devient un critère central. Quarkus a été conçu avec cette contrainte en tête, Spring Boot l'a progressivement optimisée, tandis que Struts appartient à une époque où le démarrage rapide était rarement prioritaire.
Occupation mémoire
| Framework | RSS |
|---|---|
| Spring Boot | 239 Mo |
| Quarkus | 214 Mo |
| Struts | 46 Mo* |
*Mesuré via Maven+Jetty dans la même JVM — non directement comparable.
Spring Boot et Quarkus sont proches, avec un léger avantage pour Quarkus (~25 Mo d'écart). C'est cohérent avec ses optimisations au build, même en mode JVM. En compilation native GraalVM, l'écart serait bien plus marqué, on tomberait plutôt autour de 50 Mo.
Struts affiche un chiffre très bas, mais la comparaison est biaisée par le mode de lancement. Pour une mesure équitable, il faudrait déployer le WAR sur un serveur Jetty autonome. Ce n'est d'ailleurs pas anodin : c'est précisément le reflet du modèle legacy : le framework ne se suffit pas à lui-même, il dépend du conteneur dans lequel il s'exécute.
Temps de réponse
Endpoint benchmarké : GET /articles/1
| Framework | Cold | Moyenne | P95* |
|---|---|---|---|
| Spring Boot | 190 ms | 14,8 ms | 20 ms |
| Quarkus | 229 ms | 14,55 ms | 19 ms |
| Struts | 253 ms | 14,66 ms | 18 ms |
*P95 (95e percentile) correspond au temps de réponse en dessous duquel passent 95 % des requêtes, les 5 % restantes étant plus lentes.
Sur les temps de réponse, les écarts sont beaucoup moins marqués. Une fois les applications démarrées, les trois frameworks répondent dans le même ordre de grandeur : autour de 14 à 15 ms en moyenne sur cet endpoint.
Le cold call est plus lent pour les trois frameworks, ce qui est normal : la première requête déclenche encore plusieurs initialisations internes, notamment côté sérialisation JSON, accès JPA/Hibernate et préparation des requêtes SQL. Struts est le plus lent sur ce premier appel, mais l'écart reste modéré.
Le plus intéressant ici est le P95. Les trois frameworks restent très proches, avec même un léger avantage pour Struts sur cette mesure. Cela ne signifie pas que Struts est plus performant dans l'absolu, mais que sur un cas très simple, avec peu de logique métier et une base H2 en mémoire, le framework HTTP n'est pas le facteur dominant.
Autrement dit, pour une API CRUD simple déjà démarrée, Spring Boot, Quarkus et Struts peuvent produire des temps de réponse comparables. La vraie différence se voit davantage sur l'expérience de développement, le démarrage, l'intégration moderne, l'observabilité, le packaging et l'exploitation.
Dépendances embarquées
| Framework | Nombre de dépendances | taille du jar / war |
|---|---|---|
| Spring Boot | 76 | 56,3 Mo |
| Quarkus | 162 | 42 Mo |
| Struts | 35 | 33,1 Mo |
Le nombre de dépendances est intéressant, mais il ne doit pas être lu trop vite. Quarkus intègre le plus grand nombre de dépendances, pourtant son artefact final est plus petit que celui de Spring Boot. Cela montre que le nombre brut de bibliothèques ne suffit pas à mesurer la lourdeur réelle d'une application.
Spring Boot produit ici l'artefact le plus volumineux. C'est cohérent avec son modèle : il embarque beaucoup d'intégrations prêtes à l'emploi et fournit une expérience très complète. Cette richesse se paie par un packaging plus conséquent, même si elle apporte aussi un confort de développement important.
Struts est le plus léger en nombre de dépendances et en taille d'artefact. Mais cette légèreté apparente vient aussi du fait que Struts fournit moins de choses directement. Une partie de l'assemblage est plus manuelle : configuration web, serveur servlet, initialisation JPA, mapping JSON, gestion du cycle de vie. Le framework embarque moins, mais demande davantage de plomberie.
Tableau récapitulatif
| Framework | Temps de démarrage moyen (s) |
Temps de réponse moyens (ms) |
P95 | RSS |
|---|---|---|---|---|
| Spring Boot | 1,52 | 14,88 | 20 | 239 Mo |
| Quarkus | 1,01 | 14,55 | 19 | 214 Mo |
| Struts 2 | 3,323 | 14,66 | 18 | 46 Mo* |
Ce récapitulatif met bien en évidence le principal enseignement du benchmark : l'écart le plus visible se situe au démarrage, pas sur le temps de réponse une fois l'application chaude. Quarkus prend l'avantage sur le boot, Spring Boot reste très proche en usage courant, et Struts 2 montre surtout le coût de son modèle plus ancien basé sur un déploiement WAR dans un conteneur servlet. Sur une requête simple, les trois frameworks restent en revanche dans des performances comparables.
Conclusion
Ce benchmark ne cherche pas à désigner un framework "meilleur" que les autres. Chaque framework a son histoire et répond à un contexte différent.
Ce qui ressort surtout, c'est l'évolution du backend Java : entre Struts et Spring Boot, puis entre Spring Boot et Quarkus, on observe clairement les priorités changer : moins de configuration, démarrage plus rapide, meilleure intégration cloud, optimisation runtime.
Le socle Java reste le même. Mais la façon de construire un backend Java continue d'évoluer. Et c'est précisément ce qui rend ce type de benchmark aussi intéressant : mettre des chiffres sur cette évolution.
Tout le code ayant servi à l'élaboration de ce benchmark est consultable ici :
ErwanLT
