La creación de un sitio web súper rápido y seguro con un CMS no es gran cosa. ¿O es eso?

¿Puedo romper tu sitio? ¿Tiene algún script sobrante que pueda aprovechar? ¿Existe alguna forma de robar sus credenciales y cambiar el contenido de su sitio? ¿Puedo acceder a información privada? ¿No? ¿Estás seguro? ¿O nunca lo descubriré porque tu página tarda mucho en cargarse?

En algún momento, al crear un sitio web, debe pensar en el rendimiento y la seguridad. No importa si está trabajando en su sitio web personal o en el sitio web de su cliente. Es lo mismo que hacer una copia de seguridad de sus archivos locales. Hay personas que realizan copias de seguridad periódicas y personas que aún no han perdido ninguna, por lo que están menos inclinadas a hacerlo.

CMS tradicional

Si está utilizando un sistema de gestión de contenido (CMS) tradicional, la situación es más complicada para usted. Estos sistemas contienen muchas funciones. Deben cubrir todos los posibles casos de uso que pueda tener cualquier sitio web. Eso significa código. Mucho código. Miles de archivos. Y eso no es todo: las interfaces de administración deben proporcionar una interfaz de usuario agradable para que pueda configurar todas estas funciones. Potencialmente, otros miles de archivos.

Seguridad

No es tu código, ¿verdad? Entonces ya debería estar seguro. Bueno, muchos proveedores de CMS hacen todo lo posible para garantizar que sus implementaciones sean seguras. Todavía tienen que cubrir muchos archivos. Y cada archivo puede contener un error, algún código que se dejó atrás o quizás un parámetro de cadena de consulta que expone una base de datos. Eso en sí mismo puede crear una vulnerabilidad potencial.

El uso de CMS de código abierto puede ser aún más peligroso, ya que la implementación se conoce públicamente. Sí, puede argumentar que el código abierto es ventajoso. Cualquiera puede contribuir y solucionar los problemas encontrados. Pero, esto solo cubre problemas que ya se conocen. Los atacantes probablemente se guardarían sus hazañas para sí mismos. Incluso si se encontró y solucionó un problema, aún debe esforzarse mucho para asegurarse de que su sitio web se mantenga actualizado. Debe realizar actualizaciones cada vez que se lanza una revisión de seguridad.

Si está interesado en las estadísticas del mundo real, eche un vistazo al informe de sitios web pirateados de Sucuri.

Entonces, ¿qué querrían hacer los atacantes con su sitio web? Básicamente, quieren apoderarse de sus datos, por lo que pueden hacer un mal uso de su sitio web al:

  • Obtener acceso a su base de datos a través de uno de los scripts. Este suele ser el caso de los scripts sobrantes personalizados, las páginas de prueba y otros.
  • Comprometer y hacer un mal uso de sus datos secretos. Los archivos de configuración son una opción de almacenamiento típica para varias claves secretas y credenciales para otros servicios o bases de datos.
  • Modificar el contenido de su sitio web.
  • Hacer que su sitio web sea inaccesible, es decir, cerrarlo.

Actuación

Cuando implementa su sitio web en un CMS tradicional, generalmente necesita personalizarlo, por lo que hay archivos del CMS y sus archivos personalizados. Todos ellos deben compilarse y luego, junto con las bibliotecas precompiladas, llevarlos a la memoria del servidor antes de que el servidor pueda comenzar a procesar las solicitudes a su sitio web. O peor aún, si está utilizando una solución basada en un lenguaje interpretado como PHP, interprete todo el código para cada solicitud.

De todos modos, su sitio web parece funcionar bien, entonces, ¿por qué debería ser una preocupación? Bueno porque:

  • usted paga por la potencia informática de su servidor
  • compila y copia código de funcionalidades que nunca tiene la intención de usar
  • los visitantes de su sitio web esperan la respuesta

El tiempo hasta el primer byte de estos sitios web puede ser muy superior a 1 segundo. Claro, se puede optimizar, pero luego gasta tiempo y dinero en descubrir cómo mitigar los problemas de rendimiento y, por lo general, termina aumentando la CPU y la memoria, o peor aún, agregando un servidor adicional.

Verifique su sitio usando Google PageSpeed ​​u obtenga un análisis más detallado usando SpeedCurve para ver cómo está funcionando su sitio web.

Sitios web basados ​​en API

Los sitios web creados sobre una API permiten una gran flexibilidad. Pregúntese, ¿necesita gestión de contenido? Si es así, puede utilizar un CMS sin cabeza. ¿Necesita almacenar envíos de formularios? Perfecto, usa un formulario de servicio. ¿Está creando un sitio web para un hotel de montaña y desea mostrar un pronóstico del tiempo? Hay un servicio meteorológico con su API para ti.

El número de archivos utilizados para dichos sitios web corresponde a su funcionalidad. Pero, ¿qué pasa con la interfaz de administración para la edición de contenido? No se preocupe. El CMS sin cabeza se encarga de esa parte por usted, sin ningún código adicional que deba alojar o mantener.

Seguridad

Al utilizar los servicios de API, no necesita un servicio de administración en la parte superior de su sitio web. Configura todos los componentes al crear el sitio web. Como el componente meteorológico que debería mostrar un pronóstico del tiempo durante tres días. O que debería haber cuatro publicaciones de blog en la página principal. El resto del contenido dinámico se puede administrar en el CMS sin cabeza.

El principal beneficio de este enfoque es que no necesita una base de datos. Así es, no hay un solo punto de almacenamiento de datos al que un atacante pueda acceder.

Si su sitio web está basado en JavaScript, su implementación es básicamente abierta. Se puede compilar, pero todo lo que se proporciona al navegador es legible. Ésta es otra ventaja más. Sí, cualquiera puede consultar los puntos finales de los servicios directamente. El contenido publicado que obtiene de ellos se muestra en su sitio web de todos modos, solo que se transforma en una imagen más agradable. Es como con artículos de noticias en sitios web y lectores de RSS. Para el contenido sensible, siempre puede autenticar a cada usuario a través de otro servicio, obtener su token de acceso único y usarlo para solicitar contenido sensible a través de un protocolo seguro.

Si tiene en cuenta que la implementación de JS está abierta a todos y trata los datos confidenciales de la manera correcta, tendrá mucho menos trabajo que hacer para que su sitio web sea seguro. No tener una base de datos y consumir todos los servicios de API a través de canales seguros cierra casi todas las puertas para un atacante potencial.

Actuación

En este escenario, el servidor web solo proporciona activos. La lógica empresarial de su aplicación se almacena en un archivo JS. El contenido de varios puntos finales se recopila a través de solicitudes asincrónicas por parte de los navegadores de los visitantes.

¿Solicitudes asíncronas para obtener contenido de servicios de terceros? Eso debe ser lento, ¿verdad? Bueno, seguro, toman algo de tiempo. Sin embargo, sus puntos finales de entrega generalmente están diseñados para ser rápidos, alojados en la nube y muy flexibles. También puede elegir un CMS sin cabeza que use un CDN para la entrega, uno de ellos es Kentico Cloud. De esa manera, la solicitud siempre será manejada por el centro de datos geográficamente más cercano a cada uno de sus visitantes.

Incluso si utiliza varios servicios para crear una sola página, todas estas solicitudes son asincrónicas. Los visitantes esperan solo al más lento. Cuando una página se compone en un servidor utilizando CMS tradicional, toda la comunicación con la base de datos y otros servicios suele ser sincrónica. Por lo tanto, el servidor espera a que finalice cada transacción antes de iniciar otra. Y, una vez hecho todo esto, todo se ensambla y se envía como una gran respuesta.

Observe cuánto tiempo tardó el servidor web en procesar las solicitudes entrantes (fondo amarillo claro). Durante todo este tiempo, el visitante está esperando activamente y no puede comenzar a descargar imágenes y otros activos. Serán conocidos por el navegador del visitante solo después de que se reciba la respuesta.

Un sitio web basado en API es mucho más rápido, ya que la respuesta inicial con un archivo HTML estático es instantánea. El navegador descarga la lógica empresarial del sitio web como uno de los activos y genera todas las solicitudes de contenido asincrónicas posteriores. El visitante ve una página completamente renderizada mucho más rápido y también ve que algo está sucediendo. Cuando esperan una página renderizada por el servidor, todo lo que ven es un precargador en la barra de direcciones de su navegador. La mejora general del rendimiento del sitio web basado en API es en este caso superior al 50%. Puede ser mucho mayor dependiendo de la implementación del sitio web.

Sitios web estáticos

Entonces, ¿por qué nos molestaríamos en resolver el rendimiento si ya tenemos un sitio web basado en API?

Dado que el servidor web solo proporciona archivos y activos estáticos, su rendimiento es bueno. El hecho de que el contenido dinámico se recopile más tarde, cuando el sitio web se muestra en los navegadores de los visitantes, puede provocar algunos artefactos. Los visitantes pueden ver un componente vacío que se llena cuando recibe datos de una solicitud asincrónica, y así sucesivamente. Las personas con una conexión a Internet lenta o que utilizan computadoras antiguas pueden encontrar esto molesto.

¿Qué podemos hacer al respecto? No, no agregaremos ningún precargador. ¿Cómo te hace sentir cuando ves un precargador infinito que simplemente gira y gira y gira? Podemos hacer que nuestros sitios web sean estáticos, pero mantenerlos dinámicos.

El concepto de sitios estáticos se trata de la salida de su sitio web. Comienza con el contenido. Los editores no suelen actualizar el contenido con tanta frecuencia. El sitio web debe redactarse en cada solicitud (como hacen los CMS tradicionales). La idea es similar al almacenamiento en caché: almacenar datos o páginas generados en la memoria. Pero los sitios estáticos van un poco más lejos. Todo el sitio web, todas las páginas con todo el contenido, se genera cada vez que un editor publica contenido. Entonces, si tiene 153 publicaciones de blog en su blog, el sitio web ahora tendrá 153 páginas estáticas (más algunas otras como la página de inicio, contacto y más).

¿Cómo vas a gestionar 153 páginas? Bueno, no es así. Aún administra solo la implementación de una sola página dinámica. El sitio estático se genera combinando su implementación con el contenido de un CMS sin cabeza. Entonces, cuando hay contenido nuevo, el sitio se genera automáticamente nuevamente.

Verá que el beneficio de la velocidad no es tan significativo en comparación con los sitios web dinámicos basados ​​en API. Sin embargo:

  • sus visitantes obtienen la página y todo el contenido en la primera respuesta. No mirarán una página que se está creando. Sus navegadores no necesitan crear solicitudes asincrónicas adicionales de contenido
  • todas las solicitudes posteriores se comportan de la misma manera
  • los visitantes navegan entre un conjunto de páginas estáticas que es muy rápido
  • Algunas herramientas para la generación de sitios estáticos permiten características interesantes adicionales para los visitantes, como la carga previa de páginas vinculadas (lo que hace que navegar a ellas sea instantáneo) o mostrar imágenes en baja calidad antes de que se descarguen por completo

Todo eso dejará a sus visitantes con la impresión de un sitio web increíblemente rápido.

Por supuesto, cada sitio web es diferente. Es posible que necesite algunas funciones de personalización o desee mostrar contenido confidencial. En esos casos, puede combinar ambos enfoques. Tener un sitio web estático y seguir utilizando servicios basados ​​en API para ofrecer contenido que varía entre los visitantes.

Conclusión

Los aspectos de rendimiento y seguridad de cada sitio son muy importantes. Los CMS tradicionales suelen requerir más recursos que los sitios web basados ​​en API, pero brindan más funciones listas para usar.

Por otro lado, los sitios web basados ​​en API son mucho más rápidos y seguros. Le permiten ahorrar dinero en alojamiento y brindar una mejor experiencia a sus visitantes.

Los sitios estáticos se están convirtiendo en un gran éxito hoy en día, ya que su rendimiento es el mejor con diferencia. También le permiten crear sitios parcialmente estáticos y parcialmente dinámicos basados ​​en JavaScript que los motores de búsqueda pueden indexar muy bien.

¿Tu sitio web ya es estático? ¿Ha utilizado algún generador de sitios estáticos? Hágame saber sobre su experiencia en la sección de comentarios a continuación.

En mi próximo artículo, le mostraré cómo crear un sitio web en Vue.js utilizando un generador de sitios estáticos.

Otros artículos de la serie:

  1. Cómo empezar a crear un sitio web impresionante por primera vez
  2. ¿Cómo decidir cuál es la mejor tecnología para su sitio web?
  3. Cómo potenciar su sitio web con Vue.js y con un mínimo esfuerzo
  4. Cómo combinar un CMS sin cabeza con un sitio web Vue.js y Pay Zero
  5. Cómo hacer que los envíos de formularios sean seguros en un sitio web de API
  6. La creación de un sitio web súper rápido y seguro con un CMS no es gran cosa. ¿O es eso?
  7. Cómo generar un sitio web estático con Vue.js en poco tiempo
  8. Cómo configurar rápidamente un proceso de compilación para un sitio estático