Nowy serwis testujący TTFB stron internetowych webspeed.pl

[sebak]

@Tom X to nie subdomena, ale średnia z wszystkich stron wordpress dla home.pl . Trzeba było użyć jakiegoś klucza, pod którym moglibyśmy zapisywać te dane.

 

Tutaj mamy problem i w sumie nie wiem jeszcze jak do niego podejść. Co innego przedziały dla konkretnej witryny, a co innego średnia per operator. Stosując się do tych samych wytycznych tu i tu, żaden operator nie załapałby się na kolor zielony, mimo iż około 22% stron Wordpress i 52% Prestashop wczytuje się poniżej 400 ms. Obecne przedziały dla operatorów to:

 

0-750 ms - szybko

750 ms - 1,5 sekundy - średnio

powyżej 1,5 sekundy - wolno

 

Jesteśmy otwarci na wszelkie propozycje, więc jeśli masz pomysł jak to najlepiej rozwiązać, z chęcią skorzystamy.

[Tom X]

Chodzi mi o średnią per operator, która w dwóch miejscach dla konkretnego operatora oznaczona jest różnymi kolorami (załączniki).

"Stosując się do tych samych wytycznych tu i tu, żaden operator nie załapałby się na kolor zielony" - to zrozumiałe.

[sebak]

@Tom X zerknij na to w wolnej chwili, zostało to zmienione zgodnie z Twoją sugestią. Dzięki.

[Tom X]

Zerknąłem. Skale wydajności per operator są ujednolicone. OK.
Co by się stało, gdyby skala per operator była ujednolicona ze skalą per storna? Tam są cztery kolory i cztery zakresy, domyślam się, że zakres zielony byłby nie do zdobycia w rankingu per operator, pozostają trzy zakresy (obecnie też są trzy). 

[sebak]

 

2 godziny temu, Tom X napisał(a):

Co by się stało, gdyby skala per operator była ujednolicona ze skalą per storna?

 

Żaden operator nie spada poniżej 500ms z średnią, wiec każdy byłby pomarańczowy lub czerwony. 

 

Z racji na filtrowanie rankingów łatwiej zastosować per operator 3 progi, bo łatwo można je opisać: szybko, wolno, średnio. Podobnie jak sortowanie po zmianie ilości obsługiwanych domen, tez ma 3 progi: wzrost, spadek, bez zmian.

[Tom X]

Tylko, że to IMO nie działa poprawnie. Zerknij na dane liczbowe, kolorystykę tła, kierunek i kolor strzałki, komentarz (SZYBKO, MOGŁO BYĆ LEPIEJ) z załączonych grafik.

 

Inny zakres skali per operator wydaje się racjonalny, natomiast posłużenie się identyczną kolorystyką może nadal wprowadzać w błąd. Ktoś, kto nie kliknie  w "zegar" w rankingach per operator i nie zapozna się z odmiennie zdefiniowanymi przedziałami, jest gotów uznać, że operatorzy oznaczeni kolorem zielonym posiadają kosmiczną infrastrukturę, w której strony osiągają średnie wyniki mieszczące się w 400 ms (zgodnie ze skalą per domena). Ja tak uznałem, dopóki nie zacząłem drążyć, stąd dyskusja. Może warto opisać odmiennie zdefiniowane przedziały na każdej stronie rankingu per operator (np. w ramce "Filtrowanie danych"), żeby nie było nieporozumień.

[sebak]

2 godziny temu, Tom X napisał(a):

Tylko, że to IMO nie działa poprawnie. Zerknij na dane liczbowe, kolorystykę tła, kierunek i kolor strzałki, komentarz (SZYBKO, MOGŁO BYĆ LEPIEJ) z załączonych grafik.

 

Faktycznie, naprawione. Dzięki za czujność.

[Tom X]

Znakomicie. Oczywiście nie oczekiwałem i na przyszłość: nie oczekuję, że zajmiecie się obsługą sugestii od ręki, w dni wolne od pracy

[sebak]

To właśnie różni projekty hobbistyczne, od komercyjnych, że tutaj zmian zazwyczaj dokonuje się w dni wolne i po pracy .

 

 

[Maxx]

@sebak Wyjaśnisz mi proszę, jak to jest możliwe że 21 % stron ładuje się szybciej niż 369 ms, podczas gdy tylko 5 % ładuje się szybciej niż 436 ms ?

 

 

Ponadto:

1. Nie jest jasne, czy pomiary zostały dokonane przy użyciu HTTPS czy HTTP.
2. Na wykresie z 10 dni, nie ma wyników z CACHE, które są na wykresie z 3 m-cy
3. Domyślnie powinien być przedstawiony wynik z CACHE + informacja o tym fakcie, lub oba, gdyż również nie jest jasne czego średnia się tyczy w przypadku gdy CACHE jest włączone.
4. Przy wykryciu zmiany hostingu, nie sprawdzacie czy pod domeną jest ta sama zawartość, czego efektem jest np. 30 KB przed zmianą i 60 KB po zmianie i nie wiadomo czy wynika to ze zmiany zawartości, szablonu, wtyczek czy choćby z włączonej kompresji GZIP a wszystko wymienione. A ma to wpływ na wynik podobnie jak użycie HTTPS zamiast HTTP.

 

[sebak]

15 godzin temu, Maxx napisał(a):

@sebak Wyjaśnisz mi proszę, jak to jest możliwe że 21 % stron ładuje się szybciej niż 369 ms, podczas gdy tylko 5 % ładuje się szybciej niż 436 ms ?

 

Ranking jest generowany na podstawie ostatniego sprawdzenia. Zobacz wykres 10 dniowy i będziesz wiedział skąd takie miejsce w rankingu w danej chwili.

 

15 godzin temu, Maxx napisał(a):

• Nie jest jasne, czy pomiary zostały dokonane przy użyciu HTTPS czy HTTP.

 

Pomiar zawsze jest wykonywany z użyciem domyślnie stosowanego protokołu. Jeśli strona przekierowuje na https, to leci po https, jeśli po wejściu na domenę.pl ładuje się strona http, leci po http.

 

15 godzin temu, Maxx napisał(a):

• Na wykresie z 10 dni, nie ma wyników z CACHE, które są na wykresie z 3 m-cy

 

Wykresy cache są mniej ważne i zbierane z mniejsza częstotliwością. Dlatego też są widoczne tylko z wartościami uśrednionymi dziennymi.

 

15 godzin temu, Maxx napisał(a):

• Domyślnie powinien być przedstawiony wynik z CACHE + informacja o tym fakcie, lub oba, gdyż również nie jest jasne czego średnia się tyczy w przypadku gdy CACHE jest włączone.

 

Wartości cache są podglądowe i z naszego punktu widzenia dużo mniej istotne. Badamy wydajność stron, a tutaj chcemy mieć wyniki które są powtarzalne, a te uzyskujemy tylko odpytując o nie cachowane dane.

 

16 godzin temu, Maxx napisał(a):

• Przy wykryciu zmiany hostingu, nie sprawdzacie czy pod domeną jest ta sama zawartość, czego efektem jest np. 30 KB przed zmianą i 60 KB po zmianie i nie wiadomo czy wynika to ze zmiany zawartości, szablonu, wtyczek czy choćby z włączonej kompresji GZIP a wszystko wymienione. A ma to wpływ na wynik podobnie jak użycie HTTPS zamiast HTTP

Codziennie odpytujemy 2 mln stron, więc musimy iść na pewne uproszczenia. Z naszego punktu widzenia, nie ma znaczenia czy strona jest taka sama, czy nie. Większość stron jest dynamicznie generowana z dynamicznym kontentem, więc porównywanie ich mijałby się z celem. Rozmiar daje podgląd obrazowy na to co się dzieje, czy nie mieliśmy przypadku przejścia z strony na np. zaślepkę.

[Maxx]

1 godzinę temu, sebak napisał(a):

Ranking jest generowany na podstawie ostatniego sprawdzenia. Zobacz wykres 10 dniowy i będziesz wiedział skąd takie miejsce w rankingu w danej chwili.

 

Nie chodzi mi o miejsce w rankingu ale kwestię że ilość szybszych stron jest podawana błędnie. Gdyż nie jest możliwe aby aż 21 % stron ładowało się szybciej niż 369 ms i jednocześnie aby tylko 5 % ładowała się szybciej  od znacznie dłuższego czasu ładowania tj. 436 ms.  Gdyż jest oczywiste, że ze wzrostem czasu ładowania coraz więcej stron jest szybszych a nie na odwrót jak na przytoczonym przykładzie.

 

 

1 godzinę temu, sebak napisał(a):

Pomiar zawsze jest wykonywany z użyciem domyślnie stosowanego protokołu.

 

To można się dowiedzieć z metodologii opisanej na stronie. Ale jaki został użyty protokół należało by uwzględnić w prezentowanych wynikach gdyż wpływa to na prezentowany wynik.

 

 

1 godzinę temu, sebak napisał(a):

Wykresy cache są mniej ważne i zbierane z mniejsza częstotliwością. Dlatego też są widoczne tylko z wartościami uśrednionymi dziennymi.

 

2 godziny temu, sebak napisał(a):

Wartości cache są podglądowe i z naszego punktu widzenia dużo mniej istotne. Badamy wydajność stron, a tutaj chcemy mieć wyniki które są powtarzalne, a te uzyskujemy tylko odpytując o nie cachowane dane.

 

Jeśli komuś zależy na szybkości strony - hostingu nie zmienia po to by jarać się czasem generowania strony ale by jego klientom strona ładowała się jak najszybciej. A w przypadku WP bez użycia CACHE nie jest możliwe zejść do max kilkudziesięciu ms z TTFB które ma kluczowe znaczenie dla szybkości wczytywania strony. Ponadto cache generowane jest raz i w rzeczywistym świecie to właśnie z niego serwowane są odsłony.  I dlatego nie należy podchodzić lekceważąco do tego, co ma naprawdę duże znaczenie. 

 

Jeśli z kolei chodzi o wydajność - wrzucacie do jednego wora hostingi za kilka złotych oraz VPS-y i dedyki za kilka stów co przy braku informacji z czego korzysta dana strona jest mówiąc delikatnie - mało przydatne gdy dany dostawca oferuje wiele rozwiązań. A to z kolei podwyższa średni wynik dla największego dziadostwa i obniża dla wysokiej klasy rozwiązań.

 

Podsumowywując:

Jeśli chcecie iść obraną drogą - to idźcie, gdyż zostawia to lukę na bardziej profesjonalne rozwiązania uwzględniające bardzo dokładną metodologię pomiaru u źródła poprzez zastosowanie identycznej metodologii oraz biorąc pod uwagę różnorodność rozwiązań oferowanych przez poszczególnych dostawców oraz zasobność kieszeni klienta. Z kolei Wasze narzędzie będzie świetnym narzędziem marketingowym w przypadku WP. Zwłaszcza jeśli chodzi o osiągane wyniki

 

[sebak]

45 minut temu, Maxx napisał(a):

Nie chodzi mi o miejsce w rankingu ale kwestię że ilość szybszych stron jest podawana błędnie. Gdyż nie jest możliwe aby aż 21 % stron ładowało się szybciej niż 369 ms i jednocześnie aby tylko 5 % ładowała się szybciej  od znacznie dłuższego czasu ładowania tj. 436 ms.  Gdyż jest oczywiste, że ze wzrostem czasu ładowania coraz więcej stron jest szybszych a nie na odwrót jak na przytoczonym przykładzie.

 

 

Nie zrozumieliśmy się, więc jeszcze raz dokładnie. Wartości które przytoczyłeś, dotyczą średniej z doby, a ranking jest generowany na podstawie ostatniego odpytania (odbywającego się co 2h). Wynik tego odpytania znajdziesz w wykresie 10 dniowym.

 

47 minut temu, Maxx napisał(a):

To można się dowiedzieć z metodologii opisanej na stronie. Ale jaki został użyty protokół należało by uwzględnić w prezentowanych wynikach gdyż wpływa to na prezentowany wynik.

 

Dodam to przemyślenie do listy rzeczy które moża dołożyć.

 

48 minut temu, Maxx napisał(a):

Jeśli komuś zależy na szybkości strony - hostingu nie zmienia po to by jarać się czasem generowania strony ale by jego klientom strona ładowała się jak najszybciej. A w przypadku WP bez użycia CACHE nie jest możliwe zejść do max kilkudziesięciu ms z TTFB które ma kluczowe znaczenie dla szybkości wczytywania strony. Ponadto cache generowane jest raz i w rzeczywistym świecie to właśnie z niego serwowane są odsłony.  I dlatego nie należy podchodzić lekceważąco do tego, co ma naprawdę duże znaczenie. 

 

Nie będę przytaczał konkretnych firm, ale czasem strona z cache działa wolniej u złego operatora, niż strona bez cache u innego. Dużo zależy od sposobu cache, oraz ogólnej infrastruktury operatora. Na przykładzie WordPress, gdzie masz różnych redaktorów, to co im z szybko działającego indeksu, jak panel administratora w którym pracują ładuje się wieczność uniemożliwiając pracę. Nie podchodzimy lekceważąco do cache, dlatego też w przypadku wykrycia cache masz podane dwie wartości czasu wczytywania strony. Niemniej domyślną wartością jest ta, którą uznaliśmy za bardziej ważną i porównywalną.

 

58 minut temu, Maxx napisał(a):

Jeśli z kolei chodzi o wydajność - wrzucacie do jednego wora hostingi za kilka złotych oraz VPS-y i dedyki za kilka stów co przy braku informacji z czego korzysta dana strona jest mówiąc delikatnie - mało przydatne gdy dany dostawca oferuje wiele rozwiązań. A to z kolei podwyższa średni wynik dla największego dziadostwa i obniża dla wysokiej klasy rozwiązań.

 

Nawet wychodząc z założenia, że masz rację, to % udziału serwerów VPS i serwerów dedykowanych do hostingu współdzielonego to maksymalnie 5%. Jest to skala pomijalna przy tej liczbie domen.

[Maxx]

3 godziny temu, sebak napisał(a):

Nie zrozumieliśmy się, więc jeszcze raz dokładnie. Wartości które przytoczyłeś, dotyczą średniej z doby, a ranking jest generowany na podstawie ostatniego odpytania (odbywającego się co 2h). Wynik tego odpytania znajdziesz w wykresie 10 dniowym.

 

Jak sam widzisz, na stronie macie dużo niejasnych kwestii wprowadzających użytkownika w błąd, jak na przykładzie powyżej. Dodatkowo przy aktualizowaniu tylko części domen co 2h tenże ranking  (ile stron wczytuje się szybciej/wolniej) to jeden wielki chaos i nieporozumienie. Ale to Wasza piaskownica, więc możecie prezentować dane jak tylko zechcecie. Jednak musicie wziąść pod uwagę, iż nie wszyscy użytkownicy przeglądają wspomniany wykres, który w dodatku domyślnie pokazuje dane z 3-ch miesięcy a nie 10 dni, o czym wspominałem już wcześniej i co tylko pogłębia wspomniany chaos.

 

 

3 godziny temu, sebak napisał(a):

Nie będę przytaczał konkretnych firm, ale czasem strona z cache działa wolniej u złego operatora, niż strona bez cache u innego. Dużo zależy od sposobu cache, oraz ogólnej infrastruktury operatora. 

 

Zgadza się i dlatego właśnie informacja o CACHE jest tak istotna. Gdyż nie wszyscy dostawcy dzielonego hostingu nadają się do używania cache. Wady tej (niezależnie od usługodawcy) pozbawione są serwery VPS/dedyki nawet w najtańszych wariantach. Gdyż umożliwiają one wykorzystanie do cache RAM-u przy którym dyski Optane a nawet najnowsze dyski NVMe na PCIe 5.0 to stare rupiecie jeśli chodzi o wydajność w porównaniu do możliwości jakie daje RAM. Gdyż nawet procesory 3-ej generacji z przed dekady oferują przepustowość pamięci RAM na poziomie 25.6 GB/s a nawet dwukrotnie wyższą przy 4 kanałowym kontrolerze pamięci.

Ponadto CACHE to nie tylko szybkość ale i znakomita obrona przed atakami, gdzie przy zajęciu procesora na 500 ms generowaniem strony WP można obsłużyć zaledwie 2 odsłony na sekundę przy 1 vCPU a w przypadku CACHE nawet i 1,000 na sekundę. Co przy 16 rdzeniowej maszynie daje możliwość obsłużenia ponad 1 MILIARD odsłon na dobę jeśli tylko kombinacja wielkości strony i przepustowość sieci na to pozwoli.

 

Dlatego właśnie profesjonaliści korzystający z WP używają CACHE a amatorzy szukają szybszych procesorów których stronki WP bez CACHE i tak można skutecznie zarżnąć już kilkudziesięcioma zapytaniami na sekundę. Że już o szybkim osiągnięciu progów bezpieczeństwa nie wspomnę.

A jak progi bezpieczeństwa zostaną osiągnięte, to @itomek powie: Kup pan większy pakiet który zwiększy wydajność 2 krotnie, zamiast powiedzieć: włącz pan CACHE i zwiększ wydajność nawet 1,000 KROTNIE.  A jeszcze inny "spec" od optymalizacji powie: zoptymalizuj pan obrazki i  zyskaj 5 %

 

Edytowane 7 Grudnia 2023 przez Maxx

[sebak]

17 godzin temu, Maxx napisał(a):

Jak sam widzisz, na stronie macie dużo niejasnych kwestii wprowadzających użytkownika w błąd, jak na przykładzie powyżej

 

Nie uważam tak, ale masz oczywiście prawo do własnego zdania.

 

17 godzin temu, Maxx napisał(a):

Dodatkowo przy aktualizowaniu tylko części domen co 2h tenże ranking  (ile stron wczytuje się szybciej/wolniej) to jeden wielki chaos i nieporozumienie. Ale to Wasza piaskownica, więc możecie prezentować dane jak tylko zechcecie. Jednak musicie wziąść pod uwagę, iż nie wszyscy użytkownicy przeglądają wspomniany wykres, który w dodatku domyślnie pokazuje dane z 3-ch miesięcy a nie 10 dni, o czym wspominałem już wcześniej i co tylko pogłębia wspomniany chaos.

 

Wszystkie domeny odpytujemy co 2 godziny o dane i takie dane też są wyświetlane na stronie każdej domeny. Wskaźnik (ranking) szybciej/wolniej nie mówi o konkretnej pozycji, tylko przedziale w którym strona się znajduje. Ranking dla domeny nie służy do dokładnego monitorowania swojej pozycji, ale do orientacyjnej korelacji prędkości strony w kontekście użytego rozwiązania.

 

17 godzin temu, Maxx napisał(a):

Dlatego właśnie profesjonaliści korzystający z WP używają CACHE a amatorzy szukają szybszych procesorów których stronki WP bez CACHE i tak można skutecznie zarżnąć już kilkudziesięcioma zapytaniami na sekundę. Że już o szybkim osiągnięciu progów bezpieczeństwa nie wspomnę.

 

Rynek hostingowy w 80-90% dotyczy nie profesjonalistów... Cache to cudowne narzędzie, jeśli umiesz je prawidłowo wykorzystać. Ostatnio robiliśmy badanie ile osób korzysta z super fajnych rozwiązań od Litespeeda. Cache od Litespeed'a jest zaimplementowany tylko na 51 637 stronach, co daje jakieś 2,5% domen które wykorzystują to rozwiązanie. Cache jest fajny, ale dla stron gdzie masz 2 odwiedzających dziennie, nie specjalnie ma to sens...

[Maxx]

W dniu 7.12.2023 o 20:55, sebak napisał(a):

Wszystkie domeny odpytujemy co 2 godziny o dane ...

 

Myślę że, nie bardzo to jest możliwe nie mając wpisanych na białą listę przez usługodawców IP z których skanujesz strony. Gdyż na niektórych IP jest nawet kilkadziesiąt tysięcy domen a dodając do tego kilka zapytań o każdą domenę - z automatu otrzymałbyś bana. Zgadza się ? 

 

 

 

W dniu 7.12.2023 o 20:55, sebak napisał(a):

Cache od Litespeed'a jest zaimplementowany tylko na 51 637 stronach, co daje jakieś 2,5% domen które wykorzystują to rozwiązanie

 

Jaki daje to realny zysk w przypadku WP ? Możesz podać jakieś dane porównawcze, odnośnie TTFB przy wykorzystaniu tego rozwiązania jak i przy jego braku ? 

 

 

 

W dniu 7.12.2023 o 20:55, sebak napisał(a):

Cache jest fajny, ale dla stron gdzie masz 2 odwiedzających dziennie, nie specjalnie ma to sens...

Cache w przypadku WP zawsze ma sens. Gdyż nawet jak ze strony ludzi byłoby ZERO wizyt - obciążenie generują wszelakiej maści boty, a czym większa strona tym ruch przez nie generowany jest większy. Dzięki temu na tym samym hostingu/serwerze swobodnie można trzymać znacznie więcej stron niż w przypadku gdy cache nie jest używany. Gdyż WP nie został napisany by być wydajnym a uniwersalnym i przez tą uniwersalność jest bardzo zasobożerny. I dlatego cache w przypadku WP zalicza się do kategorii "must have".  

 

[sebak]

4 godziny temu, Maxx napisał(a):

Myślę że, nie bardzo to jest możliwe nie mając wpisanych na białą listę przez usługodawców IP z których skanujesz strony. Gdyż na niektórych IP jest nawet kilkadziesiąt tysięcy domen a dodając do tego kilka zapytań o każdą domenę - z automatu otrzymałbyś bana. Zgadza się ? 

 

Myślisz, czy wiesz? Bo my mamy taki projekt, który to robi i odpytuje wszystkie strony co 2 godziny. Jakimś cudem to działa i zbiera dane już około pół roku .

 

4 godziny temu, Maxx napisał(a):

Jaki daje to realny zysk w przypadku WP ? Możesz podać jakieś dane porównawcze, odnośnie TTFB przy wykorzystaniu tego rozwiązania jak i przy jego braku ? 

 

Takich statystyk nie mamy, mamy obecnie tylko listę domen, których to dotyczy. Na szybko mogę sprawdzić ile z tych domen to Wordpress - 41 667 domen. Zapuszczę obliczenie tego i wrócę z wynikami.

 

4 godziny temu, Maxx napisał(a):

Cache w przypadku WP zawsze ma sens. Gdyż nawet jak ze strony ludzi byłoby ZERO wizyt - obciążenie generują wszelakiej maści boty, a czym większa strona tym ruch przez nie generowany jest większy. Dzięki temu na tym samym hostingu/serwerze swobodnie można trzymać znacznie więcej stron niż w przypadku gdy cache nie jest używany. Gdyż WP nie został napisany by być wydajnym a uniwersalnym i przez tą uniwersalność jest bardzo zasobożerny. I dlatego cache w przypadku WP zalicza się do kategorii "must have".  

 

Z natury cache jest dobry, tam gdzie ma sens. Jeśli na stronę wchodzi 1 osoba dziennie, cache generuje więcej zachodu, niż pożytku. Takie jest moje zdanie. A praktyka mówi, że większość stron nie korzysta z dobrych praktyk, nawet jeśli one są i istnieją. 

 

EDIT:

 

Wracam z wynikami. Średni czas wczytywania się dla tych 41 667 domen wynosi:
786 ms z uwzględnieniem lscache i

2543 ms wymuszając wczytanie witryny bez cache

Edytowane 13 Grudnia 2023 przez sebak

[Tom X]

Pewna strona internetowa z uptime 99,2%, która czasami ładuje się kilka/naście sekund zanim się wyświetli.

"Tylko 17% witryn WordPress jest szybszych." - trudno uwierzyć.

Uzupełniam dane szczegółowe:

Średnia z 3 mc: 5 805 ms

Percentyl 95% z 3 mc: 9 240 ms

Średnia (cache) z 3 mc: 916 ms

Prośba o komentarz.

Edytowane 13 Lutego przez Tom X

[sebak]

@Tom X ostatni pomiar poszedł pewnie z jakiegoś cache. Całość działa na rankingach redisowych. Inaczej ciężko było by porównywać te wartości, przy tak dużej ilości domen. Ranking jest aktualizowany zawsze o ostatnią wartość która jest aktualnie pobrana przy sprawdzaniu czasu strony. Mam świadomość, że w takich sytuacjach jak ta, wygląda to "dziwnie", niemniej nie znalazłem żadnego sensownego rozwiązania tego problemu.

 

 

[Tom X]

Czemu nie porównujecie średniej z 10 dni, która wyklucza takie anomalie?

[sebak]

Średnia 10 dniowa nie istnieje nigdzie w naszej bazie danych, jest liczona w momencie serwowania strony. Co innego obliczyć średnią na bieżąco dla 1 strony, a co innego liczyć ją każdorazowo dla 2 mln domen. Zaś ranking redisowy działa na zasadzie przyporządkowania WARTOŚCI LICZBOWEJ do KLUCZA.  W prosty sposób możesz pobrać pozycje z rankingu, ale musisz podać istniejący KLUCZ. W naszym przypadku KLUCZEM jest domena, a WARTOŚCIĄ LICZBOWĄ czas jej wczytywania wyrażony w ms.

Edytowane 13 Lutego przez sebak

[Tom X]

Rozumiem. W takim razie może warto byłoby dodać skrócony opis metodologii do dymku wyświetlającego się pod literką (i), np. "Ranking w oparciu o pojedynczy ostatni odczyt" czy coś w tym stylu. Dla kogoś, kto nie wie jak ten ranking działa, lub na jakie skróty poszli autorzy z różnych względów, jego wartość jest skrajnie myląca o ile w ogóle wartościowa.

[sebak]

Jeśli pozycja w rankingu nie musi być aktualna, to mogę ją zamienić na średnią z doby poprzedzającej aktualną datę. Średnie dobowe i tak przeliczamy codziennie w godzinach nocnych, więc akurat na tą wartość mogę w prosty sposób podmienić ranking. Wtedy będzie miał dobowe opóźnienie, ale będzie bardziej stabilny emocjonalnie.

[Tom X]

Cząstkowe dane z odczytów dostępne są na wykresie, więc jeśli ktoś majstruje przy stronie, to zmiany zobaczy. Ranking dobowy byłby bardziej stabilny. Moim zdaniem - dobry pomysł, niewymagający rewolucji/przeciążania zasobów.

[sebak]

Zmiana została zaimplementowana.