Skocz do zawartości
  • Cześć!

    Witaj na forum RootNode - aby pisać u nas musisz się zarejestrować, a następnie zalogować. Posty pisane z kont niezarejestrowanych nie są widoczne publicznie.

Nowy serwis testujący TTFB stron internetowych webspeed.pl


Rekomendowane odpowiedzi

Opublikowano

Cześć,

 

przeszukując forum zdziwiłem się, że nie ma na nim żadnego oficjalnego wątku dotyczącego serwisu https://www.webspeed.pl/, który już jakiś czas temu był promowany przez  @theqkash na Facebooku, włączając w to promocję na grupie Hosting Polska, którą administruję. Dla osób, które dotychczas nie wiedziały o tym narzędziu wyjaśnię, że https://wwww.webspeed.pl ma dużą szansę stać się ciekawym elementem uzupełniającym wiedzę użytkowników o tym, jak szybko działa dana strona Internetowa, a także jak szybko działa dany hosting.

 

Reprezentując na forum nazwa.pl na wstępie podkreślę, że bardzo cieszymy się, że taki serwis, jak webspeed.pl, powstał. Te osoby, które czytają moje komentarze chociażby w informacjach o nazwa.pl wiedzą, że jako firma hostingowa bardzo dbamy o jakość techniczną infrastruktury i oficjalnie doceniamy przygotowanie kolejnego serwisu, który pozwoli użytkownikom Internetu sprawdzić, jak działają wybrane przez nich strony WWW. Ponieważ w ostatnim czasie webspeed.pl doczekał się dodatkowych funkcji, w tym raportów/wykresów/komentarzy, myślę że warto, aby @theqkash, jako osoba bezpośrednio zaangażowana w promocję tego narzędzia i/lub także w jego rozwój (?), napisał coś więcej o metodologii, coś o osobach tworzących ten projekt, planach jego rozwoju i innych kwestiach, które niewątpliwie są warte tego, aby przedstawić je społeczności skupionej wokół tematów hostingowych na rootnode.

 

Ja na ten moment wiem, że webspeed.pl bada TTFB stron WWW, gdyż to konkretnie jest wyjaśnione na https://webspeed.pl/about. Raz na dobę jest realizowane odpytanie o DNS, odpytanie o rekord MX i A, a dalej wykonywany jest cURL z odczytem nagłówka powiązanego z adresem URL. W drugim etapie, między 6 a 24, następuje pobranie strony metodą cURL. Nie wiemy natomiast, czy informacje DNS są cacheowane, czy uruchamiane są może osobne pody kubernetesowe pod każdy test (tak jak ma to miejsce na test2speed.pl), czym jest wynik "avg wordpress" i jak go interpretować, czy przy mierzeniu TTFB odliczane są czasy rozwiązania IP, czasy zapytań DNS oraz co się dzieje w sytuacji, gdy domena korzysta z jakichś DNSów, ale w rzeczywistości jest obsługiwana przez inny hosting niż wskazywałyby na to DNSy ? Tu jako przykład pod pytanie podam raport https://webspeed.pl/wynajem-maszyn.com.pl, z którego mogę się dowiedzieć, że cyt: "Zmiana serwera z kei.pl na nazwa.pl okazała się minimalna. Domena wynajem-maszyn.com.pl z nowego serwera wczytuje się z podobną szybkością." oraz "System wykrywa zmianę wskazania domeny na nowy serwer DNS. Nie musi to oznaczać zmiany usługi hostingowej. Wykres pozwala właścicielowi domeny ocenić zmianę, której dokonał. Metodologia.".  I wszystko byłoby ok, ale... strona wynajem-maszyn.com.pl nie jest utrzymywana  na serwerze nazwa.pl, tylko na serwerze cyber_Folks, co widać chociażby po raporcie MTR i informacjach o IP tutaj https://www.test2speed.pl/report/wynajem-maszyn.com.pl/mZ3jaeoi :) .

 

Mówiąc o badaniu DNS, zastanawiam się też, co z domenami, które pracują na DNSach więcej niż jednej firmy? Jak te nazwy internetowe identyfikowane są przez webspeed.pl? Do jakiego hostingu przypisywane są te domeny?

 

Oczywiście, serwis jest w fazie beta i ma prawo mieć różne błędy, ale skoro brakuje możliwości kontaktu z twórcami i brak jest możliwości sprawdzenia, kto za niego odpowiada, może @theqkash tutaj na rootnode napisze coś więcej o promowanym przez siebie narzędziu. Osobiście starałem się zebrać wiedzę o webspeed.pl tak, jak robi to "zwykły użytkownik" czyli z ogólnodostępnych baz, ale: 1) WHOIS domeny pokazuje dane prywatne; 2) DNSy ustawione są na Cloudflare; 3) rekordu MX brak. Jest podany profil na FB, ale on także nie zawiera żadnych informacji o właścicielach czy twórcach projektu 🥸. A skoro serwis dysponuje bazą ponad 1,6 mln domen, to w sumie też jest to ciekawe, skąd tak "młode narzędzie" uzyskało listę aż tylu domen oraz kto tą bazą administruje.

  • Super! 1
Opublikowano
Godzinę temu, itomek napisał(a):

I wszystko byłoby ok, ale... strona wynajem-maszyn.com.pl nie jest utrzymywana  na serwerze nazwa.pl, tylko na serwerze cyber_Folks, co widać chociażby po raporcie MTR i informacjach o IP tutaj https://www.test2speed.pl/report/wynajem-maszyn.com.pl/mZ3jaeoi :) .

 

Drugi komunikat który zacytowałeś raczej jednoznacznie wyjaśnia wątpliwości. 🙂

 

Domena jest na Waszych DNSach i taka też informacja widnieje w narzędziu. Niedługo natomiast pojawią się dodatkowe rozwiązania, które będą to raczej w sposób jednoznaczny przedstawiały.

 

Godzinę temu, itomek napisał(a):

 

Mówiąc o badaniu DNS, zastanawiam się też, co z domenami, które pracują na DNSach więcej niż jednej firmy?

 

Podasz przykład?

 

Godzinę temu, itomek napisał(a):

tutaj na rootnode napisze coś więcej o promowanym przez siebie narzędziu

 

Jeśli jako twórcy zechcemy o tym tutaj informować i szerzyć wiedzę, to na pewno to zrobimy. :) Póki co narzędzie jest jeszcze w fazie beta i jest mocno rozwijane. Skupiamy się na funkcjonalności, a nie na rzeczach "miękkich".

 

Godzinę temu, itomek napisał(a):

A skoro serwis dysponuje bazą ponad 1,6 mln domen, to w sumie też jest to ciekawe, skąd tak "młode narzędzie" uzyskało listę aż tylu domen oraz kto tą bazą administruje.

 

Nie ma z tym problemu, ale myślę, że narzędzie które Wy tworzycie stawia tu większe znaki zapytania (np. top100 wht).

 

Nie wydaje mi się też, aby domeny były czymś co wymaga wskazywania kto tym administruje. Dane pochodzą np. z ipsniper.info gdzie domen *.pl jest już multum. 

 

Godzinę temu, kankan napisał(a):

gdzie można zebrać wiedzę w jaki sposób tworzony jest ranking top100 na wht, gdzie niepodzielnie rządzi nazwa.pl, mimo, że w rzeczywistości w niezależnym rankingu rootnode jest trzecia, a zaraz będzie czwarta?

 

Gdzieś tam było pisane, że zaczeli gromadzić także domeny globalne i eu., ale na jakich zasadach to "przetwarzają" to już raczej tajemnica poliszynela. No i pewnie te domeny ma zliczane przede wszystkim nazwa.pl właśnie :) 

 

Godzinę temu, itomek napisał(a):

 

Temat jest o webspeed.pl, więc nie wiem, po co taka próba odbicia piłeczki...

 

Być może po to, bo w zwyczaju macie szukanie zaczepki u zewnętrznych podmiotów, podczas gdy Wasze narzędzia ani transparentnością ani specjalną przejrzystością nie stoją 🙂 

 

  • Lubię 4
Opublikowano
Teraz, kankan napisał(a):

zadbaj o swoje podwórko, jeśli chcesz się czepiać innych, działających niekomercyjnie i niepowiązanych z hostingami...

 

Skoro masz informacje, kto jest autorem / wydawcą / właścicielem webspeed.pl lub kto przy nim pracuje, to świetnie, niestety ja nigdzie tych informacji nie odnajduję. 

Opublikowano
59 minut temu, theqkash napisał(a):

Podasz przykład?

 

Tak, poniżej:

 

# dig NS 01workshop.pl a-dns.pl

; <<>> DiG 9.10.3-P4-Ubuntu <<>> NS 01workshop.pl a-dns.pl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29432
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;01workshop.pl.                 IN      NS

;; ANSWER SECTION:
01workshop.pl.          3600    IN      NS      dns3.home.pl.
01workshop.pl.          3600    IN      NS      dns.home.pl.
01workshop.pl.          3600    IN      NS      ns2.wix.com.
01workshop.pl.          3600    IN      NS      ns1.wix.com.
01workshop.pl.          3600    IN      NS      dns2.home.pl.

;; ADDITIONAL SECTION:
dns.home.pl.            60343   IN      A       217.160.80.244
dns.home.pl.            59718   IN      AAAA    2001:8d8:fe:53:6870::1
ns1.wix.com.            159933  IN      A       185.230.61.165
ns2.wix.com.            159933  IN      A       185.230.60.165
dns2.home.pl.           10828   IN      A       217.160.81.248
dns2.home.pl.           51275   IN      AAAA    2001:8d8:fe:53:6870::2
dns3.home.pl.           43725   IN      A       185.132.34.251
dns3.home.pl.           52287   IN      AAAA    2607:f1c0:fe:53:185:132:34:251

 

Opublikowano

Ja chyba nie bardzo w temacie :D O co ten spór? O to że projekt jest w fazie beta? Coś źle pokazuje? Czy spieranie się o to kto jest właścicielem?

 

Trochę wygląda to na prywatne przekomarzanki na forum...

Opublikowano

Na wstępnie chciałbym prosić administrację o wyczyszczenie wątku z zbędnej przepychanki słownej. Myślę, że jest ona zbędna i przejdźmy do merytoryki.

 

@itomek jestem pomysłodawcą i autorem koncepcji, @theqkash był konsultowany w sprawach merytorycznych, ale bezpośrednio nie odpowiada za projekt. Projekt dopiero raczkuje i jego pierwsza wersja jakkolwiek publiczna ujrzała światło dzienne niespełna miesiąc temu.

 

Cały projekt merytorycznie był konsultowany z większą liczbą osób, ale za część programistyczną odpowiada dwóch pasjonatów hostingowych. Projekt nie jest skupiony na porównywaniu firm hostingowych, a na prezentowaniu wydajności danej witryny w czasie. Dlatego też poszliśmy na pewne uproszczenia i wykrywany operatora po delegacji domeny na serwer dns hostingodawcy. Takie przypisanie jest poprawne w ~99% przypadków, ale jeśli rekord A jest wydelegowany do innego operatora, nasz projekt w chwili obecnej tego nie uwzględnia. Jesteśmy otwarci na wszelkie sugestie i propozycje, ale z racji na to, że zespół jest mały i pracuje w swoim czasie wolnym, wdrożenie funkcji nie corowych może zająć chwilę.

 

Godzinę temu, itomek napisał(a):

W drugim etapie, między 6 a 24, następuje pobranie strony metodą cURL. Nie wiemy natomiast, czy informacje DNS są cacheowane, czy uruchamiane są może osobne pody kubernetesowe pod każdy test (tak jak ma to miejsce na test2speed.pl), czym jest wynik "avg wordpress" i jak go interpretować, czy przy mierzeniu TTFB odliczane są czasy rozwiązania IP, czasy zapytań DNS oraz co się dzieje w sytuacji, gdy domena korzysta z jakichś DNSów, ale w rzeczywistości jest obsługiwana przez inny hosting niż wskazywałyby na to DNSy ?

 

Informacje DNS nie są cachowane. Nody sprawdzające to są serwery VPS vultr, które po kolei odpytują adresy URL. Wynik avg.wordpress jest średnią dla wszystkich stron typu Wordpress z naszej bazy danych. Nie odliczamy zapytań DNS, ani też rozwiązania IP, ale informację o pingu między lokalizacją Vultr, a strona dorzucamy do informacji o domenie.

 

Godzinę temu, itomek napisał(a):

Mówiąc o badaniu DNS, zastanawiam się też, co z domenami, które pracują na DNSach więcej niż jednej firmy? Jak te nazwy internetowe identyfikowane są przez webspeed.pl? Do jakiego hostingu przypisywane są te domeny?

W tym przypadku bierzemy pod uwagę pierwszy serwer ns zwracany dla danej domeny. Masz pełną rację, że takie przypadki występują, ale z naszych badań są pomijalnym promilem w kontekście całości odpytywanych domen. Mając ograniczone zasoby ludzkie, musimy iść na pewne uproszczenia, aby projekt mógł się skupić na core usługi, czyli prezentowaniu wydajności konkretnej strony. Informacje o operatorze, są tutaj jedynie dodatkiem. Z założenia ktoś kto wchodzi, by zobaczyć wydajność swojej strony, wie gdzie się hostuje i kiedy dokonywał jakiś zmian.

 

@itomek zachęcam do kontaktu lub wpisywania swoich pomysłów i sugestii na https://webspeed.pl/features. Bardzo będziemy cieszyć się z wszelkich sugestii które umożliwią nam poprawę naszego projektu. Chcemy skupiać się na stronie i prezentowaniu danych przydatnych dla właściciela serwisu internetowego, a nie chcemy bawić się w porównywanie konkretnych firm.

 

Jeśli chodzi o bazę domen. Zaimportowaliśmy dane z ipsniper.info plus następnie przeczesaliśmy wszystkie strony w poszukiwaniu linków do innych domen.

  • Lubię 3
  • Super! 1
Opublikowano
42 minuty temu, sebak napisał(a):

@itomek jestem pomysłodawcą i autorem koncepcji, @theqkash był konsultowany w sprawach merytorycznych, ale bezpośrednio nie odpowiada za projekt. Projekt dopiero raczkuje i jego pierwsza wersja jakkolwiek publiczna ujrzała światło dzienne niespełna miesiąc temu.

 

Cieszę się, że taki projekt powstał. Doskonale wiem, ile pracy wymaga przygotowanie tego typu narzędzia, a potem jakie koszty wiążą się z jego utrzymaniem.

 

56 minut temu, sebak napisał(a):

Cały projekt merytorycznie był konsultowany z większą liczbą osób, ale za część programistyczną odpowiada dwóch pasjonatów hostingowych

 

Myślę, że wszyscy zdajemy sobie sprawę z tego, że takie przedsięwzięcia budowane czy finansowane przez ludzi, którzy są związani z jedną lub drugą firmą hostingową, albo które są wprost przez taką firmę utrzymywane, są i będą pod baczną obserwacją społeczności. I szczerze - dziwiłem się, że nie ma żadnych tego typu informacji na webspeed.pl. A przecież Vultr nie ma w ofercie darmowych serwerów :) 

 

Jako nazwa.pl, w przypadku test2speed.pl poszliśmy nawet o krok dalej. Zdecydowaliśmy się na dostarczenie w każdej lokalizacji, gdzie są serwery testujące, łącz od komercyjnego dostawcy (Orange). To wszystko po to, aby wyniki można było powtórzyć poza naszym środowiskiem, a także, aby nikt nie zarzucał nam, że stojąc za tym narzędziem, staramy się jakkolwiek wpływać na wyniki. Co prawda webspeed.pl bada TTFB a nie szybkość wczytywania strony, ale ponieważ jest to wskaźnik, który można sobie "wygenerować" w domu, myślę że warto pomyśleć o usprawnieniach, o których wcześniej wspomniałem, albo które wynikają z moich pytań z pierwszego wpisu.

 

59 minut temu, sebak napisał(a):

Takie przypisanie jest poprawne w ~99% przypadków, ale jeśli rekord A jest wydelegowany do innego operatora, nasz projekt w chwili obecnej tego nie uwzględnia.

 

Zgadzam się z tym, że zdecydowana większość domen ma "jedyną słuszną konfigurację" :) 

 

Ale podam jeszcze jeden przykład: https://webspeed.pl/acs-online.pl. Wyniki dla tej domeny zaliczone są na poczet home.pl, sama domena jest delegowana na serwery atthost.pl i home.pl, natomiast hostowana jest w atthost.pl. Widać to na MTRach raportu https://www.test2speed.pl/report/acs-online.pl/uw6H04nf . Dodatkowo, w historii na test2speed.pl adres IP, na którym działa strona WWW w tej domenie, nie zmienił się od roku. 

 

Warto ten element przepracować. Nie jest to rzecz "miękka", bo jak widać - może mieć miejsce przy większej liczbie domen. Podobnie, jak wspomniany przeze mnie przypadek z raportem https://webspeed.pl/wynajem-maszyn.com.pl, który też zawiera nieprawidłowe informacje o hostowaniu strony przez nazwa.pl.

 

Godzinę temu, Tweedlex napisał(a):

Jeszcze niedawno Whois wskazywał na image.png

 

@Tweedlex dzięki, chociaż moje pytanie z pierwszego postu bardziej było podyktowane nie tyle tym, kto jest właścicielem, ale z kim tak na prawdę trzeba kontaktować "w pewnych kwestiach", których nie zgłosi się przez formularz na stronie, bo wymagają szerszego wytłumaczenia.

 

Nadmienię, że wczoraj próbowałem rozmawiać o tym błędnym raporcie  https://webspeed.pl/wynajem-maszyn.com.pl, co niestety skończyło się podobnie, jak pewnie skończyłaby się dyskusja w tym wątku, o ile nie zdecydowałbyś się @sebak zabrać głos. Bardzo to doceniam!

 

Godzinę temu, sebak napisał(a):

Bardzo będziemy cieszyć się z wszelkich sugestii które umożliwią nam poprawę naszego projektu. Chcemy skupiać się na stronie i prezentowaniu danych przydatnych dla właściciela serwisu internetowego, a nie chcemy bawić się w porównywanie konkretnych firm.

 

Może z racji wieku, ale jestem przyzwyczajony do rozmów bezpośrednio. I to nawet gdybym na rzeczową odpowiedź miał czekać dużo dłużej :) Pewne sugestie już tutaj zawarłem, i w treści i w pierwszym wpisie. Niektóre wątpliwości też podałem. Ma to znaczenie, bo inne firmy hostingowe też mogą zacząć się odzywać w przypadku błędnych raportów. Warto pewne poprawki zaplanować i wprowadzić, bo wszyscy - jak widać po komentarzach niektórych osób w tym wątku - ciągle jesteśmy oceniani i obserwowani 😉

 

Opublikowano
Godzinę temu, sebak napisał(a):

Projekt nie jest skupiony na porównywaniu firm hostingowych, a na prezentowaniu wydajności danej witryny w czasie.
(...)
Chcemy skupiać się na stronie i prezentowaniu danych przydatnych dla właściciela serwisu internetowego, a nie chcemy bawić się w porównywanie konkretnych firm.

Nie wątpię, jednakże komunikaty prezentowane na waszej stronie wskazują na takie porównania i zachęcają do porównań:
"Zmiana serwera z X na Y okazała się pozytywna. Domena ***.** z nowego serwera wczytuje się Z% szybciej. Dobra robota!"
gdzie:
X oraz Y to konkretne domeny operatorów hostingu. Zatem liczcie się z tym, że prezentowane wyniki będą przeczesywane w kontekście takich porównań, migracji i ich skutków. Będą również oceniane przez działy PR operatorów hostingu, skoro są oni wymieniani w komunikatach w pozytywnym lub negatywnym świetle.
Jeśli prezentowane dane mają być głównie dla właścicieli serwisów, to oni dokładnie wiedzą kiedy oraz skąd dokąd migrowali, wystarczy im wykres w czasie bez zbędnych komentarzy n/t wyższości jednej firmy hostingowej nad drugą.

Opublikowano
6 minut temu, itomek napisał(a):

Jako nazwa.pl, w przypadku test2speed.pl poszliśmy nawet o krok dalej. Zdecydowaliśmy się na dostarczenie w każdej lokalizacji, gdzie są serwery testujące, łącz od komercyjnego dostawcy (Orange). To wszystko po to, aby wyniki można było powtórzyć poza naszym środowiskiem, a także, aby nikt nie zarzucał nam, że stojąc za tym narzędziem, staramy się jakkolwiek wpływać na wyniki. Co prawda webspeed.pl bada TTFB a nie szybkość wczytywania strony, ale ponieważ jest to wskaźnik, który można sobie "wygenerować" w domu, myślę że warto pomyśleć o usprawnieniach, o których wcześniej wspomniałem, albo które wynikają z moich pytań z pierwszego wpisu.

 

Pomysł świetny i gratuluję ;-). Dla nas to obecnie projekt hobby, więc patrzymy na koszta i jedna lokalizacja będzie musiała wystarczyć. Przy wczytywaniu całej strony, jak w przypadku test2speed.pl to co zrobiliście ma większe znaczenie, bo wczytujesz duże ilości danych (strona plus wszystkie pliki potrzebne do zaserwowania treści). My skupiamy się tylko na index.php i czasie jego generowania, gdzie narzut dns'y, czy połączenie punkt - punkt ma dużo mniejsze znaczenie. Tutaj najwięcej czasu potrzeba na wygenerowanie treści po stronie serwera.

 

14 minut temu, itomek napisał(a):

Ale podam jeszcze jeden przykład: https://webspeed.pl/acs-online.pl. Wyniki dla tej domeny zaliczone są na poczet home.pl, sama domena jest delegowana na serwery atthost.pl i home.pl, natomiast hostowana jest w atthost.pl. Widać to na MTRach raportu https://www.test2speed.pl/report/acs-online.pl/uw6H04nf . Dodatkowo, w historii na test2speed.pl adres IP, na którym działa strona WWW w tej domenie, nie zmienił się od roku. 

 

Warto ten element przepracować. Nie jest to rzecz "miękka", bo jak widać - może mieć miejsce przy większej liczbie domen. Podobnie, jak wspomniany przeze mnie przypadek z raportem https://webspeed.pl/wynajem-maszyn.com.pl, który też zawiera nieprawidłowe informacje o hostowaniu strony przez nazwa.pl.

 

 

Masz rację, będziemy zastanawiać się jak to poprawić. Co innego widzisz jak traktujesz dane maszynowo, a co innego, jak analizujesz konkretnie dane domeny. Dlatego jestem bardzo wdzięczny za wyłapywanie takich anomalii, które będą mogły nam posłużyć do poprawy narzędzia.

 

17 minut temu, itomek napisał(a):

@Tweedlex dzięki, chociaż moje pytanie z pierwszego postu bardziej było podyktowane nie tyle tym, kto jest właścicielem, ale z kim tak na prawdę trzeba kontaktować "w pewnych kwestiach", których nie zgłosi się przez formularz na stronie, bo wymagają szerszego wytłumaczenia.

 

 

Serwis ruszył w wersji beta i nie spodziewaliśmy się takiego zainteresowania. A co za tym idzie, myśleliśmy, że mamy czas na uzupełnienie różnych aspektów informacyjnych i ich doprecyzowanie.

 

19 minut temu, itomek napisał(a):

Może z racji wieku, ale jestem przyzwyczajony do rozmów bezpośrednio. I to nawet gdybym na rzeczową odpowiedź miał czekać dużo dłużej :) Pewne sugestie już tutaj zawarłem, i w treści i w pierwszym wpisie. Niektóre wątpliwości też podałem. Ma to znaczenie, bo inne firmy hostingowe też mogą zacząć się odzywać w przypadku błędnych raportów. Warto pewne poprawki zaplanować i wprowadzić, bo wszyscy - jak widać po komentarzach niektórych osób w tym wątku - ciągle jesteśmy oceniani i obserwowani 😉

 

Będziemy starać się je wdrożyć, stopniowo wedle możliwości, ale jestem za nie bardzo wdzięczny, bo spojrzenie z innej perspektywy zawsze jest cenne. Jesteśmy tylko ludźmi i nie zawsze wszystko jesteśmy w stanie sami przewidzieć.

 

13 minut temu, Tom X napisał(a):

Nie wątpię, jednakże komunikaty prezentowane na waszej stronie wskazują na takie porównania i zachęcają do porównań:
"Zmiana serwera z X na Y okazała się pozytywna. Domena ***.** z nowego serwera wczytuje się Z% szybciej. Dobra robota!"
gdzie:
X oraz Y to konkretne domeny operatorów hostingu. Zatem liczcie się z tym, że prezentowane wyniki będą przeczesywane w kontekście takich porównań, migracji i ich skutków. Będą również oceniane przez działy PR operatorów hostingu, skoro są oni wymieniani w komunikatach w pozytywnym lub negatywnym świetle.
Jeśli prezentowane dane mają być głównie dla właścicieli serwisów, to oni dokładnie wiedzą kiedy oraz skąd dokąd migrowali, wystarczy im wykres w czasie bez zbędnych komentarzy n/t wyższości jednej firmy hostingowej nad drugą.

 

Akcentowanie zmian, wydawało nam się dość ciekawą opcją. Wiadomo, musimy doprecyzować to o czym mówił @itomek, ale z mojej perspektywy jest to bardzo ciekawe, co się dzieje z daną strona w momencie zmiany operatora.

  • Lubię 1
Opublikowano
29 minut temu, sebak napisał(a):

Dla nas to obecnie projekt hobby, więc patrzymy na koszta i jedna lokalizacja będzie musiała wystarczyć.

 

Jasne. Chociaż pewnie warto byłoby to jeszcze dalej pociągnąć. Obydwa serwisy - Was, czyli webspeed.pl i nasz - test2speed.pl to ważne narzędzia dla użytkowników polskich hostingów. Rynek u nas jest dość mocno podzielony, co dobrze rokuje dla tego typu narzędzi. Nie mówię o komercyjnym wykorzystaniu, ale o popularności, która z czasem na pewno przekuje się w dodatkowe "plusy dodanie" dla firmy, która dany projekt rozwija. Moim zdaniem warto na webspeed.pl napisać, że ten projekt tworzy / sponsoruje Ultimahost lub osoby z Wami powiązane oraz dodać bezpośrednie informacje kontaktowe. 

 

32 minuty temu, sebak napisał(a):

Dlatego jestem bardzo wdzięczny za wyłapywanie takich anomalii, które będą mogły nam posłużyć do poprawy narzędzia.

 

👍 

 

Takie rzeczy, jak kwestia porównań szybkości stron na różnych hostingach, zgłaszane są dość często przez klientów. We wszystkich firmach. Zatem to, o czym pisał @Tom X, niestety się dzieje...

 

34 minuty temu, sebak napisał(a):

Jesteśmy tylko ludźmi i nie zawsze wszystko jesteśmy w stanie sami przewidzieć.

 

Najlepsi testerzy w firmie nie wykryją tego, co wykryje społeczność rootnode :) Też się o tym przekonaliśmy. Dlatego mimo niechęci pewnych osób, jesteśmy m.in. na tym forum i będziemy. Bo wychodzimy z założenia, że nawet gdy na pewne tematy mamy różne zdania, to na końcu jest użytkownik. dla którego warto się starać. @sebak po Twoich komentarzach widzę, że u Was jest tak samo.

 

37 minut temu, sebak napisał(a):

Akcentowanie zmian, wydawało nam się dość ciekawą opcją. Wiadomo, musimy doprecyzować to o czym mówił @itomek, ale z mojej perspektywy jest to bardzo ciekawe, co się dzieje z daną strona w momencie zmiany operatora.

 

Jeżeli informacje będą pobierane na podstawie rekordu A, to nie powinno być kłopotu. Oczywiście, pewnie znajdą się i takie strony, które mają dwa rekordy A, które kierują na serwery dwóch różnych firm. Zgadzam się, że to nieprawidłowe konfiguracje, ale kto im zabroni :) 

 

Na koniec wrócę na moment do:

 

2 godziny temu, sebak napisał(a):

Jeśli chodzi o bazę domen. Zaimportowaliśmy dane z ipsniper.info plus następnie przeczesaliśmy wszystkie strony w poszukiwaniu linków do innych domen.

 

Dzięki za informację o tym serwisie. Ponieważ nie braliśmy prezentowanej bazy pod uwagę przy top100.webhostingtalk.pl, przekazałem informację do naszego działu IT. Dostałem przed chwilą odpowiedź, że wstępna weryfikacja pokazała u nas dług ok. 200 tyś domen, których m.in. metodami słownikowymi i innymi rodzajami typowań zwyczajnie nie dało się ustalić. Mam potwierdzenie, ze w ciągu 1-2 dni można spodziewać się dużej aktualizacji na top100.webhostingtalk.pl. Domeny przybędą oczywiście u różnych operatorów. Dla osób, które dopytywały o nasz serwis dodam jeszcze, że w bazie ujęte są wyłącznie te domeny, które są zgromadzone na serwerach DNS danej firmy hostingowej (wykluczamy domeny z odpowiedzią SERVFAIL).

Opublikowano
5 godzin temu, itomek napisał(a):

Jasne. Chociaż pewnie warto byłoby to jeszcze dalej pociągnąć. Obydwa serwisy - Was, czyli webspeed.pl i nasz - test2speed.pl to ważne narzędzia dla użytkowników polskich hostingów. Rynek u nas jest dość mocno podzielony, co dobrze rokuje dla tego typu narzędzi. Nie mówię o komercyjnym wykorzystaniu, ale o popularności, która z czasem na pewno przekuje się w dodatkowe "plusy dodanie" dla firmy, która dany projekt rozwija. Moim zdaniem warto na webspeed.pl napisać, że ten projekt tworzy / sponsoruje Ultimahost lub osoby z Wami powiązane oraz dodać bezpośrednie informacje kontaktowe. 

Nie wiem do końca w którą stronę projekt pójdzie. Sam projekt wziął się z czysto teoretycznej rozmowy z znajomym branżowym, który twierdził, że nie da się przetwarzać regularnie takiej ilości danych. Postanowiłem sprawdzić czy się da. Okazało się, że to nie takie trudne 😀. Zapytałem innego znajomego, czy nie zrobi front-endu do zebranych już danych i tak powstał projekt webspeed.pl.

 

5 godzin temu, itomek napisał(a):

Jeżeli informacje będą pobierane na podstawie rekordu A, to nie powinno być kłopotu. Oczywiście, pewnie znajdą się i takie strony, które mają dwa rekordy A, które kierują na serwery dwóch różnych firm. Zgadzam się, że to nieprawidłowe konfiguracje, ale kto im zabroni :) 

 

 

Będziemy dążyć do tego, by pobierać dane na podstawie rekordu A, jednak muszę się zastanowić jeszcze jak to zrobić w sposób efektywny i w miarę ujednolicony oraz nie obciążający nadmiernie naszych vultrowych serwerów VPS. PS: Cały projekt jest oparty obecnie o 8 serwerów sprawdzających VPS (1 vCPU i 1GB ramu) oraz serwera bazy danych. Tak więc, nie jest to specjalnie duża infrastruktura.

 

5 godzin temu, itomek napisał(a):

Dzięki za informację o tym serwisie.

 

Cieszę się, że też mogłem jakoś pomóc.

 

7 godzin temu, Tom X napisał(a):

Nie wątpię, jednakże komunikaty prezentowane na waszej stronie wskazują na takie porównania i zachęcają do porównań:

 

Wracając jeszcze do tego co pisałeś, to na stronie głównej mamy tylko zachęcenie do sprawdzenia stron które zmieniły operatora w ostatnich dniach. Aby zachęcić do sprawdzenia jak to działa, jeśli ktoś nie ma pomysłu na wpisanie domeny. Losujemy z domen które zmieniły operatora miedzy conajmniej 3 dni temu i maksymalnie 10 dni temu. Nie udostępniamy nigdzie zbiorczych list domen, które przyszły, lub odeszły od danego operatora. Ogólnie rzecz biorąc kluczem do wszelkich sprawdzeń jest konkretna domena.

 

Oczami wyobraźni widzę, że jeśli jakiś operator będzie robił migrację klienta do siebie i będzie chciał się pochwalić tym, że strona klienta przyspieszyła, to może podesłać link do webspeed.pl.

  • Lubię 2
Opublikowano (edytowane)

Mi osobiście bardzo podobają się niektóre funkcje webspeed.pl, sporo informacji, fajnie zrobiony front pod względem UX, status uptime i ogólnie jak wpływa migracja na TTFB. Ale tu jest mały szkopuł, zmigrowałem stronę WP, która w ogóle nie była keszowana (a mogła, była bardzo zaniedbana pod tym względem), na hosting gdzie wdrożyłem cache, było 2000ms na wcześniejszym hostingu, teraz jest w okolicach 80ms zwycięzcą okazał się nowy hosting o ponad 2000%. Dla testu na jednej ze stron na wcześniejszym hostingu, ulokowałem WP skeszowałem i TTFB spadł na starym hostingu do 179ms. Więc myślę, że jeżeli mielibyśmy wyłaniać zwycięzcę przy migracji i podawać o ile % spadły/wzrosły wyniki, warto byłoby (o ile jest to możliwe) dodać informacje czy strona korzystała z cache przed i po migracji, bo np. w przypadku WP, dobrze ogarnięty cache odgrywa role w TTFB.

 

Imo nie ma co wieszać psów na twórcach, tylko wskazywać im jakieś sugestie, przecież to beta i w dodatku fajnie się zapowiada, trzymam kciuki:)

Edytowane przez sempre
Opublikowano

@sempre próbujemy takie coś zrobić. Wczytujemy /feed dla Wordpress'a jako osobne odpytanie raz na dobę. Jeśli /feed wczytuje się dłużej niż index.php to strona prawdopodobnie korzysta z cache. Chwilowo nie mamy pomysłu, jak to inaczej sprawdzać.

  • Lubię 1
Opublikowano
5 godzin temu, sebak napisał(a):

@sempre próbujemy takie coś zrobić. Wczytujemy /feed dla Wordpress'a jako osobne odpytanie raz na dobę. Jeśli /feed wczytuje się dłużej niż index.php to strona prawdopodobnie korzysta z cache. Chwilowo nie mamy pomysłu, jak to inaczej sprawdzać.

 

Moim zdaniem trzeba opisać ten fakt, bo w metodologii nie wspominacie o feed. Tak samo, jak nie wiemy, czym jest avg wordpress, który pojawia się w wynikach w postaci wykresu, a także który można sprawdzić jako "domenę" w niektórych firmach hostingowych. Przy obecnych błędach pomiarowych typu zaliczanie strony pod inny hosting, niż jest to w rzeczywistości, ten avg wordpress też może wprowadzać w błąd. Zastanawiam się też, czemu avg wordpress w przypadku niektórych firm jest, a w przypadku niektórych firm go nie ma. 

 

Przy badaniu TTFB jest wiele czynników, które też wymieniłem wcześniej, jak chociażby czasy zapytań DNS, wpływ DNSSEC na czas zapytania, RTT, cacheowanie o którym wspomniał @sempre  itd. Inaczej działa WP z Litespeedem, a inaczej WP który musi w całości wykonać stronę indeksową, zanim pojawi się ona w wyszukiwarce. Wskazywanie czy zmiana hostingu przyspieszyła stronę, której pełnych parametrów nie znamy i nie możemy wrócić do pełnych wyników wpływających na TTFB jest dość ryzykowne. Rozumiem, że projekt tworzycie z chęci przekazania społeczności czegoś dobrego, ale jako osoby związane z konkretną firmą hostingową, musicie patrzeć też na postrzeganie webspedd.pl przez inne podmioty z branży. Nie ma tu znaczenia, czy działa on tak samo dla Waszego webh.pl, jak dla innych firm. Między innymi z tego powodu, budując test2speed.pl zdecydowaliśmy się na skorzystanie z Chrome'a i Lighthouse'a, a analiza waterfalla i powrót do pełnych wyników historycznych pozwalają dokładnie zorientować się, co działo się na poszczególnych etapach realizacji połączenia na różnych serwerach. Myślę, że dobrze jest wskazać, gdzie aktualnie pracuje strona, bo nie każdy po IP-ku wie, jak to sprawdzić, jednocześnie dając użytkownikom możliwość powrotu do danych historycznych. Ale z doświadczenia wiem, że wyciąganie "daleko idących wniosków", których tak naprawdę w obecnym stanie webspeed.pl nie jest w stanie skutecznie udowodnić, nie jest właściwe i może być dwuznacznie postrzegane. Projekt w końcu nie zrobił się sam i ktoś za te 8 VPSów i serwer bazodanowy płaci.

Opublikowano
Godzinę temu, itomek napisał(a):

Moim zdaniem trzeba opisać ten fakt, bo w metodologii nie wspominacie o feed

 

Feed pobiera się tym samym poleceniem, co zwykły URL, dlatego nie dublujemy poleceń. Odnosi się jedynie do innego adresu URL. W metodologii chcieliśmy by każdy mógł we własnym środowisku sprawdzić każdy parametr który pobieramy, mając do dyspozycji gotowe polecenia. Ale zgodnie z Twoją sugestią zmiany w metodologii zostały wprowadzone.

 

Godzinę temu, itomek napisał(a):

Tak samo, jak nie wiemy, czym jest avg wordpress, który pojawia się w wynikach w postaci wykresu, a także który można sprawdzić jako "domenę" w niektórych firmach hostingowych.

 

Może zacznę od tego, czemu jest to dla niektórych firm hostingowych. Całość działa po adresach dns, więc jeśli ktoś ma dnsy w swojej domenie byłby dla siebie operatorem, a my musielibyśmy liczyć i przechowywać dane dla tysięcy wirtualnych operatorów. Zrobiliśmy listę domen, dla których robią się rankingi typy avg do tych którzy byli w czołówce top100.rootnode.pl. Jeśli chcesz byśmy dodali jakąś firmę, wyślij mi na PW. Samo AVG liczy się prosto, czas wszystkich witryn danego operatora typu Wordpress dzielony przez liczbę witryn.

 

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

Przy obecnych błędach pomiarowych typu zaliczanie strony pod inny hosting, niż jest to w rzeczywistości, ten avg wordpress też może wprowadzać w błąd. Zastanawiam się też, czemu avg wordpress w przypadku niektórych firm jest, a w przypadku niektórych firm go nie ma. 

 

Masz rację co do błędów, jak pisałem, postaramy się to poprawić zgodnie z Twoimi sugestiami. Niemniej, to o czym mówisz, jest trochę jak błąd pomiarowy. Rzadko się dzieje, by normalnie ktoś delegował dns'yp do np. nazwy.pl, a trzymał domenę w innej formie. Na moje oko takich klientów jest poniżej 1%. Przeważająca liczba wszystkich witryn bazuje na WordPress, więc są to duże liczby. Przy tej skali jest to pomijalny błąd pomiaru.

 

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

Przy badaniu TTFB jest wiele czynników, które też wymieniłem wcześniej, jak chociażby czasy zapytań DNS, wpływ DNSSEC na czas zapytania, RTT, cacheowanie o którym wspomniał @sempre  itd.

 

Jak już pisałem, większość tych czynników stanowi ułamek czasu, który jest pomijalny z perspektywy krańcowego wyniku. Ale idźmy tym tokiem rozumowania ;-). Z punktu widzenia klienta, który wchodzi na stronę, nie interesuje go, ile musi czekać na odpytanie DNS, wpływ DNSSEC, czy generowanie strony. Dla niego liczy się po jakim czasie dostanie content i taką wartość też mu prezentujemy. Jeśli firma ma sprawne DNS'y, czas ten będzie krótszy. Jeśli firma ma szybkie serwery z nowoczesnymi procesorami wpływ DNSSEC będzie mniejszy, tak samo jak i czas generowania strony. Te czynniki w dużej mierze zależą od tego, jak firma hostingowa podejdzie do tematu. Wiadomo, testujemy to z konkretnej lokalizacji, więc np. dhosting z racji na fakt, że jest w tej samej serwerownii ma mniejszy ping, ale w średnich mimo wszystko wypada dość przeciętnie. Dla każdej witryny podajemy zawsze pod wykresem ping, na podstawie którego można zobaczyć jaki wpływ na połączenie na wydajność konkretnej witryny.

 

2 godziny temu, itomek napisał(a):

Inaczej działa WP z Litespeedem, a inaczej WP który musi w całości wykonać stronę indeksową, zanim pojawi się ona w wyszukiwarce.

 

Owszem, masz rację, ale z punktu widzenia klienta końcowego mało istotne jest to, czy operator zastosuje cache, czy nie. Ważne by strona wczytywała się szybciej. Jeśli operator użyje narzędzia, które to osiągnie, to jest to jego przewaga technologiczna. Jeden użyje Litespeed'a by to osiągnąć, inny użyje cdn'a, a trzeci bardzo wydajnych procesorów. 

 

2 godziny temu, itomek napisał(a):

Wskazywanie czy zmiana hostingu przyspieszyła stronę, której pełnych parametrów nie znamy i nie możemy wrócić do pełnych wyników wpływających na TTFB jest dość ryzykowne.

 

Obecnie przy zmianie operatora, wrzucamy informacje o ilości unikalnych linków przed i po zmianie (po zmianach społeczności na ten temat), oraz wielkości strony. Tak obecnie weryfikujemy czy i jak strona uległa zmianie. Jeśli uważasz, że warto monitorować jeszcze inny parametr, napisz, pomyślimy jak go wdrożyć. 

 

2 godziny temu, itomek napisał(a):

Ale z doświadczenia wiem, że wyciąganie "daleko idących wniosków", których tak naprawdę w obecnym stanie webspeed.pl nie jest w stanie skutecznie udowodnić, nie jest właściwe i może być dwuznacznie postrzegane.

 

To co odróżnia nasz projekt to pełna przejrzystość. Masz podane wszystkie polecenia w jaki sposób odpytujemy o dowolne dane. Każdy może samodzielnie odtworzyć ten proces i zweryfikować ich poprawność. Dzięki czemu udostępniamy pełną transparentność.

Opublikowano
11 minut temu, sebak napisał(a):

To co odróżnia nasz projekt to pełna przejrzystość.

 

Cieszę się, że wprowadzacie nie tylko dodatkowe usprawnienia, ale też dokładniejsze wyjaśnienia w opisach. Takie zmiany, jak informacje o feed są istotne. Trzeba wyjaśnić, co to jest i czemu jest badane oraz w jakich przypadkach. Narzędzie jest dla każdego, nie tylko dla profesjonalistów. Jak wspominałem, w test2speed.pl używamy silnika Chrome + Lighthouse, a skoro wy piszecie w 100% samodzielnie własny mechanizm badający, to warto to bardziej szczegółowo scharakteryzować. Możecie być pewni, że ten, kto ma zrozumieć - zrozumie.

 

Zachęcam też, żebyście dla pełnej przejrzystości dodali zasady korzystania z serwisu, aby nie było wątpliwości, kto za niego odpowiada. Ja ze swojej strony zastanowię się i pewnie niedługo podpowiem, co moim zdaniem można jeszcze dodać do webspeed.pl.

 

ps. Swoim projektem i tą dyskusją zmotywowaliście nas też do kolejnych usprawnień na test2speed.pl. Kilka fajnych pomysłów wkrótce się będzie kodować :D 

Opublikowano

Bardzo fajna strona, dużo technikaliów, przypomina mi trochę https://speed.cloudflare.com/, albo https://www.webpagetest.org/.

 

Kilka pomysłów pod rozwagę:

- rozdzielić hosting DNS od hostingu strony, zrobić z tego dwie sekcje i tworzyć statsty specyficzne dla każdego z nich

- spróbować wykrywać używany CMS

- porównywać średni czas odpowiedzi nie do WordPressu i PrestaShop, ale do wykrytego CMS'a, oraz do pasującej kategorii strony, np. wosp.org.pl do organizacji NGO, onet.pl do portali, nazwa.pl do firm hostingowych itp.

- nie wiem, co reprezentuje "PHP" w porównaniu średnich czasów, jeśli nie ma dobrego uzasadnienia, to usunąć.

- zmienić tekst "Rozmiar index.php" na "Rozmiar strony głównej". Nie wszystko jest na PHP, opis jest mylący

- wygląda, że źle wykrywacie CMS, np. https://www.webspeed.pl/wosp.org.pl pokazuje WordPress, jestem prawie pewien, że nie

- usunąć informację o serwerze poczty, nieistotne z punktu widzenia wydajności

- dodać sprawdzanie obecności IPv6 oraz procentową różnicę w wydajności (wystarczy mała wzmianka, nie rozdrabniajmy się)

- Sprawdźcie, czy Cloudflare Radar ma jakieś fajne dane, które moglibyście wykorzystać (dostępne API)

- wpisuję domenę, której nie ma zindeksowanej, komunikat jest mało czytelny. Dlaczego jej nie ma? Powinna być? Jak dodać?

- dodać możliwość skanowania dowolnej domeny "na żądanie", nawet jeśli później nie zostałaby dodana do indeksu (bo np. nie jest w kręgu waszych zainteresowań)

Opublikowano
1 godzinę temu, itomek napisał(a):

Możecie być pewni, że ten, kto ma zrozumieć - zrozumie.


Dlatego Tomku wszystkie polecenia które wykonujemy, by pozyskać dane są opisane w metodologii. Tak, by nie było wątpliwości jak to działa, oraz by można było odtworzyć wyniki po swojej stronie.

 

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

Zachęcam też, żebyście dla pełnej przejrzystości dodali zasady korzystania z serwisu, aby nie było wątpliwości, kto za niego odpowiada. Ja ze swojej strony zastanowię się i pewnie niedługo podpowiem, co moim zdaniem można jeszcze dodać do webspeed.pl.


Tutaj jest problem, za projekt odpowiadają głównie dwie osoby(oraz cała rzesza ludzi z branży z którymi konsultowaliśmy metodologię), pracujące nad projektem po pracy. Ja (właściciel webh) oraz druga osoba, która nie pracuje w webh, ale jest entuzjastą technologii. Stąd też trudno przypisać projekt pod konkretna firmę. Nie mam problemu by podpisać się pod projektem z imienia i nazwiska, ale webh/ultimahost w żaden sposób nie finansuje projektu. Więcej, w celu przejrzystości kupuje serwery vps w Vultr, mimo iż za darmo mógłbym mieć je u siebie ;-). Jeśli chcesz dołączyć do zespołu i wspólnej pracy nad projektem, zapraszamy.

 

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

Ja ze swojej strony zastanowię się i pewnie niedługo podpowiem, co moim zdaniem można jeszcze dodać do webspeed.pl.


Pierwsze Twoje sugestie powinny być wprowadzone już w tym tygodniu ;-).

 

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

ps. Swoim projektem i tą dyskusją zmotywowaliście nas też do kolejnych usprawnień na test2speed.pl. Kilka fajnych pomysłów wkrótce się będzie kodować :D 


Cieszę się, że możemy mieć pozytywny wpływ w Wasz projekt.

@psz jestem teraz w trasie, odpisze Ci wieczorem.

Opublikowano
3 godziny temu, psz napisał(a):

- rozdzielić hosting DNS od hostingu strony, zrobić z tego dwie sekcje i tworzyć statsty specyficzne dla każdego z nich

 

Będziemy myśleć, żeby właśnie iść w tym kierunku i analizować rekordy A zgodnie z sugestią @itomek.

 

3 godziny temu, psz napisał(a):

- spróbować wykrywać używany CMS

 

- wygląda, że źle wykrywacie CMS, np. https://www.webspeed.pl/wosp.org.pl pokazuje WordPress, jestem prawie pewien, że nie

 

Staramy się wykrywać CMS tylko po kodach http. Nie analizujemy zawartości strony (za dużo domen do sprawdzenia). Dlatego też nasz mechanizm sprawdzania i przypisywania CMS'ów działa z 99% skutecznością. Będziemy starać się go ulepszać, ale przy stronach typu WOŚP, jest to tak niestandardowa i specyficznie zabezpieczona strona, że CMS może być wykrywany niepoprawnie.

 

3 godziny temu, psz napisał(a):

- porównywać średni czas odpowiedzi nie do WordPressu i PrestaShop, ale do wykrytego CMS'a, oraz do pasującej kategorii strony, np. wosp.org.pl do organizacji NGO, onet.pl do portali, nazwa.pl do firm hostingowych itp.

 

Docelowo chcemy zrobić kategorie stron, ale to już wymaga analizy dużej ilości danych. To zostawiamy sobie na później, jak co do głównej funkcjonalności nie będzie zastrzeżeń. Ale plany takie są.

 

3 godziny temu, psz napisał(a):

- nie wiem, co reprezentuje "PHP" w porównaniu średnich czasów, jeśli nie ma dobrego uzasadnienia, to usunąć.

 

PHP, to strona oparta o technologię php(istnieje index.php), która nie jest wordpressem, czy prestą. Co ciekawe, dużo w naszym internecie stron to zwykły HTML.

 

3 godziny temu, psz napisał(a):

- zmienić tekst "Rozmiar index.php" na "Rozmiar strony głównej". Nie wszystko jest na PHP, opis jest mylący

 

W dzisiejszej poprawce zmienimy to, dzięki za wyłapanie błędu. Pierwotnie mieliśmy sprawdzać tylko strony dynamiczne, ale docelowo uznaliśmy, że nie mając 100% pewności co do poprawności wykrywania typu danych, będziemy sprawdzać wszystko.

 

3 godziny temu, psz napisał(a):

- usunąć informację o serwerze poczty, nieistotne z punktu widzenia wydajności

 

W pełni się z Tobą zgodzę, ale zastanawiam się, czy w przyszłości nie przyda się to do jakiś ciekawych danych statystycznych. Tutaj cały czas się zastanawiamy nad tym, co z tym zrobić.

 

3 godziny temu, psz napisał(a):

- dodać sprawdzanie obecności IPv6 oraz procentową różnicę w wydajności (wystarczy mała wzmianka, nie rozdrabniajmy się)

 

- Sprawdźcie, czy Cloudflare Radar ma jakieś fajne dane, które moglibyście wykorzystać (dostępne API)

 

Obecnie chcemy się skupić na dopracowaniu podstawy działania statystyk. Jeśli to będzie działać bez zastrzeżeń, będziemy rozwijać to o dodatkową funkcjonalność. Masz fajne pomysły, jeśli możesz dodaj je proszę na https://webspeed.pl/features

 

3 godziny temu, psz napisał(a):

- wpisuję domenę, której nie ma zindeksowanej, komunikat jest mało czytelny. Dlaczego jej nie ma? Powinna być? Jak dodać?

 

Przeanalizujemy na dniach ten problem i postaramy się dawać bardziej jasne komunikaty.

 

3 godziny temu, psz napisał(a):

- dodać możliwość skanowania dowolnej domeny "na żądanie", nawet jeśli później nie zostałaby dodana do indeksu (bo np. nie jest w kręgu waszych zainteresowań)

 

Tutaj będzie problem, bo całość ma strukturę uniemożliwiającą taką operację. Już tłumacze dlaczego. Serwer web, który serwuje dane statystyczne w żadnej sposób nie wykonuje żadnych sprawdzeń, oraz nie ma dostępu do serwerów sprawdzających strony. Całość jest dość mocno od siebie odseparowana.

Opublikowano
17 godzin temu, sebak napisał(a):

Wracając jeszcze do tego co pisałeś, to na stronie głównej mamy tylko zachęcenie do sprawdzenia stron które zmieniły operatora w ostatnich dniach. Aby zachęcić do sprawdzenia jak to działa, jeśli ktoś nie ma pomysłu na wpisanie domeny. Losujemy z domen które zmieniły operatora miedzy conajmniej 3 dni temu i maksymalnie 10 dni temu. Nie udostępniamy nigdzie zbiorczych list domen, które przyszły, lub odeszły od danego operatora. Ogólnie rzecz biorąc kluczem do wszelkich sprawdzeń jest konkretna domena.

Tak, funkcja ta zachęca do korzystania z serwisu.

Zastanawia mnie mechanizm weryfikowania CMS'a w kontekście pewnego przykładu, który zwrócił moją uwagę znakomitymi wynikami jak na Wordpressa.
http://pracowniawz.pl/
Ni
estety nie jest to strona oparta na Wordpressie. Być może była w przeszłości. Jeżeli strona jest odpytywana kilka razy dziennie, to system powinien wykryć zmianę i uaktualnić CMS - w tym wypadku: PHP. A może CMS wykrywany jest jedynie przy pierwszym skanowaniu strony?

Opublikowano
3 godziny temu, Tom X napisał(a):

Zastanawia mnie mechanizm weryfikowania CMS'a w kontekście pewnego przykładu, który zwrócił moją uwagę znakomitymi wynikami jak na Wordpressa.

 

Mechanizm ustalania CMS nie jest zbyt skomplikowany i działa tylko na statusach http. Poniżej masz fragment kodu na jakiej zasadzie to sprawdzamy. Całość sprawdzamy z każdym procesem discovery, ale operując tylko na kodach http, musimy iść na pewne uproszczenia.

Zrzut ekranu 2023-08-17 o 22.01.17.png

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.