Pomiar czasu ładowania strony przy użyciu JavaScript

Question

Utworzono skrypt w JavaScript, który jest wstrzykiwany do naszej aplikacji Ext JS podczas automatycznego testowania przeglądarki. Skrypt mierzy czas potrzebny do załadowania danych w naszych sieciach.

W szczególności skrypt odpytuje każdą siatkę, sprawdza, czy istnieje pierwszy wiersz lub komunikat "brak danych", a gdy wszystkie sieci spełnią ten warunek, skrypt zapisuje wartość między Date.now() a wydajnością .timing.fetchStart i traktuje to jako czas załadowania strony.

Ten skrypt działa mniej więcej zgodnie z oczekiwaniami, jednak w porównaniu z czasem mierzonym przez człowieka (stoper Google ftw) czas zgłoszony w tym teście jest stale o około 300 milisekund dłuższy niż w przypadku pomiaru za pomocą stopera.

Moje pytania są następujące:

• Czy istnieje dziura w tym logiki, który mógłby prowadzić do błędnych wyników?
• Czy istnieją alternatywne i dokładne sposoby osiągnięcia tego pomiaru ?

Scenariusz jest następujący:

function loadPoll() { 
    var i, duration, 
     dataRow = '.firstRow', noDataRow = '.noData', 
     grids = ['.grid1', '.grid2', '.grid3','.grid4', 'grid5', 'grid6', 'grid7']; 

    for (i = 0; i < grids.length; ++i) { 
      var data = grids[i] + ' ' + dataRow, 
      noData = grids[i] + ' ' + noDataRow; 

     if (!(document.querySelector(data) || document.querySelector(noData))) { 
      window.setTimeout(loadPoll, 100); 
      return; 
     } 
    } 

duration = Date.now() - performance.timing.fetchStart; 
    window.loadTime = duration; 
} 

loadPoll(); 

kilka uwag:

• Chociaż zdaję sobie sprawę, że czas reakcji człowieka może być powolne, jestem pewien że niespójność 300 milisekund nie jest wprowadzany przez ludzki czynnik związany ze stoperem Google.

• Patrząc na kod może się wydawać, że odpytywanie wielokrotności elementów może prowadzić do niespójności 300 ms, jednak gdy zmienić liczbę elementów są monitorowane od 7 do 1, nadal wydaje się być Nadwyżka 300 ms w czasie podanym w automatycznym teście .

• Nasze testy automatyczne są wykonywane w ramach kontrolowanych przez Selen i kątomierz.

Z góry dziękuję, jeśli jesteście w stanie zapewnić jakikolwiek wgląd w to!

Answer 1

Jeśli używasz performance.now(), czas powinien być dokładny do 5 mikrosekund. Według MDN:

Sposób

performance.now() zwraca DOMHighResTimeStamp mierzona w milisekundach, z dokładnością do tysięcznych części pięciu milisekund (5 mikrosekundy).

Zwrócona wartość reprezentuje czas, jaki upłynął od czasu pochodzenia (właściwość PerformanceTiming.navigationStart).

Answer 2

Gdybym był tobą, skorygowałbym moje podejście do tego, jak uchwycono faktyczny pomiar czasu. Zamiast oceniać czas dla każdego wywołania loadPoll(), możesz ocenić, ile połączeń możesz wykonać przez określony czas.Innymi słowy, możesz liczyć liczbę iteracji funkcji przez dłuższy czas, np. 1000 milisekund. Oto, jak można to zrobić:

var timeout = 1000; 
var startTime = new Date().getTime(); 
var elapsedTime = 0; 

for (var iterations = 0; elapsedTime < timeout; iterations++) { 
    loadPoll(); 
    elapsedTime = new Date().getTime() - startTime; 
} 

// output the number of achieved iterations 
console.log(iterations); 

Takie podejście zapewni bardziej spójne i dokładne oszacowanie czasu. Szybsze systemy po prostu uzyskają większą liczbę iteracji. Należy pamiętać, że setInterval()/setTimeout() nie są idealnie precyzyjne, a dla naprawdę małych interwałów czasowych te funkcje mogą dawać nieprawidłowe wyniki ze względu na usuwanie śmieci, żądania ze zdarzeń i wiele innych rzeczy, które mogą działać równolegle, podczas gdy twój kod jest wykonany.