Mudando el esqueleto de PabloYglesias: ¿Qué SSL implementamos?

Esta historia comienza hace algo más de tres años.

La página que actualmente visita estaba alojada en un servicio temporal con unos recursos, como cabría esperar, ínfimos. Y puesto que parecía que esto de escribir a diario de manera pública me estaba gustando, tocaba el turno de profesionalizarlo un poco más.

Miré por aquel entonces alternativas, y acabé decantándome por un hosting low cost, del cual había oído tanto cosas buenas como malas, y que al menos en mi caso, y hasta ahora, ha cumplido como un campeón.

Pero los tiempos cambian, y las necesidades que tenía PabloYglesias, y las que requiere hoy en día con el tráfico actual, han evolucionado sustancialmente.

La página, como bien sabe, está hiperoptimizada a nivel de cliente, aplicándome el propio cuento que aplico con algunos de mis clientes, con una paralelización de carga de contenido audiovisual, con un caché local y con el uso del proxy inverso-CDN de CloudFlare.

Pero aun así, las limitaciones del servidor empezaban a quedarse cortas, y estos últimos meses, habida cuenta de algún que otro susto (efectos menéame y caídas varias), decidí ponerme manos a la obra para upgradear el servicio.

Y ya que nos poníamos, habilitar por defecto un SSL, que entiendo acabará siendo el protocolo de comunicación por defecto de la red (y pese a que tiene algunos puntos negros preocupantes).

Es aquí cuando comenzaron los problemas.

Limitaciones absurdas para clientes antiguos

La primera sorpresa con la que me encontré es que en mi plan (ya descatalogado) se incluían dos dominios, mientras que en los nuevos solo uno.

“Pues oye, saco uno y tiro con el resto”, pensé, para regocijo del destino.

Y así hice, enviando el dominio principal a mi proveedor habitual de dominios y haciendo las configuraciones oportunas. Pero todo se fue al trasto.

¿La razón? Pese a que había hablado con los técnicos de antemano, explicándoles la arquitectura que tenía en mi página, al parecer en ese proveedor tenían una limitación en el uso que se le podía dar a un dominio externo, y casualmente, las redirecciones de CloudFlare eran ahora incompatibles.

El dominio principal funcionó durante unas horas, y los subdominios (necesarios para la paralelización) no funcionaron desde el principio. Y esto además mandaba al cuerno el tema de aplicar un SSL sino era contratándolo al propio proveedor (cosa que por principios me negaba). Descontando que en mi nuevo proveedor de dominio tenía una permanencia de 60 días…

Así que volví a una configuración anterior (solo cacheado local), para lamento de algunos de mis lectores, y dejé que se me calmaran los ánimos mientras me iba a San Francisco y reordenaba temas profesionales y personales.

A finales de la semana pasada decidí, en un momento de inspiración, hablar con Jose Ramón (@monchomad) de SiteGround, al cual conocí precisamente hace unos meses, en el estreno de su nueva oficina en Madrid, y con el que he ido coincidiendo en más de un evento de software libre y wordpress de la capital.

Faltaron apenas un par de emails para que me convenciera de que me fuera con ellos, y es que en todo este tiempo no he oído más que buenas cosas de la compañía (ES).

Este fin de semana nos pusimos manos a la obra, y este ha sido el resultado.

La importancia de un proveedor con soporte REAL de WordPress

Parece una tontería, ¿verdad? Un desarrollador recurriendo a técnicos para que le ayuden en el trabajo…

Nada más lejos de la realidad. Ha sido un verdadero placer contar con un equipo que además de hacerme la migración (que sí, que solo es cuestión de dedicarle un par de horas), han estado ahí respondiendo a mis preguntas y ayudándome con los problemas (no solo de la migración, sino también de la arquitectura de la web y del propio WP) que han ido surgiendo.

Además, la capacidad de consultar la página vía hosts local (en mi anterior proveedor no tenía manera) me ha evitado tener que apuntar el dominio principal hasta que en efecto todo estaba correcto.

Un fin de semana en el que los técnicos han metido mano al asunto, y hemos acabado por encontrar el problema (un plugin de cortafuegos que se había quedado con el cambio a medio camino entre activo y desactivo, y que evitaba que cargaran la mayoría de scripts asíncronos que tengo en la página), buscar soporte en los creadores del plugin (por cierto, vaya soporte más bueno) y solucionar el asunto.

Hoy en día, después de unas 72 horas con la nueva dirección y pidiendo feedback a algunos usuarios por Twitter, creo que ya está totalmente operativa, subdominios incluidos, paralelización de carga incluida, y con el cacheado en tres niveles que ofrece SiteGround, sin lugar a duda mucho más potente que el que tenía yo habilitado anteriormente.

Únicamente me falta sacar el dominio alternativo del antiguo proveedor (esto lleva su tiempo) y decidir qué hacemos con el SSL.

Es aquí donde entra usted.

PREGUNTA: ¿Qué SSL implementamos?

Tengo hoy en día tres alternativas:

• SSL certificado: Que como ya dije, descartaría a no ser que de verdad fuera estrictamente necesario. No por el coste que conlleva (tengo el primer año gratuito), sino porque si de verdad queremos que el SSL sea el protocolo de comunicación por defecto, debe ser democrático para cualquiera, y no solo accesible por los que lo puedan pagar.
• SSL de Let’s Encrypt: El programa de la EFF por ofrecer de manera gratuita un SSL a cualquier interesado es a priori lo más cómodo. SiteGround se encarga de todo, simplemente pidiéndolo desde su CPanel. Pero tiene una parte mala y es que si habilito este SSL y quiero tener también el CDN de CloudFlare, tendría que contratar una cuenta de pago de CloudFlare.
• SSL Flexible de CloudFlare: La tercera opción, que pasa por gestionar yo el tema directamente con CloudFlare y habilitar el SSL y el CDN con ellos de manera gratuita.

Es decir, que la duda está entre si utilizamos Let’s Encrypt y no tenemos los beneficios de CloudFlare (éste se encarga de replicar nuestra página a lo largo y ancho del mundo, de forma que un usuario que entra desde México, por ejemplo, se le suministrarán la mayoría de recursos desde un CPD cercano, teniendo que cargar desde europa apenas nada), o bien me lío este fin de semana con la configuración de CloudFlare, teniendo las dos cosas.

Eso sí, hay que considerar un último punto, y es que CloudFlare habilitó recientemente unas medidas dictatoriales con aquellos que navegan desde redes privadas como TOR, obligándoles a pasar, de vez en cuando, captchas para seguir navegando.

La pregunta que le hago, y de la cual me gustaría que me respondiera vía comentarios, es si le parece que esta página carga de media mejor que la mayoría de páginas que a diario visita.

Lanzo esta pregunta para tomar una decisión.

• Si la página, con la configuración actual, carga lo suficientemente rápido tanto para los usuarios europeos como para los americanos, me declino a usar Let’s Encrypt, que es más cómodo de implementar y así no molesto a ese reducido porcentaje de lectores que me visitan vía TOR y compañía.
• Si la página, con la configuración actual, se siente pesada para un porcentaje significativo de usuarios, tendré que anteponer el bien de la mayoría, implementando CloudFlare y SSL Flexible, y molestando puntualmente a los que navegáis por TOR.

Simplemente con un mensaje rápido, en plan, “Pues a mí me va genial, Pablo”, o “La verdad es que tu página me carga más lenta que la mayoría de páginas” me sirve.

Con ello, este fin de semana me pongo con uno u otro tema, y cuando ya esté todo correctamente implementado, indistintamente de si al final nos decidimos por uno u otro, publicaré un tutorial de cómo hacerlo con CloudFlare, que ya lo tengo prácticamente escrito de la última vez, y que resulta una verdadera odisea :).

¡Muchas gracias!

P.D.: También es verdad que se espera una carga ligeramente mejor cuando tengamos SSL implementado, habida cuenta de la configuración Apache+PHP7+SSL (ergo HTTP/2) que pasaríamos a tener.

________

¿Quieres conocer cuáles son mis dispositivos de trabajo y juego preferidos?

Revisa mi setup de trabajo, viaje y juego (ES).

Y si te gustaría ver más de estos análisis por aquí. Si el contenido que realizo te sirve en tu día a día, piénsate si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.