Una lista, dos sitios y 121 peticiones de más

En la entrada de la 0.10.0 dejamos escrita una deuda al final, en el apartado de lo que no estaba: el modo lista trataba como interno solo el dominio de la primera URL del fichero. Dijimos que cambiarlo en esa versión habría sido mal momento, porque ya movía hallazgos de un lado a otro, y que quedaba declarado en el manual hasta levantarlo.

La 0.11.0 lo levanta. Esta entrada cuenta qué pasaba exactamente, porque era peor de lo que decía el manual.

Lo que hacía

crawlforge list urls.txt audita exactamente las URLs del fichero y nada más. Es el modo para revisar las cuarenta landings de una campaña, y es también el que usamos para comparar con otra herramienta en igualdad de condiciones. Para decidir qué es tuyo y qué es ajeno, el motor necesita saber cuál es «tu sitio». En modo crawl es obvio: el de la URL de arranque. En modo lista se tomó la misma decisión, el sitio de la primera línea, y funcionaba mientras el fichero fuera de un solo dominio.

Nuestro caso de uso no es ese. Llevamos más de cien blogs, y lo natural es tener un fichero con las páginas que importan de cada uno. Para medirlo monté una lista de doce URLs: seis de especialmundial.com primero y seis de colorvivo.com después. Con la 0.10.0 salió esto:

colorvivo.com        is_internal=0  done      6
colorvivo.com        is_internal=0  skipped  122  (121 con estado)
especialmundial.com  is_internal=1  done      6
especialmundial.com  is_internal=1  skipped  199  (0 con estado)

Las seis páginas de colorvivo se descargaron y se auditaron, pero quedaron marcadas como externas. Y las 122 páginas de colorvivo que esas seis enlazan, sin estar en la lista, recibieron el trato de un enlace a un sitio ajeno: una petición HEAD a cada una para comprobar que responde. Fueron 121 peticiones contra nuestro propio servidor que nadie había pedido. Las 199 de especialmundial, que sí era «el sitio», se registraron sin pedirse, que es lo que promete este modo.

De esas sondas salieron dos hallazgos ASSET-BROKEN, recursos rotos usados en seis páginas:

/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js   404
/cdn-cgi/scripts/7d0fa10a/cloudflare-static/rocket-loader.min.js  404

Son los scripts que inyecta Cloudflare para ocultar direcciones de correo y para cargar el resto de scripts en diferido. Responden 404 a una petición suelta sin cookies, y el motor ya ignora a propósito las rutas /cdn-cgi/ de un sitio propio: las registra y no las pide. Como colorvivo no era «el sitio», el filtro no se aplicó y el informe daba dos errores que no existen. El manual no hablaba de esto. Decía que el resto de dominios se trataban como ajenos, y el daño concreto de tratarlos así lo encontramos al rastrear, como casi siempre.

Dos preguntas que antes eran una

El arreglo obvio es cambiar «el dominio de la primera línea» por «cualquier dominio de la lista». Para decidir qué se descarga y qué se sondea, eso basta. Pero «interno» se usaba para dos cosas distintas, y con un solo sitio daban siempre la misma respuesta.

La primera es si una URL pertenece a alguno de los sitios auditados. De eso depende si se pide, si se sondea y cómo se guarda. La segunda es si un enlace se queda dentro del sitio de la página que lo contiene, y de ella dependen el recuento de enlaces internos de cada página y reglas como INDEX-NOFOLLOW-INTERNAL, que avisa cuando pones nofollow a un enlace hacia tu propio sitio.

Con dos sitios en la lista, un enlace del blog A al blog B apunta a una URL auditada y, a la vez, sale del sitio de A. Si se contaba como interno, cada nofollow entre dos blogs de la misma cartera dispararía un aviso, y hay carteras donde eso es una decisión tomada a propósito. Para un buscador A y B son dos sitios aunque tengan el mismo dueño, y la herramienta tiene que verlo igual.

Así que ahora hay un objeto con las dos preguntas separadas. Con un solo sitio, que es el caso de crawl y de la auditoría de una carpeta dist/, sigue exactamente el mismo camino que antes. La misma lista con la 0.11.0:

colorvivo.com        is_internal=1  done      6
colorvivo.com        is_internal=1  skipped  122  (0 con estado)
especialmundial.com  is_internal=1  done      6
especialmundial.com  is_internal=1  skipped  199  (0 con estado)

Cero sondas contra páginas propias, y los dos ASSET-BROKEN desaparecen. El resto de hallazgos es idéntico en las dos versiones.

El número que asustaba y no era nuestro

La verificación previa a publicar dio 68.760 elementos por segundo. La 0.10.0 daba 108.585. Después de lo que pasó la última vez, con un 24% que la prueba dejó pasar, no me fiaba de un verde.

Esta vez el sospechoso razonable era el código nuevo: la comprobación de «¿es de un sitio auditado?» se hace una vez por enlace de cada página, y es exactamente la función que costó un 4% hace un mes. Por eso el caso de un solo sitio conserva la comparación sin asignaciones de antes, y solo una lista con varios dominios pasa por una tabla hash.

Pero comparar con el número del mes pasado no demuestra nada. Lo que sirve es compilar las dos versiones y medirlas en la misma máquina, en el mismo rato y alternando el orden:

original  60.625    nueva  61.730
original  63.400    nueva  60.039

Empate dentro del ruido. El Mac tenía una carga media de 23 mientras medía, y eso explicaba la caída entera. El número del changelog sirve de referencia, pero la medida tiene que ser del mismo día y de la misma máquina.

Lo que sigue saliendo de la primera URL

Hay dos cosas que siguen atadas a la primera línea a propósito. La credencial de CRAWLFORGE_AUTH solo se manda a su host, porque elegir a cuál de varios sitios mandar una contraseña sería adivinar. Y el informe lleva su nombre en el título. El manual lo dice en los dos idiomas.

Las dos pruebas nuevas se vieron en rojo antes de darlas por buenas: quitando el arreglo, cada bloque de comprobaciones falla por su cuenta. Montan dos sitios en un mismo servidor de pruebas, porque para el motor 127.0.0.1 y localhost son dominios distintos aunque acaben en la misma máquina. Son 1.054 pruebas en verde.