performance - google - web developer tools




Profilage de l'inspecteur Web avec "Images": recherche de la cause des problèmes de performances lorsque rien n'apparaît dans la chronologie (2)

Je viens de regarder la session d'E / S de Google: Jank Busters: Construction d'applications Web performantes où les intervenants ont expliqué comment utiliser la nouvelle vue "Images" dans la chronologie de l'inspecteur Web Chrome.

Voici un exemple d'enregistrement que j'ai obtenu en faisant défiler sur une page que je développe:

Comme vous pouvez le voir, il y a d'énormes retards dans certaines images mais sans cause apparente dans la timeline (il y a de grands espaces entre les événements jaunes "Timer Fired"). Comment puis-je résoudre les problèmes de performances afin d'augmenter la fréquence d'images de manière cohérente?


Je vous recommande d'utiliser http://pagespeed.googlelabs.com

Il vous montrera en fait un détail complet de ce qui s'est passé quand la page a été chargée pour que vous sachiez où travailler ... (et je pense aussi que certaines informations pourraient manquer dans certains cas)

En outre, vous devez effectuer un profilage de la mémoire de la page pour voir combien de temps certains objets prennent pour être chargés dans la mémoire.


Votre exemple ne semble pas vraiment mauvais. Votre code s'exécute rapidement, et le navigateur ne rendra qu'à 60fps, donc il passe un peu de temps (jusqu'à 16ms) à attendre le prochain cycle de rendu.

Voici un aperçu particulièrement inquiétant de la vue Images du panneau Montage de Chrome Dev Tools.

Selon la documentation :

  • Les zones grises indiquent une activité qui n'a pas été instrumentée par DevTools, et l'équipe Chrome travaille pour garder cette zone aussi petite que possible
  • Les zones claires indiquent un temps d'inactivité entre les cycles d'actualisation de l'affichage, ce qui n'est généralement pas un problème, en particulier si la zone atteint la ligne 60fps, car Chrome attend simplement de pouvoir afficher une trame sur le vsync du moniteur

Les petites zones jaunes et vertes au bas des barres indiquent que la gestion des événements, la peinture et la composition ont été assez rapides - assez rapides pour tomber sous la ligne horizontale indiquant le seuil de 30fps, et probablement plus vite que le seuil de 60fps l'heure (ligne non montrée)

Pour en savoir plus, ouvrez les options des outils de développement et vérifiez:

Avec cette option activée, vous verrez les régions grises dans la barre 'RECORDS':

Chaque région grise montre une période pendant laquelle le thread de rendu a été occupé. Si vous voyez de nombreuses lacunes, le navigateur est probablement lié au GPU.

Nat Duca, un ingénieur sur Chrome, fournit plus d'informations dans ce post :

La limite du GPU vient typiquement de deux choses:

  1. ayant -webkit-filter, conserve les propriétés 3D sur les éléments. Ceux-ci mangent au gpu comme ... euh, quelque chose qui a faim.
  2. avoir trop de grandes couches.

Couches? "Afficher les bordures de calques composites" pour les voir. L'endroit où la plupart des gens ont des problèmes n'est pas vraiment le nombre de couches, mais plutôt la surface des couches.

Règle de base: la plupart des ordinateurs sont conçus pour pouvoir toucher chaque pixel de l'écran principal environ 4 fois. Un exemple très simple, un MacBook Air de 2 ans est fourni pour la taille de son écran LCD. Lorsque vous branchez un moniteur de 30 "qui a plus d'un calque, il commence à être lié au GPU.

Pourquoi est-ce important? [Handwaving], une couche touche un pixel une fois lorsque nous dessinons l'écran. Si une couche a la taille de votre fenêtre, par exemple vous avez une largeur = 100% height = 100% div avec -webkit-transform: translateZ (0), alors vous touchez chaque pixel de l'écran une fois. Donc, comptez la surface de vos couches et si vous dépassez 4 fois la surface de votre moniteur, vous ne pourrez peut-être pas aller dans l'espace [parce que vous êtes lié au GPU].

Un bon test pour la limite de gpu est de réduire la taille de la fenêtre de 1/2 dans chaque dimension. Si les choses restent lentes, alors il se passe quelque chose d'autre ... si les choses vont plus vite, vous frappez probablement le GPU.

Dans mon cas (montré dans l'image la plus en haut) j'essaie toujours de savoir ce qui cause les barres grises. Le code n'a pas changé, et les performances étaient géniales. Il se peut qu'une version plus récente de Chrome (aujourd'hui, je cours 31.0.1650.57 m) ne fonctionne pas aussi bien avec ce code pour une raison quelconque. Encore une fois, les zones grises indiquent que le thread de rendu était occupé avec du code non-instruit, donc il est difficile de dire ce qui se passait.