Cómo Smashing Magazine gestiona el contenido: Migración de WordPress a JAMstack

Este artículo ha sido amablemente apoyado por nuestros queridos amigos de Netlify, una plataforma todo en uno para automatizar proyectos web modernos. ¡Gracias!

Cada vez que los desarrolladores hablan de WordPress, su porcentaje de cuota de mercado cambia. “ ¡ El 20% de todos los sitios están en WordPress! ” “ ¡ El 40% de todos los sitios están en WordPress! Cualquiera que sea el porcentaje, el mensaje es el mismo: en términos de adopción, WordPress es MASIVO.

Entonces, ¿por qué, con ese tipo de adopción, un sitio que usa WordPress consideraría cambiarse a JAMstack? En esta serie de artículos de dos partes, cubriremos cómo se ve una migración real de WordPress, utilizando un estudio de caso del mismo sitio que está leyendo en este momento.

Hablaremos de las ganancias y pérdidas, las cosas que desearíamos haber sabido antes y lo que nos sorprendió. Y luego lo seguiremos con una demostración técnica de una posible ruta de migración, no fuera de WordPress por completo, sino cómo puede servir WordPress desacoplado para que pueda tener lo mejor de ambos mundos: una implementación JAMstack de WordPress que le brinda todo el poder de su tablero y funcionalidad, con mejor rendimiento y seguridad.

¡Vamos a profundizar en!

¿Por qué?

En 2015, el cofundador de Netlify, Mathias Biilmann, y el fundador de Smashing, Vitaly Friedman, hablaron de negocios. A medida que la arquitectura JAMstack comenzó a circular, Smashing se interesó más en la idea de la pila. Vitaly y Markus (exdirector general de Smashing) le preguntaron a Matt qué sucedería si Smashing migrara de su sitio tradicional de WordPress/LAMPstack a una arquitectura JAMstack.

Como experimento, Matt raspó todo el HTML de Smashing y lo alojó en Netlify, entregando el contenido de forma estática desde un CDN. Los resultados fueron convincentes: ¡la versión estática es más de seis veces más rápida en promedio!

Este tipo de arquitectura funciona tan bien en parte porque las páginas no se compilan a pedido a medida que las visita. Dado que está sirviendo contenido prediseñado directamente desde una red de entrega de contenido , el sitio ya está "allí" y listo para el usuario.

Dado que está sirviendo a través de CDN, también puede distribuir el contenido en todo el mundo, más cerca de los visitantes potenciales. No hay un punto central de origen, lo cual es vital en el caso de cualquier publicación en línea que quiera ser rápida para todos sus lectores.

Así que el escenario estaba listo. Smashing Magazine migró a JAMstack, a Netlify como plataforma en particular. En sus 10 años de funcionamiento, Smashing había pasado de ser una pequeña publicación en línea a un enorme blog de WordPress, que vendía cosas como libros, entradas para conferencias y talleres.

Había algunas piezas de este sitio:

• Blog de WordPress
• Panel de empleos de Rails
• Tienda Shopify
• Otro CMS para el sitio de la conferencia

Cuando Netlify comenzó la migración por primera vez, el sitio sufría algunos problemas de rendimiento, abrumado por 20 000 comentarios y miles de artículos. Smashing también estaba interesado en la autenticación como parte de un nuevo plan de suscripción, así como en un rediseño para una apariencia más moderna.

Fiabilidad

Smashing logra regularmente lo que sueñan otras plataformas: artículos compartidos ampliamente a través de una comunidad enorme. Sin embargo, cuando se alcanzaba un punto de inflexión en el tráfico de una publicación, Smashing solía tener problemas con las interrupciones. Para mitigar esto, se introdujo el uso intensivo de complementos de WordPress en su pila, pero aún lucharon por mantener buenas métricas de tiempo de actividad.

El cambio a Netlify permitió al equipo de Smashing evitar errores de conexión a la base de datos y no preocuparse por el tiempo de inactividad , incluso cuando un artículo tenía una gran cantidad de tráfico. ¿Por qué? Porque cuando se sirve sin un servidor, el contenido preconstruido no tiene que generarse y servirse, ya existe, listo para ser visto. No se solicita nada en el acto, excepto la página completa y estática.

Servir a través de CDN también permitió que Smashing durmiera un poco más tranquilo en términos de seguridad. wp-login.php ha sido durante mucho tiempo una fuente de agujeros de seguridad y vectores de ataque. No se puede acceder al contenido preconstruido de la misma manera y los agujeros de seguridad no son tan omnipresentes.

Invalidación de caché

Smashing había pasado por todos los complementos de almacenamiento en caché de WordPress, con resultados variados y muchos problemas. Vitaly Friedman de Smashing menciona,

“Los principales problemas que tuvimos estaban relacionados con el 'Error al establecer la conexión de la base de datos' que seguíamos teniendo cada dos semanas, y literalmente probamos todos los complementos de almacenamiento en caché de WordPress que había. El rendimiento estuvo bastante bien (en general), pero buscábamos mejorarlo aún más. Además, queríamos lanzar Membresía y conectar todas las diferentes ofertas (conferencias, puestos de trabajo, artículos, libros, libros electrónicos) con una sola plataforma, y ​​fue notablemente difícil de lograr con WordPress en juego”.

El cambio a Netlify permitió que el equipo de Smashing viera la invalidación instantánea de la memoria caché y, al mismo tiempo, sirviera contenido en memoria caché y con buen rendimiento, sin gastos generales adicionales.

Cuando implementa un sitio, los archivos HTML se alojan en el CDN de Netlify. Está optimizado para una alta tasa de aciertos de caché y un tiempo rápido para el primer byte, al tiempo que puede invalidar instantáneamente todos los archivos HTML que han cambiado. Netlify también toma las huellas dactilares de todos los enlaces a activos como archivos CSS, imágenes, fuentes o archivos JS, y sirve a Smashing con encabezados de almacenamiento en caché que los almacenan en caché para siempre. La toma de huellas dactilares garantiza que son únicos y que si actualiza una nueva versión, se sirve la versión más nueva en su lugar.

flujo de trabajo

En cuanto a la configuración existente, una de las principales razones de la migración fue simplemente unificar las propiedades existentes. Tener que cambiar el contexto entre todas estas pilas de tecnología y configuraciones diferentes se convirtió en un problema de mantenimiento difícil que encargó a los ingenieros.

Cuando previamente su infraestructura se dividió entre tantos sistemas diferentes, este proceso de migración también unificó todo , manteniendo el sitio principal, el sitio de la conferencia, las suscripciones y la sección de comercio electrónico trabajando juntos en lugar de mantenerlos por separado con diferentes pilas. Esto ayudó a mantener bajos los costos de desarrollo y la experiencia del desarrollador trabajando en todas las propiedades de manera consistente.

La pieza de migración de WordPress resultó ser la más grande y delicada. Netlify intentó exportar los datos del exportador de WP, solo para descubrir que el contenido tenía incrustaciones que debían conservarse o, en ocasiones, se modificaban con complementos. Para mantener la paridad con lo que había en el sitio, se escribieron una serie de raspadores, desglosados ​​por artículos, activos, comentarios y la página de inicio.

Una vez que se escribió y transformó, se cargó en un nuevo repositorio en GitHub y, en su lugar, se utilizó Netlify CMS. Lo que hace que Netlify CMS sea único es que es liviano e integra editores de contenido en un flujo de trabajo de Git, lo que significa que literalmente extraerá y entregará archivos de rebajas desde un repositorio de Git en lugar de una base de datos. Además, Netlify CMS es independiente de la plataforma y funciona con (casi) todos los generadores de sitios estáticos y sitios almacenados en GitHub.

En ese momento, Sara Soueidan trabajaba para Smashing como desarrolladora front-end independiente en su rediseño. Creó una biblioteca de componentes para construir la arquitectura front-end y comentó cuánto más simple era trabajar con él porque estaba trabajando directamente en git, incluso cuando trabajaba con el CMS.

“Todo lo que puse en el repositorio se está aplicando directamente a la biblioteca de patrones, lo que significa que no tienes que mantener dos conjuntos diferentes de componentes... ¡este tipo de continuidad fue excelente! Todo lo que tengo que hacer es escribir HTML, CSS y JavaScript e ingresar al repositorio y todo funciona como magia. El flujo de trabajo fue fantástico”.

Dicho todo esto, Netlify CMS a veces puede ser demasiado liviano para un caso de uso de alto tráfico y escala. Smashing tiene regularmente autores invitados y un equipo editorial completo. Algunas de las ricas funciones que ofrece WordPress son realmente útiles para este tipo de entornos altamente colaborativos.

Es por eso que en el siguiente tutorial, lo guiaremos a través de un modelo sin cabeza , donde aún puede aprovechar los beneficios del tablero de WordPress para creadores de contenido, pero use WordPress a través de API y haga que el desarrollo dependa de un flujo de trabajo centrado en git así de fácil. para que los desarrolladores también lo mantengan. ¡Manténganse al tanto!

Opciones de marco

En el prototipo inicial que creó Matt Biilmann, escribió todo en Preact mínimo, junto con Hugo, ya que estaba muy centrado en el rendimiento. Solo usó accesorios y mantuvo todo muy liviano. Cuando hizo pasar el proyecto al desarrollador de Smashing, Ilya Pukhalski, para que lo mantuviera, descubrió que a Preact le faltaban algunas características que faltaban para aprovechar el ecosistema de React. Eventualmente, los beneficios de Redux y otras bibliotecas superaron el costo.

Reflexionando ahora, Matt dice que habría usado Vue, que no tenía la cuota de mercado en ese momento (juro que no le pedí que dijera eso). Hice la pregunta obvia: ¿por qué no Svelte? Como la gente con mentalidad de rendimiento tiende a buscar esa biblioteca. Mencionó que Svelte aún no tiene el ecosistema que tiene Vue.

Cuando Matt reflexiona sobre si hubiera seguido usando Hugo o no, dice que ama a Hugo, pero lo que encontró difícil para este proyecto en particular fue que no tenía suficiente sistema de complementos: crear anuncios publicitarios y cosas de que la naturaleza no era lo suficientemente programable con Hugo y necesitaba inyectar guiones para lograrlo. Estos scripts tendían a ralentizar el proceso de compilación. Dicho esto, todavía usamos Hugo para nuestro propio sitio en netlify.com y nos encanta; esta advertencia es extremadamente particular para las necesidades del sitio de Smashing en particular.

Si pudiera hacerlo de nuevo, podría elegir Eleventy, que tiene capacidades ricas en términos de creación de complementos y otras secuencias de comandos extensibles. O, si estuviera usando Vue, Nuxt le habría ofrecido algunas buenas capacidades de complemento al mismo tiempo que le habría permitido ser una buena opción para ese marco, ofreciendo renderizado, enrutamiento y generación estática del lado del servidor.

Construcción de grandes sitios

Hubo un problema que surgió al trabajar con un sitio tan grande como Smashing y tal vez ya puedas descubrir de qué se trata, acabamos de mencionarlo. Es cierto que con cualquier sitio grande de páginas preconstruidas servidas en un CDN, el rendimiento sigue siendo excelente porque no estamos construyendo nada sobre la marcha para los usuarios.

Pero ese beneficio solo puede ocurrir si el sitio está preconstruido, y ese proceso puede llevar mucho tiempo. Si bien los sitios más tradicionales crearán las páginas cuando las solicite, literalmente estamos creando cada página por adelantado en caso de que el usuario la necesite. ¡Hace que el rendimiento sea súper rápido! Pero ese tiempo ahora se descarga al tiempo de desarrollo y publicación: crear cada página puede llevar tiempo.

Esto no es un gran problema con los sitios más pequeños, pero a la escala de Smashing Magazine, debemos pensar un poco más en ese momento, especialmente para que las personas puedan mantener una productividad alta mientras crean contenido activamente a diario.

Lo que hizo Netlify fue crear una carpeta grande /production-articles que contenía la mayor parte de los miles de artículos que ya estaban alojando. Luego, creó un directorio de trabajo separado llamado content/articles donde se podían colocar los artículos que se estaban creando y editando activamente.

Este proceso de compilación significó que todos los que trabajaban en el sitio trabajaron con un lote más pequeño de artículos para el desarrollo local, sin tener que esperar la compilación completa. Este proceso fue administrado por una tarea de trago para preparar los artículos de producción y liberó a Hugo para manejar solo lo que se estaba trabajando activamente.

Una de las desventajas de este enfoque es que aún requiere que se ejecute la compilación completa, lo que hace que el proceso sea lento. En una publicación más pequeña, esto probablemente importaría menos, pero a la escala de Smashing, ralentiza el proceso de publicación.

API de código abierto

Al principio, mencionamos que, entre otras cosas, Smashing estaba interesado en migrar su solución de comercio electrónico existente, manejar comentarios fuera de WordPress y agregar funcionalidad para la autenticación. Todas estas piezas de funcionalidad se crearon con soluciones de código abierto que mantiene Netlify, dividiéndolas en API sin estado:

• GoTell
  Una API y una herramienta de compilación para manejar grandes cantidades de comentarios.
• GoCommerce
  Una pequeña API basada en Go para sitios de comercio electrónico que maneja pedidos y pagos.
• GoTrue
  Una pequeña API de código abierto escrita en Golang que puede actuar como un servicio de API autónomo para gestionar el registro y la autenticación de usuarios para proyectos. Se basa en OAuth2 y JWT y manejará el registro de usuarios, la autenticación y los datos de usuario personalizados.

Cada una de estas piezas requirió migración y factores únicos propios, y aunque están fuera del alcance de este artículo, todas están cubiertas en un libro gratuito que Matt coescribió llamado " Desarrollo web moderno en JAMstack ". También haremos algunas inmersiones profundas como esta, con ejemplos útiles, en la búsqueda y la autenticación, en publicaciones posteriores.

Conclusión

La migración transcurrió a la perfección. ¿Aplastantemente? Eh… salió bien. Smashing no fue penalizado por su propio éxito: cuando aparecía un artículo popular, podían publicar el contenido de manera constante, sin tener que abandonar grandes cargas. Junto con esto, el cambio a una infraestructura JAMstack trajo un mejor rendimiento y seguridad.

Markus Seyfferth, exdirector ejecutivo de Smashing Magazine, señaló:

"El tiempo de carga inicial es mucho más rápido que antes... antes teníamos que esperar 800 ms a que se sirviera el archivo HTML y ahora son 80 ms ".

Este proceso fue exitoso y, como cualquier gran proyecto de ingeniería, se aprendieron lecciones en el camino. En el próximo artículo de esta serie, veremos un tutorial y una demostración de lo que recomendaríamos dado lo que hemos aprendido. Si desea modernizar su desarrollo de WordPress y aprovechar los beneficios de rendimiento y seguridad de JAMstack, ¡siga leyendo!