Maxx

Nazwa.pl nie ma zdefiniowanej ceny nawet dla przesyłek zwykłych które stanowią 99,99 % przypadków. Gdyż tylko skończony głupiec może wysyłać przez WhoisPrivacy przesyłkę która gabarytowo lub wagowo nie mieści się w cennikach firm spedycyjnych / kurierskich. A jak słusznie zauważył @kafi - roszczenia względem przesyłki można mieć wyłącznie do firmy na której adres przesyłka została wysłana. Więc w ramach przejrzystości - podaj Tomku nazwę i dane firmy którą Nazwa.pl używa jako proxy dla WhoisPrivacy i na którą przychodzą tak standardowe przesyłki jak wagon pustaków którego koszt dostarczenia do klienta trzeba będzie ustalić indywidualnie. Gdyż z tego co napisałeś wynika iż zwykła korespondencja o maksymalnych wymiarach A4 stanowi ułamek procenta a wagony z pustakami to standard jeśli chodzi o WhoisPrivacy w Nazwa.pl

Czyli standardy gorsze niż na targowisku. Bo jak głupim trzeba być aby podpisać umowę/skorzystać z usługi której istotne koszty nie są zdefiniowane w cenniku ani też sposób ich wyceny sprecyzowany w regulaminie/umowie. Gdyż później może się okazać, że gdy przesyłka dotrze do Nazwa.pl - trzeba zrobić audyt za 2,000 PLN aby w ogóle się upewnić z jaką korespondencją mamy do czynienia i wynająć kuriera za kolejne 2,000 PLN żeby ją dostarczyć . Myślę że na tym przykładzie doskonale widać w jakich klientów celuje Nazwa.pl

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ę ? 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 ? 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".

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. 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 %

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. 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. 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 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: Nie jest jasne, czy pomiary zostały dokonane przy użyciu HTTPS czy HTTP. Na wykresie z 10 dni, nie ma wyników z CACHE, które są na wykresie z 3 m-cy 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. 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.

Domen newGTLD mających ustawione serwery nazw Home.pl jest blisko 20 razy więcej niż domen mających ustawione serwery nazw Nazwa.pl Stan na dzień 5 grudnia 2023 wygląda następująco: newGTLD Home.pl - 11,941 domen Nazwa.pl - 646 domen Home.pl wygrywa również w najbardziej znanych końcówkach gTLD, ale tutaj przewaga nie jest już tak gigantyczna jak w przypadku newGTLD: .COM Home.pl - 42,204 domen Nazwa.pl - 24,236 - domen .NET Home.pl - 2,970 domen Nazwa.pl - 2,129 - domen .ORG Home.pl - 3,271 domen Nazwa.pl - 1,834 - domen .INFO Home.pl - 2,111 domen Nazwa.pl - 1,657 - domen .BIZ Home.pl - 1,077 domen Nazwa.pl - 830 - domen Za jakiś czas kolejne zestawienie które powie nam kto zyskuje a kto traci

Tomku, w dzisiejszych czasach nie jeździ się po świecie z kompem w plecaku aby dokonać pomiaru czasu ładowania strony ale wykorzystuje się przeglądarkę użytkownika oraz stosowne narzędzia. Za pomocą tej samej przeglądarki i tych samych narzędzi można również sprawdzić realną szybkość połączenia, pingi, czas ustanowienia połączenia https vs http i wiele innych rzeczy. A dzięki zebranym danym można REALNIE porównać różne rozwiązania będące na rynku jeśli chodzi np. o CDN, DNS czym sam hosting i dzięki temu dobrać stosowne rozwiązanie do konkretnej sytuacji na konkretnej stronie charakteryzującej się konkretną audiencją. Mając serwery testowe 2.5 ms od swojego CDN-a faworyzuje się właśnie tego CDN-a w wynikach. Gdyż jest oczywiste że inny dostawca mający CDN-y np. w Miami i Seattle wypadnie w nich znacznie lepiej mając tam również serwery testowe niż Nazwa.pl. Dokładnie na odwrót będzie w przypadku test2speed.com. Już nawet nie wspomnę o tym iż wyniki testów za pomocą narzędzi między serwerowych będących 2.5 ms od CDN-a i to zazwyczaj na łączu 1 Gbit są praktycznie bezużyteczne gdyż w rzeczywistym świecie będą miały odzwierciedlenie w mniej niż 1% przypadków. Dlatego właśnie stosuje się pomiary po stronie przeglądarki użytkownika i tą metodologię stosuje również Google w narzędziu Pagespeed a która jest niepodatna na marketingowy bełkot uwzględniając przy tym wiele innych i istotnych czynników. I dlatego wyniki pokazywane przez Google Pagespeed są z goła inne niż pokazywane przez jakiekolwiek amatorskie narzędzia do których bez cienia wątpliwości zalicza się zarówno test2speed.com jak i test2speed.pl

Nie wiem dlaczego zakładasz Tomku iż będę prezentował najgorsze z możliwych wyników. Jak widzisz samodzielnie udało Ci się uzyskać znacznie gorsze (wspomniane 22 s). Ale wystarczy spojrzeć na kod strony aby wyjaśniło się skąd bierze się taka kolejka (Queue). A w tymże kodzie mamy 19 zewnętrznych skryptów i jeszcze 17 osadzonych ... Nie wiem czy wiesz Tomku, ale jeśli przeglądarka napotka na tag SCRIPT w kodzie - w przypadku skryptu osadzonego, dalsze wyświetlanie strony jest zatrzymane do czasu jego wykonania. Podobnie dzieje się w przypadku każdego skryptu zewnętrznego ładowanego synchronicznie - ale dochodzi do tego jeszcze czas jego pobrania. To właśnie wyjaśnia skąd bierze się w niektórych przypadkach tak wysokie opóźnienie w ładowaniu strony Waszego bloga, mającej w sumie 36 skryptów . Gdyż wystarczy iż jeden z tych skryptów ładowanych synchronicznie z zewnątrz się "opóźni" i ma to wpływ na czas załadowania całej strony. Dlatego tylko amator może pozwolić sobie na taj dużą ilość skryptów i to rozrzuconych w różnych miejscach strony zamiast samym dole, gdy użytkownik widzi już zawartość. Nie mówimy Tomku o Pagespeed Score, ale REALNYM czasie ładowania się danej strony. A ze wspomnianego narzędzia Google (z wyników zebranych od odwiedzających) wynika iż tylko 75 percentyl mieści się w 1.6 sekundy, 91 percentyl w 2.5 sekundy a blisko 10 % to wszystko ponad to, czyli między innymi wspomniane 22 sekundy ładowania się cytowanej strony Waszego bloga z dala od Polski z CDN-em Nazwa.pl. Z kolei narzędzia typu test2speed czy to .com czy to .pl mierzą maksymalnie 5 percentyl (czyli max 5% użytkowników osiągnie prezentowane wyniki) będąc umiejscowione 2.5 ms od serwerów. Dlatego też są mówiąc delikatnie - są mało przydatne dla kogoś, kto podchodzi do czasu ładowania strony poważnie. I dlatego Google bierze pod uwagę pomiary dokonywane w przeglądarce użytkownika gdyż są odbiciem realnego czasu ładowania strony a nie syntetyczne testy 2.5 ms od serwera.

Jeśli serwery dedykowane są w zakresach IP które wymieniłem wcześniej a które są autoryzowane przez rekordy SPF(TXT) dla wysyłki poczty w imieniu Home.pl - nie ma znaczenia z jakich hostów/subdomen zostanie wysłana poczta. Zwłaszcza biorąc pod uwagę iż nie widzę nic (DMARC,DKIM) dla domeny Home.pl które by mogło zmienić wynik weryfikacji SPF. No ale może coś umkneło mojej uwadze ... Dlatego warto aby dział techniczny się temu dokładnie przyjrzał. Bo jak mówi powiedzenie, diabeł tkwi w szczegółach.

@kafi powyżej wyjaśnił o co chodzi. Zakładam że pośród tej niemałej puli IP znajdują się również serwery dedykowane (i VPSy) a nie tylko shared hosting. A w przypadku dedyków jakoś nie wyobrażam sobie abyście blokowali port 25 czy narzucali klientowi w jaki sposób ma korzystać z poczty na swoim dedyku. No ale może się myle ...

Nie zmienia to faktu, że przy takim ustawieniu SPF i autoryzacji przez SMTP każdy klient Home.pl posiadający IP ze wspomnianej puli może podpisać się w polu od "Home.pl" i serwery poczty uznają każdą taką wiadomość jako wysłaną od Home.pl. Ale "ot tak" każdy klient Home.pl z tych 180 tysięcy kont może podpisać się Waszą marką w polu OD i każda wiadomość przejdzie weryfikację SPF o czym wspomniałem wyżej. Zgadza się ? Czy w Waszej ofercie są wyszczególnione funkcje php które blokujecie, czy też klient sam musi na to wpaść (czyli czasem stracić kilka godzin) nie rozumiejąc dlaczego dany skrypt nie chce mu działać ?

Tomku wyjaśnisz jak to możliwe, że na wklejonym przez Ciebie wyniku testu z Singapuru, strona w pełni załadowała się szybciej (~0,3 s) niż sam czas jej generowania przez WP który wynosi ponad 0.4 s, że już nawet nie wspomnę o czasie połączenie z PL do SG ? Bo najwyraźniej coś z tym testem jest nie tak. Sprawdziłem też inne narzędzia korzystające z silnika chrome i dysponujące tymi samymi lokalizacjami i tam wyniki dla wspomnianej strony z Waszego bloga na przykładzie https://www.uptrends.com/tools/website-speed-test są następujące: Singapore - 5.2 sec Los Angeles - 6.9 sec New York - 6.5 sec Wynika z tego iż tak rewelacyjne wyniki dla Waszego bloga pokazuje JEDYNIE Wasze narzędzie. To nad takim laniem wody trwały prace z blogiem o których wspominałeś ?

Home.pl ma tak ustawione rekordy DNS odnośnie poczty, iż można wysłać email z 180,224 adresów IP i podpisać się Home.pl w polu nadawcy a serwery odbierające pocztę i weryfikujące SPF uznają każdą wiadomość wysłaną z tej puli jako VERIFIED. Oznacza to, iż wystarczy aby spamer uzyskał hasło do jednego z kont hostingowych z tej puli lub znalazł lukę w jakimkolwiek skrypcie php na tych kontach umożliwiającą uruchomienie funkcji "mail" w php aby bezproblemowo rozesłać spam i podpisać się w polu nadawcy "Home.pl". To samo może zrobić każdy klient Home.pl mający konto hostingowe w następującej puli IP: 212.85.96.0/19 62.129.192.0/18 89.161.128.0/17 79.96.0.0/16 188.128.128.0/17 46.41.160.0/19 46.242.192.0/18 Nie tylko pogratulować @home_pl tak niskiego ukłonu w stronę spamerów

692 ms (i ponad) to ogromna tragedia w przypadku WP, zresztą wszystko ponad kilkadziesiąt milisekund jest tragedią. Zwłaszcza iż można to zmienić w zaledwie kilka minut dobierając odpowiednią wtyczką cache / nakładkę i tym sposobem zejść do kilku ms a nawet jeszcze niżej przy odpowiedniej konfiguracji Nginxa i to nawet bez uruchamiania interpretera php. Więc jeśli chodzi o brak kompetencji - strona WP generująca się 692 ms to najlepszy przykład. Dlatego też profesjonalistę nie interesuje czas generowania strony mający trzeciorzędne znaczenie w tym wypadku ale TTFB z cache oraz powtarzalność wyników w czasie. Dodatkowo sprawdzając wyłącznie strony z cache - niweluje się błąd pomiaru pomiędzy poszczególnymi stronami wynikający choćby z ilości zainstalowanych wtyczek i generowanych przez nie opóźnień. Czyli stworzone są niemal identyczne warunki dla każdej ze stron. Dlatego tylko i wyłącznie taki pomiar dla profesjonalisty ma sens jeśli chodzi o strony z WP. Dlatego jak CI napisałem wcześniej - Twoja strona na dzień dzisiejszy jest dla profesjonalisty całkowicie bezużyteczna. Więc jeśli chcesz aby dla tej grupy była w jakikolwiek sposób przydatna - zrób ranking top 100 najszybciej ładujących się domen z WP uwzględniając powtarzalność wyników w czasie. A wtedy się okaże który hosting jest naprawdę szybki i który wybierają profesjonaliści. Chyba też nie muszę Ci tłumaczyć iż w tym rankingu nie może się znaleźć żadna strona z zewnętrznym akcelatorem treści jak choćby CloudFlare a wyłącznie te, serwowane przez danego usługodawcę. Więc zamiast się obrażać jak dziecko, zachwycać tragicznymi wynikami na poziomie 692 ms i wyzywać od troli tych, którzy znacznie lepsze narzędzia robili co najmniej dekadę wstecz - uważnie słuchaj, bo wiele możesz się nauczyć. Bo to co odróżnia ludzi mądrych od głupich - to właśnie umiejętność słuchania i uczenia się od ludzi ze znacznie większym doświadczeniem.

Ten przykład podałem wyłącznie po to aby był wystarczająco jasny. Natomiast największy błąd w całym pomiarze przy syntetycznych narzędziach i to niezależnie od wielkości próbki wprowadza nie uwzględnienie szybkości łącza użytkownika i jego obciążenia, a tutaj błąd może sięgać nawet 10,000 %. Więc jaki ma sens test obarczony takim błędem ? Jak wyżej napisałem - to jest po prostu zabawka i ktoś kto naprawdę bierze sprawę szybkości strony na poważnie skorzysta z profesjonalnych narzędzi zbierających dane w rzeczywistych warunkach od odwiedzających daną stronę. Po prostu profesjonaliści korzystają z innych narzędzi niż amatorzy. Ale na rynku są zarówno jedni jak i drudzy - więc dla amatorów takie narzędzia mogą być wystarczające. Co nie zmienia faktu, iż amatorzy używający syntetycznych testów mogą być święcie przekonani iż ich strona jest szybka gdy w rzeczywistości może być zupełnie na odwrót. Podobnie jak święcie mogą być przekonani, że strona konkurencji jest wolna podczas gdy w rzeczywistości jest na odwrót. A dzięki tej rzeczywistości - klienci wybierają stronę konkurencji a nie ich. Po prostu korzystanie z amatorskich narzędzi ma swoją cenę. Profesjonalista optymalizuje stronę na podstawie wiarygodnych danych i osiągnie tym nawet i 100,000 % wzrost wydajności i szybkości ładowania strony zwłaszcza w połączeniu z usługą CloudFlare która nawet w darmowej wersji ma sporo możliwości konfiguracji - czego nie ma garstka amatorskich rozwiązań i serwerów CDN takich jak choćby nazwa.pl Z tego co napisałeś wnioskuję że w Nazwa.pl nie bardzo macie rozeznanie odnośnie możliwości usług CDN jakie są na rynku, więc spieszę Cię poinformować Tomku, iż w CloudFlare już od dawna można wybrać serwer źródłowy dla danej lokalizacji i tym samym skrócić dziesiątki razy TTFB w przypadku skryptów php. Dlatego tym bardziej śmieszy mnie iż staracie się wejść na rynek CDN z technologię sprzed 10 lat - nie mając na nim absolutnie żadnych szans. Dlatego darmowa usługa CloudFlare wyprzedza płatną usługę CDN w Nazwa.pl o lata świetlne a o możliwościach płatnej usługi CloudFlare lepiej za dużo nie mówić - gdyż to kopanie leżącego którym w tym przypadku jest Nazwa.pl. No i na koniec pytanie (retoryczne) - czy ktoś komu naprawdę zależy na szybkości działania strony i z myślą o użytkownikach z poza Polski wybierze płatną i biedną usługę z garstką serwerów w nazwa.pl czy darmową usługę CloudFlare oferującą o wiele więcej lokalizacji serwerów CDN/DNS oraz dość szeroką możliwość ich konfiguracji nawet w darmowej wersji którą już za niewielką opłatą można rozszerzyć do obsługi wielu serwerów źródłowych czy choćby wgrania własnych certyfikatów SSL na serwery krańcowe - dziesiątki razy skracając nawiązanie połączenia SSL ?

W żadnym z tych testów nazwa.pl nie jest na pierwszym miejscu, więc wynika z nich jedynie, iż nazwa.pl w niczym nie jest liderem oprócz marketingowego bełkotu który tylko potwierdza, iż ta krowa która najgłośniej ryczy najmniej mleka daje. Ponadto aby jakikolwiek test był wiarygodny, muszą być stworzone identyczne warunki - czyli w przypadku bloga WP - przede wszystkim taki sam szablon i te same wtyczki oraz taka sama ilość (i objętość) zarówno strony głównej jak jej zawartości w postaci grafik/zdjęć. A nawet mimo stworzenia takich warunków wciąż wyniki będą dalekie od rzeczywistości gdyż nie uwzględniają szybkości łącz konsumenckich gdzie przy wielkości strony 10 MB i szybkości łącza konsumenckiego 10 Mbit wynik testu będzie wprowadzał w błąd na łączu serwerowym 100Mbit a błąd będzie dziesięciokrotny w stosunku do rzeczywistości. I choćby nie wiem jak szybki i wydajny był serwer źródłowy, nie jest możliwe aby czas ładowania strony spadł poniżej 10 sekund przy w/w warunkach podczas gdy test na serwerze 100Mbit może pokazać czas ładowania 1 sekundę - dlatego tego typu testy są całkowicie bezużyteczne. Do tego wszystkiego wyciąganie średniej jest obarczone gigantycznym błędem i bardzo dalekie od rzeczywistości, gdyż przykładowo średnia 2 stron wynosząca 500 ms, z czego jedna generowana jest w 900 ms a druga w 100 ms - nie ma nic wspólnego z rzeczywistością a wynik jest obarczony 500% błędem w przypadku strony szybszej. Dlatego Google stosuje pomiar szybkości ładowania strony po stronie użytkownika, które dalekie jest od tego co podają narzędzia robiące syntetyczne testy między serwerowe. Zasada jest bardzo prosta: test szybkości generowania strony robi się na serwerze źródłowym a czas jej wczytywania w przeglądarce użytkownika. Dlatego narzędzie jakie stworzyłeś nie można traktować poważnie a raczej bardziej jako zabawkę dla dorosłych dzieci jak i każde inne jemu podobne. Jedynie co mogę w nim pochwalić to ładny ciemny design. A to co mogę zasugerować to robienie cache wyników co określony czas, które przyspieszy ich prezentację.

Czy liczyłeś Tomku na to, iż takimi banałami usprawiedliwisz tak fatalny wynik nazwa.pl na forum specjalizującym się w usługach hostingowych ? Czytając co piszesz odnoszę wrażenie iż muszę od podstaw wyjaśnić Ci co dzieje się od momentu wpisania przez użytkownika konkretnego adresu w przeglądarkę abyś choć troszkę był w stanie zrozumieć z czego wynika tak fatalny wynik CDN-ów nazwa.pl. Ale musisz mieć też na uwadze Tomku iż wyjdzie wtedy na jaw, iż celowo i bez wiedzy swoich klientów znacząco spowolniliście ich strony włączając im tak bezużyteczną usługę jaką bez cienia wątpliwości jest SECDNS a 5 Ghz Xeon E−2388G którym tak chełpi się Nazwa.pl nie tylko nie jest w stanie nadrobić tak fatalnej pomyłki ale i również czym dalej od serwera źródłowego - tym gorzej. Ponadto dzisiaj już 5 Ghz Xeon-y stosowane przez nazwę są przestarzałe gdyż obecnie procki rozpędzają się do 6 Ghz podobnie też jak przestarzałe już są dyski Optane a nowe dyski NVMe na PCIe 5.0 rozpędzają się do 12,000 MB/s zamiast ułamka z tego w przypadku Intel Optane poprzedniej generacji w które zainwestowałą nazwa.pl w 2019 roku. Gdyż jak widzisz Tomku -Wasze rozwiązania w zaledwie w 2 lata stały się przestarzałe i mało atrakcyjne ( w przypadku Optane - w 3 lata ) A najgorsze w tym jest to iż Nazwa.pl nigdy do żadnych błędów się nie przyznaje obarczając ich gigantycznymi kosztami swoich klientów wmawiając im przy tym iż te gigantyczne błędy to rozwój technologiczny gdzie już na przykładzie SECDNS dobitnie widać, iż nazwa.pl odgrzała starego a w dodatku mocno przytlonego kotleta sprzed dekady którym nikt nie był zainteresowany. A dzisiaj wstyd się przyznać Tomku dlaczego Wasze CDN-y wypadają tak fatalnie, prawda ?

Nie widzę w testach Sao Paulo. Rozumiem, że tam gdzie nazwa.pl nie ma serwerów CDN testów nie robicie aby świat nie dowiedział się jak straszliwie ślimaczą się strony hostowane w nazwie. Niestety nawet 2.5 ms od serwerów CDN nazwy, na łączach 100Mbit+ w które są wyposażone serwery testowe - wynik dobitnie pokazuje jak beznadziejną usługą (a w dodatku jeszcze płatną) jest CDN w nazwa.pl. A przypomnę iż poniższy test został wykonany po południu w niedzielę a więc daleko mu do mocno obciążonych łącz w peek-u podczas tygodnia. Średnio 1,000x tyle co średni ping do serwerów CDN nazwy.pl - czyli PORAŻKA na maxa. Aż strach pomyśleć jak muszą się straszliwie ślimaczyć strony hostowane w nazwie w przypadku klienta zlokalizowanego w Australli w której jest sporo Polaków a która jest najdalej od Polski i blisko 200 ms od Singapuru. Przetestowałem też kilka losowych stron z blogów hostingowych i niemal w każdym wypadku wynik jest lepszy od nazwy.pl i jej biednych czterech CDN-ów zlokalizowanych poza Polską a wyszczególnionych w w/w teście. Wynika z tego iż jeśli ktoś chce aby jego blog ślimaczył się na maksa poza Polską - najlepiej skorzystać z oferty nazwa.pl i jej CDN-ów. Zresztą wynik w Polsce nie prezentuje się wiele lepiej - polecam sprawdzić dla wskazanej podstrony