Um afunilamento comum para tempos de carregamento de página lentos é geralmente a Resolução de DNS. Para testar a quantidade de tempo necessária para resolver o DNS, tente usar dig(1) .
$ dig example.com
Isso deve fornecer uma saída nas seguintes linhas
; <<>> DiG 9.10.2-P1 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13362
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 1 IN A 93.184.216.34
;; Query time: 3 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Thu Jun 18 23:19:24 IST 2015
;; MSG SIZE rcvd: 45
Veja a última seção? Mostra quanto tempo demorou para resolver o DNS. Com o dnsmasq, eu diria que você estará em alguns milissegundos ou menos.
Se você parece bem aqui, hora de testar a rede real. Primeiro, verifique se a conexão com o domínio não está demorando muito. Você deve tentar pingar o domínio e observar os tempos de rtt. Se o rtt for muito grande, a latência da conexão provavelmente será sua causa.
$ ping -c 5 example.com
PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=51 time=204 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=51 time=205 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=51 time=206 ms
64 bytes from 93.184.216.34: icmp_seq=4 ttl=51 time=205 ms
64 bytes from 93.184.216.34: icmp_seq=5 ttl=51 time=205 ms
--- example.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 204.315/205.415/206.755/0.785 ms
Se esse for um segundo ou mais, você definitivamente tem um gargalo de conexão.
Caso você veja algo errado com a saída de ping(1) , tente criar um perfil da conexão melhor usando traceroute(1) .
A saída do traceroute deve ajudá-lo a traçar o perfil da conexão e ver qual parte do caminho da sua máquina para o servidor está causando o máximo de atraso.
Se a saída do ping parecer boa, verifique se o servidor está demorando muito tempo para enviar uma resposta de volta. Experimente wget(1)
$ wget -d example.com
DEBUG output created by Wget 1.16.3.60-fd3a-dirty on linux-gnu.
URI encoding = ‘UTF-8’
--2015-06-18 23:27:55-- http://example.com/
Resolving example.com (example.com)... 93.184.216.34, 2606:2800:220:1:248:1893:25c8:1946
Caching example.com => 93.184.216.34 2606:2800:220:1:248:1893:25c8:1946
Connecting to example.com (example.com)|93.184.216.34|:80... connected.
Created socket 4.
Releasing 0x0000000001afc8d0 (new refcount 1).
---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.16.3.60-fd3a-dirty (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: example.com
Connection: Keep-Alive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Type: text/html
Date: Thu, 18 Jun 2015 17:57:56 GMT
Etag: "359670651"
Expires: Thu, 25 Jun 2015 17:57:56 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (ewr/15BD)
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270
---response end---
200 OK
Registered socket 4 for persistent reuse.
Length: 1270 (1.2K) [text/html]
Saving to: ‘index.html’
index.html 100%[==========================================================================>] 1.24K --.-KB/s in 0s
2015-06-18 23:27:56 (197 MB/s) - ‘index.html’ saved [1270/1270]
A saída faz uma pausa em qualquer local por um longo tempo? Então, esse passo é definitivamente o que está causando os atrasos.