Retour au blog

WindowServer et utilisation CPU élevée sur Mac : ce que c'est et comment le résoudre

WindowServer à plus de 100 % de CPU ? C'est le processus macOS qui dessine chaque pixel à l'écran. Découvrez pourquoi il s'emballe, quand s'inquiéter, et comment trouver l'application qui provoque réellement la charge.

Vous ouvrez Activity Monitor parce que votre Mac semble lent, et le processus en tête de la colonne CPU s’appelle WindowServer — parfois à 80 %, 150 %, voire 300 %. L’arrêter n’est pas une option (cela vous déconnecterait), et le conseil habituel « redémarrez votre Mac » n’explique pas ce qui se passe. Ce guide explique ce qu’est réellement WindowServer, pourquoi une utilisation CPU élevée est presque toujours un symptôme plutôt qu’une cause, et comment trouver l’application ou la charge de travail qui le fait réellement s’emballer.

Réponse rapide

WindowServer est le processus macOS qui compose chaque pixel que vous voyez à l’écran — fenêtres, menus, curseur, Dock, animations. Il ne fait quasiment rien par lui-même. Lorsqu’il affiche une utilisation CPU élevée, cette charge est provoquée par autre chose qui lui demande de dessiner : une application au comportement défectueux, de nombreuses fenêtres visibles ou des pages de navigateur lourdes en graphismes, plusieurs écrans externes haute résolution, ou une couche accélérée par GPU boguée dans une application basée sur Electron. Vous ne pouvez pas et ne devez pas arrêter WindowServer ; le forcer à quitter met fin à votre session utilisateur. La solution consiste à identifier l’application en amont et à la traiter. ProcXray rend cela rapide : triez par la colonne GPU par processus pour trouver le processus gourmand en graphismes, utilisez le System Dashboard pour confirmer la pression GPU globale, et utilisez le Window Spy Picker pour relier n’importe quelle fenêtre visible à l’application qui la possède.

Qu’est-ce que WindowServer ?

WindowServer est la partie de macOS responsable de la composition d’écran — elle prend la sortie graphique de chaque application en cours d’exécution et la combine en l’image finale affichée par votre écran. Il réside à l’emplacement /System/Library/PrivateFrameworks/SkyLight.framework/Resources/WindowServer et démarre automatiquement à l’ouverture de session d’un utilisateur. Il existe un processus WindowServer par session utilisateur ouverte.

En coulisses, chaque application visible pousse son contenu rendu sous forme d’un ensemble de couches Core Animation. WindowServer demande ensuite au GPU de combiner ces couches — en appliquant transparence, flous, ombres et animations — et envoie le résultat à votre écran à la fréquence de rafraîchissement (typiquement 60 Hz, ou jusqu’à 120 Hz sur les écrans ProMotion).

Dans des conditions normales, WindowServer utilise entre 1 % et 15 % de CPU. Sur un Mac avec un seul écran interne et quelques applications ouvertes, il ne devrait pas être le processus en tête.

Une remarque sur les pourcentages : dans Activity Monitor, 100 % correspond à l’équivalent d’un cœur CPU complet. Sur un Mac avec plusieurs cœurs, un seul processus peut afficher bien au-delà de 100 %. Ainsi, WindowServer à 300 % n’est pas « 300 % de toute la machine » — il occupe l’équivalent de trois cœurs entiers.

Pourquoi une utilisation CPU élevée de WindowServer n’est généralement pas son fait

C’est la reformulation la plus importante de ce guide : WindowServer est en aval. Il ne déclenche pas son propre travail. Chaque cycle CPU qu’il consomme provient d’une demande de dessiner quelque chose — par une application, par une fenêtre, par une animation, ou par le système lui-même.

Donc quand WindowServer est à 200 % de CPU, la question de diagnostic n’est pas « qu’est-ce qui ne va pas avec WindowServer ? » C’est :

Qu’est-ce qui fait actuellement travailler WindowServer si dur ?

Cette cause en amont est ce que vous devez trouver et corriger. Arrêter WindowServer ne vous déconnecterait pas seulement — même si vous pouviez le remplacer instantanément, la même charge en amont reviendrait aussitôt.

C’est le même schéma de diagnostic que pour kernel_task et l’utilisation CPU élevée : le processus visible en tête d’Activity Monitor est le symptôme, pas la cause.

Ce qui déclenche les pics de WindowServer

Il existe six causes en amont fréquentes, à peu près classées par fréquence d’occurrence :

1. Une application accélérée matériellement au comportement défectueux

Les navigateurs basés sur Chromium (Chrome, Edge, Arc, Brave), les applications Electron (Slack, Discord, VS Code, Notion, Figma), les éditeurs vidéo et les jeux poussent tous des couches accélérées matériellement vers WindowServer. Un bug ou une couche bloquée dans l’un d’eux peut immobiliser WindowServer même lorsque l’application semble inactive. Des exemples fréquents incluent Chrome et Slack.

2. Nombreux écrans externes ou écrans haute résolution

Chaque écran externe ajoute du travail de composition. Un écran externe 4K ou 5K — surtout lorsqu’il est mis à l’échelle sur une résolution non native — multiplie la charge par image. Deux écrans externes 4K peuvent faire grimper WindowServer bien plus haut, en particulier sur les anciens Mac Intel, sur les configurations Apple Silicon de moindre puissance, et dans les modes mis à l’échelle (non natifs) qui nécessitent une passe de rendu supplémentaire.

3. Nombreuses fenêtres visibles ou contenu web lourd en graphismes

Chaque fenêtre visible — y compris chaque fenêtre de navigateur ouverte — est un ensemble distinct de couches Core Animation que WindowServer doit composer. Les onglets en arrière-plan dans les navigateurs modernes sont généralement suspendus et n’ajoutent pas directement de charge à WindowServer, mais les pages riches en vidéo, les contenus WebGL ou canvas, et les pages web animées (publicités à lecture automatique, animations CSS complexes) le font. Plusieurs dizaines de fenêtres visibles, ou quelques onglets exigeants, donnent à WindowServer nettement plus à suivre et à composer à chaque image.

4. Animations bloquées ou CALayers non libérés

Lorsqu’une application ne libère pas correctement ses ressources graphiques, WindowServer continue de les conserver et de les réévaluer. Cela se manifeste souvent par une montée lente du CPU sur plusieurs heures de fonctionnement, qui chute brusquement au moment où vous quittez l’application fautive.

5. Effets de transparence, de mouvement et de fond d’écran

Les fonds d’écran dynamiques de macOS et les effets de transparence et de mouvement du système passent tous par WindowServer. Sur les anciens Mac Intel, ou sur les Mac Apple Silicon avec une partie graphique intégrée déjà sollicitée, ces effets peuvent devenir disproportionnellement coûteux.

6. Bugs de macOS ou des pilotes GPU

Plusieurs fuites de mémoire et de CPU de WindowServer ont été documentées dans diverses versions intermédiaires de macOS au fil des ans. Si vous venez de mettre à jour et que le pic est apparu immédiatement, consultez les notes de version d’Apple et le forum Apple Discussions pour cette version précise.

Comment trouver le véritable coupable

Activity Monitor est le point de départ naturel et s’est amélioré au fil des versions récentes de macOS, mais il présente encore des lacunes pour ce problème spécifique. Il peut afficher l’activité GPU globale (Fenêtre → Historique GPU) et une colonne %GPU pour les processus utilisant le GPU, mais il ne vous donne pas une tendance GPU continue par processus alignée sur la chronologie de WindowServer, et il ne relie pas une fenêtre à l’écran au processus qui la possède. Ces deux éléments sont précisément ce dont vous avez besoin.

Étape 1 : gains rapides dans Activity Monitor

Ouvrez Activity Monitor → onglet CPU. Triez par CPU. Notez le pourcentage de WindowServer. Ouvrez Fenêtre → Historique GPU pour confirmer si la charge GPU globale est élevée. Si vous pouvez voir une colonne %GPU sur les processus, triez par celle-ci pour repérer le plus gros consommateur GPU à cet instant.

Cela vous indique que le symptôme est réel et pointe vers les applications gourmandes en graphismes, mais vous devez encore corréler avec WindowServer dans le temps et confirmer quelles fenêtres d’application sont responsables.

Étape 2 : identifiez l’application en amont avec ProcXray

ProcXray est conçu spécifiquement pour ce type de diagnostic multi-ressources :

Pour la comparaison plus large des limites d’Activity Monitor pour ce type de débogage, voir ProcXray vs Activity Monitor.

Étape 3 : test A/B en quittant les suspects

Une fois que vous avez un ou deux suspects, quittez-les un à un et observez la chute du CPU de WindowServer. Cela confirme la cause sans redémarrer ni interrompre votre session complète.

Solutions étape par étape

Appliquez-les dans l’ordre — d’abord les moins coûteuses et les moins perturbantes.

1. Quittez l’application suspecte

Une fois le processus en amont identifié, quittez-le. Rouvrez-le proprement si vous en avez besoin. Cela résout immédiatement la majorité des pics de WindowServer.

2. Déconnectez les écrans externes en tant que diagnostic

Si vous ne pouvez pas isoler une application précise, déconnectez un écran externe et surveillez le CPU. Si WindowServer chute fortement, les écrans sont le coût dominant. Vous pouvez alors soit réduire la résolution, soit faire fonctionner l’écran externe à sa résolution native (sans mise à l’échelle), soit le laisser déconnecté lorsque vous n’en avez pas besoin.

3. Réduisez la transparence et le mouvement

Les deux réglages déplacent le travail de composition de WindowServer vers des chemins de dessin plus simples. Gratuit, réversible, et souvent perceptible sur les Mac à graphismes intégrés :

4. Désactivez l’accélération matérielle dans les applications gourmandes en GPU

Dans Chrome : Paramètres → Système → désactivez « Utiliser l’accélération graphique si disponible », puis redémarrez Chrome. Des options similaires existent dans la plupart des applications Electron sous leurs propres paramètres. Cela déplace le rendu du GPU vers le CPU — cela peut corriger les pics de WindowServer au prix d’un CPU légèrement plus élevé dans l’application elle-même.

5. Fermez les fenêtres superflues et les pages lourdes en graphismes

La plupart des onglets en arrière-plan sont déjà suspendus et ne chargent pas directement WindowServer. Concentrez-vous plutôt sur la fermeture des fenêtres visibles dont vous n’avez pas besoin, la mise en pause des vidéos à lecture automatique ou des pages animées, et l’arrêt des démos WebGL ou canvas encore actives dans une fenêtre d’arrière-plan. Si vous gardez habituellement plusieurs fenêtres de navigateur ouvertes, consolider les onglets dans moins de fenêtres aide également.

6. Déconnectez-vous puis reconnectez-vous

Se déconnecter termine WindowServer proprement et le relance avec un état neuf — sans redémarrage complet. Cela résout souvent les cas de couches bloquées que la fermeture d’applications individuelles n’a pas pu attraper.

7. Mettez à jour macOS et l’application suspecte

Si une mise à jour récente de macOS ou de l’application a précédé le problème, vérifiez s’il existe un correctif ultérieur. Apple a publié à plusieurs reprises des correctifs intermédiaires pour des fuites de WindowServer.

8. En dernier recours : redémarrer, et uniquement sur les anciens Mac Intel une réinitialisation du SMC

Un redémarrage complet réinitialise WindowServer et l’état du pilote GPU. Si la même charge de travail déclenche encore le pic après redémarrage, la cause est en amont — pas un état transitoire — et vous devriez vous concentrer sur l’identification de l’application responsable plutôt que sur d’autres réinitialisations système. Sur les anciens Mac Intel uniquement, une réinitialisation du SMC peut occasionnellement aider si des symptômes d’affichage ou de gestion de l’alimentation persistent en parallèle de la charge de WindowServer ; les Mac Apple Silicon n’ont pas de réinitialisation SMC accessible à l’utilisateur, et ce n’est de toute façon que rarement la bonne solution pour un problème de WindowServer.

Pour un triage de performance plus général lorsqu’aucun suspect précis ne se dégage, voir comment réparer un Mac lent en arrêtant les bons processus.

FAQ

Puis-je arrêter ou désactiver WindowServer ?

Non. WindowServer fait fonctionner toute votre session graphique. Le forcer à quitter vous déconnecte instantanément, faisant perdre tout travail non enregistré. macOS le relance automatiquement à votre reconnexion. Il n’existe aucun moyen pris en charge de le désactiver.

Une utilisation CPU élevée de WindowServer endommage-t-elle mon Mac ?

Pas directement. Une utilisation CPU élevée soutenue augmente la chaleur et raccourcit l’autonomie de la batterie, mais le fait que WindowServer accomplisse ce travail n’est pas un risque matériel. La préoccupation plus profonde est ce qui le fait travailler aussi dur — une application incontrôlable qui vide la batterie est le véritable coût.

Pourquoi WindowServer utilise-t-il autant de mémoire ?

WindowServer met en cache les couches rendues de chaque application visible pour rendre la composition rapide. L’utilisation de la mémoire augmente avec le nombre de fenêtres, la résolution de vos écrans et la durée d’exécution de la session. Plusieurs gigaoctets après une longue durée de fonctionnement n’a rien d’inhabituel. Si la mémoire croît sans limite, suspectez un cas de couche non libérée (cause n° 4 ci-dessus) et déconnectez-vous puis reconnectez-vous.

Pourquoi s’emballe-t-il uniquement quand je branche un écran externe ?

L’ajout d’un écran externe augmente le travail de composition par image proportionnellement à sa résolution. Un écran externe 4K double ou triple à peu près le nombre de pixels que WindowServer doit composer à chaque image. Si le pic est important, essayez de faire fonctionner l’écran externe à sa résolution native — les modes à l’échelle sont nettement plus coûteux car ils nécessitent une passe de rendu supplémentaire.

Redémarrer corrige-t-il définitivement l’utilisation CPU élevée de WindowServer ?

Uniquement si la cause sous-jacente est une fuite transitoire. Un redémarrage réinitialise WindowServer à un état propre, mais si vous rouvrez la même application ou rebranchez le même écran, le pic revient. La vraie solution est d’identifier la cause en amont ; le redémarrage est une remise à zéro, pas un traitement.

Sources et références


Télécharger ProcXray gratuitement → — trouvez l’application qui fait réellement travailler WindowServer. macOS Sonoma+, Apple Silicon & Intel.