Google Lighthouse Speed ​​Index Définition de l'image à 100% complétée visuellement

Visuellement complet, c'est lorsque la page de la fenêtre cesse de changer. C'est à dire. les visuels ne changent pas.

Il est calculé en prenant des captures d'écran tout au long du chargement et en les comparant entre elles et à l'état final final. Donc oui dans votre exemple lorsque tous les nombres 1 à 100 sont imprimés et que la page cesse de changer, vous êtes "visuellement complet".

Donc, si une page charge rapidement les données affichées mais rend le contenu «sous la ligne de flottaison» (par exemple, les images hors écran) plus lentement, vous obtiendrez une vue visuelle rapide, même si le temps de chargement global de la page est encore long. / p>

De même, si la plupart du contenu à l'écran est dessiné tôt mais qu'une petite partie est dessinée plus tard (peut-être une option «cliquer pour discuter»), vous obtiendrez la plupart du temps visuellement complet et donc un bon indice de vitesse, même si ce n'est pas le cas aussi bon que l'exemple ci-dessus.

D'un autre côté, si vous chargez des polices, ou peut-être une grande image de héros, en dernier et qu'il redessine de grandes parties de la page en vue, vous obtiendrez un temps visuel complet lent et également un score d'index à vitesse lente.

Plus de détails ici: https: / /sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

Je viens de recevoir la réponse du contributeur du repo Lighthouse, veuillez vérifier ce lien les gars.

https://github.com/GoogleChrome/lighthouse/issues/8148

Phare

Selon la Description de Google de la vitesse du phare " Index "audit :

Lighthouse utilise un module de nœud appelé Speedline pour générer le score de l'indice de vitesse.

envoie Speedline

Le fichier readme Github de Speedline dit

L ' Speed ​​Index , introduit par WebpageTest.org , vise à résoudre ce problème. Il mesure à quelle vitesse le contenu de la page est affiché visuellement . La mise en œuvre actuelle est basée sur la méthode de calcul Progression visuelle à partir de la capture vidéo décrite sur le Page Speed ​​Index . La progression visuelle est calculée en comparant la distance entre l'histogramme de l'image courante et l'image finale.

(Italique à moi.)

une chronologie des peintures

La page Speed ​​Index va dans détail douloureux sur la façon dont la progression visuelle est calculée . Voici un extrait:

Dans le cas des navigateurs basés sur Webkit, nous collectons les données de la chronologie qui incluent les rects de peinture ainsi que d'autres événements utiles.

Je pense que les "données de chronologie" font référence à un objet JSON récupéré via la Chronologie des performances API .

Il semble que Lighthouse transmette la chronologie JSON à Speedline, qui extrait un tableau de" frames ", décrivant les événements de peinture du chargement de la page:

/**
 * @param {Frame} current
 * @param {Frame} initial
 * @param {Frame} target
 */
function calculateFrameProgress(current, initial, target) {
    let total = 0;
    let match = 0;

    const currentHist = current.getHistogram();
    const initialHist = initial.getHistogram();
    const targetHist = target.getHistogram();

    for (let channel = 0; channel < 3; channel++) {
        for (let pixelVal = 0; pixelVal < 256; pixelVal++) {
            const currentCount = currentHist[channel][pixelVal];
            const initialCount = initialHist[channel][pixelVal];
            const targetCount = targetHist[channel][pixelVal];

            const currentDiff = Math.abs(currentCount - initialCount);
            const targetDiff = Math.abs(targetCount - initialCount);

            match += Math.min(currentDiff, targetDiff);
            total += targetDiff;
        }
    }

    let progress;
    if (match === 0 && total === 0) {   // All images are the same
        progress = 100;
    } else {                                                    // When images differs
        progress = Math.floor(match / total * 100);
    }
    return progress;
}

qui calcule les histogrammes h2>

Speedline convertit les données d'image de chaque événement de peinture en un histogramme d'image , ce qui est intéressant excluant les pixels qui sont "suffisamment proches" pour passer pour du blanc:

// find visually complete
for (let i = 0; i < frames.length && !visuallyCompleteTs; i++) {
    if (frames[i][progressToUse]() >= 100) {
        visuallyCompleteTs = frames[i].getTimeStamp();
    }
}

Le calcul et la comparaison des histogrammes font beaucoup de maths. Le responsable du projet est la bonne personne pour demander à ce sujet. Mais c'est là que la détermination du "visuellement complet "arrive :

/**
 * @param {number} i
 * @param {number} j
 * @param {ImageData} img
 */
function isWhitePixel(i, j, img) {
    return getPixel(i, j, 0, img.width, img.data) >= 249 &&
            getPixel(i, j, 1, img.width, img.data) >= 249 &&
            getPixel(i, j, 2, img.width, img.data) >= 249;
}

et déduit" progression ",

La" progression "d'une image donnée semble être calculée par cette fonction :

/**
 * @param {string|Array<TraceEvent>|{traceEvents: Array<TraceEvent>}} timeline
 * @param {Options} opts
 */
function extractFramesFromTimeline(timeline, opts) {

et "visuellement complet" est la première image avec une progression de 100%.

Sans auditer complètement le code, mon interprétation est que le "visuellement image complète "est la première image calculée pour avoir la même différence totale par rapport à l'image initiale que l'image finale (qui est déterminée par quelles images Lighthouse choisit d'envoyer à Speedline ).

Ou, en d'autres termes, c'est compliqué .