Posted on

La diferencia entre los algoritmos de compresión Brotli y Gzip para acelerar tu sitio web

Compresión Brotli y Gzip

¿Estás buscando formas gratuitas de hacer que tu sitio web sea más rápido? Una forma en que cada propietario de un sitio web pueda obtener un poco de velocidad gratis es activar la compresión en el servidor. Cuando tanto el servidor web como el navegador con el que está conversando entienden un algoritmo de compresión común, entonces los datos que realmente se envían por cable se pueden comprimir. Los datos comprimidos son más pequeños. Los datos más pequeños se reciben más rápido.

¿Qué es la compresión?

Cuando ingresas una URL en tu navegador, el navegador inicia una conversación con el servidor y una de las cosas que le dice es si puede descomprimir contenido y, de ser así, qué “algoritmos” de compresión comprende.

El servidor escucha, y si ha activado la compresión y conoce uno de los algoritmos de compresión que hace el navegador, comprimirá todos los datos y los enviará al navegador.

La mayoría de los navegadores web modernos entienden o “aceptan” contenido codificado en uno de tres algoritmos:

  • Deflate
  • Gzip
  • Brotli

Cuando un navegador web contacta a un servidor, envía un encabezado que se ve así:

Aceptar codificación: br, gzip

Eso le dice al servidor que entiende los datos comprimidos en Brotli (br) o Gzip (gzip). Los servidores tienen la opción de ignorar esto y devolver también datos sin comprimir.

Sin embargo, en general, los datos comprimidos viajan más rápido que los datos sin comprimir. Entonces, tu sitio web llega al navegador más rápido si los datos están comprimidos.

La compresión se aplica principalmente al texto:

  • HTML
  • javascript
  • CSS

Estos constituyen una gran parte de los sitios web modernos en estos días y todos estos pueden comprimirse mediante algoritmos de compresión por parte del servidor.

Por otro lado, tanto la mayoría de los formatos de imagen (jpg, png, etc.) como la mayoría de los formatos de audio (mp3) y otros archivos binarios que no son de texto ya están comprimidos. Comprimirlos no hará ninguna diferencia, por lo que, independientemente del encabezado de codificación de aceptación, los servidores los enviarán tal como están.

Como se indicó anteriormente, la mayoría de los navegadores web modernos aceptarán 3 algoritmos de compresión principales. La mayoría de los servidores ahora han migrado a uno o ambos de los dos más populares, Gzip y Brotli.

¿Qué es la compresión Gzip?

Los dos algoritmos de compresión más comunes son Gzip y Brotli. Gzip es el más antiguo y común de los dos. Fue escrito por Jean-loup Gailly y Mark Adler. La versión beta inicial se realizó en 1992. La primera versión real, la versión 1.0, se lanzó a principios de 1993. En 1992, justo cuando la web comenzaba a ser un concepto extendido para la mayoría de las personas.

Gzip fue diseñado como una biblioteca de compresión para todo uso. Las teorías detrás de Gzip se basaron en el algoritmo de compresión anterior, DEFLATE.

Debido a su popularidad, y al hecho de que es muy bueno para hacer archivos pequeños, todavía se usa ampliamente hoy en día tanto en diferentes sistemas operativos como en un algoritmo de compresión principal para servidores web.

¿Qué es la compresión de Brotli?

Brotli fue desarrollado por los empleados de Google Jyrki Alakuijala y Zoltán Szabadka en 2013. Originalmente, Google estaba buscando una mejor manera de comprimir archivos WOT que son fuentes web.

Gzip originalmente estaba destinado a comprimir archivos y se ha adaptado para comprimir transmisiones para que pueda funcionar en la web. Brotli, por otro lado, fue diseñado desde el principio para comprimir flujos. Esto lo convierte en una mejor opción para que los servidores web compriman el contenido antes de transmitirlo a un navegador.

En 2015, Google lanzó la especificación Brotli para HTTP. Además de especificar cómo el navegador debe notificar al servidor que puede descomprimir Brotli enviando un encabezado “Codificación de contenido: br”, los ingenieros de Google también realizaron otras mejoras en Brotli que lo hicieron aún más rápido para comprimir contenido web.

¿Cuál es la diferencia entre la compresión Brotli y Gzip?

Si bien ambos tienen su origen en el algoritmo LZ77, Gzip fue diseñado específicamente para comprimir archivos. La biblioteca se ha incorporado a muchos programas diferentes que necesitan comprimir archivos. La biblioteca se incorporó a los servidores web cuando la compresión de contenido comenzó a ser la norma. Era uno de los dos algoritmos de compresión especificados en RFC 2616, la especificación HTTPS 1.1. Si bien no fue diseñado específicamente para operaciones de transmisión como servidores web, se adaptó a ello.

Brotli, por otro lado, fue diseñado específicamente para la web. Google reconoció la necesidad de una forma de comprimir transmisiones de manera más eficiente, por lo que diseñó Brotli.

Ambos algoritmos hacen un buen trabajo para lo que fueron diseñados. Gzip todavía se sigue usando en la web porque es mejor que nada. Sin embargo, a medida que Brotli crece en popularidad, más y más servidores web prefieren Brotli a Gzip. Dada la elección de los dos, Brotli es el predeterminado que usarán muchos servidores. Ha sido la opción predeterminada en todos los servidores de SiteGround desde hace un tiempo.

¡Mira el siguiente video (en inglés) para obtener más información sobre las diferencias entre Brotli y Gzip!

Evaluación comparativa de Brotli y Gzip

Cuando se comparó Brotli con Gzip, se descubrió que comprime mejor los siguientes archivos:

  • JavaScript un 14% más pequeños
  • HTML un 21% más pequeños
  • CSS un 17% más pequeños

Dado que Brotli fue diseñado para comprimir transmisiones sobre la marcha, es más rápido tanto para comprimir contenido en el servidor como para descomprimirlo en el navegador que en gzip. En algunos casos, la descompresión inicial general es hasta un 64% más rápida que Gzip.

¿Cómo puedo habilitar la compresión en mi sitio web?

En términos simples, “activar la compresión” simplemente significa decirle a tu servidor web que comprima todo antes de enviarlo a un navegador que ha anunciado que puede manejar la compresión.

Si eres administrador de un servidor, sabes cómo editar archivos de configuración. Si no eres administrador del servidor, omita esta sección y desplácese directamente a la sección “Si no soy administrador del servidor” a continuación.

Si uso Apache

Si está utilizando el servidor web Apache, hay 2 pasos para habilitar la compresión Brotli:

  • En primer lugar, habilita el módulo apache Brotli. Se incluye de forma predeterminada, pero es posible que no esté habilitado:

$ sudo a2enmod brotli 

  • A continuación, debes editar el archivo de configuración de tu servidor web y decirle al servidor a qué desea aplicar la compresión:

<IfModule mod_brotli.c>

            AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/javascript

</IfModule>

En el ejemplo anterior, le estamos diciendo al servidor web que comprima:

  • HTML
  • Texto sin formato
  • CSS
  • JavaScript

Éstos son los principales tipos de archivos que se pueden comprimir.

Si uso Nginx

Nginx es otro servidor web muy popular. Al igual que Apache, está controlado por archivos de configuración. Debes ubicar tu archivo nginx.conf y agregar las siguientes dos líneas:

load_module modules/ngx_http_brotli_filter_module.so;

load_module modules/ngx_http_brotli_static_module.so;

Luego, en el archivo conf individual de tu sitio web, debes agregar lo siguiente:

brotli on;

brotli_static on;

brotli_types *;

Después de realizar los cambios, ya sea Apache o Nginx, reinicia tu servidor web y ahora responderá con un encabezado de “Codificación de contenido” si el navegador envía un encabezado de “Codificación de aceptación“.

Si no soy administrador del servidor

Si no eres administrador del servidor, en realidad es mucho más fácil para ti habilitar la compresión en tu servidor. Simplemente elige un hosting como SiteGround que lo activa de forma predeterminada. Es fácil.

La mayoría de los hostings de primer nivel como SiteGround están interesados ​​tanto en hacer que tu sitio sea lo más rápido posible como en conservar la mayor cantidad de ancho de banda posible. Éstos son los dos mayores beneficios de habilitar la compresión. Por lo tanto, los hostings de primer nivel activan la compresión de forma predeterminada.

Si no eres un cliente de SiteGround, debes asegurarte de que tu servidor web active la compresión en tu servidor web. Si no lo hacen y no la activan para ti, es hora de encontrar un nuevo hosting.

¿Cómo puedo probar la compresión de Brotli y Gzip?

Entonces, ¿cómo puedo saber si la compresión está activada para mi sitio web? Hay un par de maneras de hacer esto.

El camino difícil

  • Abre un navegador. Voy a usar Chrome en este ejemplo, pero el concepto funcionará con cualquier navegador. Sin embargo, los nombres de las opciones pueden cambiar un poco entre las marcas de los navegadores.
  • Haz clic derecho en cualquier parte del navegador y selecciona “Inspeccionar”
  • Esto abrirá una ventana en el lateral o en la parte inferior y es una ventana muy llena de datos. La ventana tiene varias pestañas con nombres como éste.
    • Elementos
    • Consola
    • Fuentes
    • Red
    • Rendimiento
    • Etc.
  • Busca la pestaña “Red”.
  • En el cuadro de URL de arriba, ingresa la URL de tu sitio web y presiona enter. Esto va a llenar la pestaña de red con muchos registros diferentes. Desplaza atrás hasta el primer registro. Debe ser simplemente el nombre de tu dominio.
  • Haz clic en ese primer registro.
  • Localiza el encabezado “aceptar codificación“. Se ubicará en la sección “Encabezados de solicitud“. Estos son los encabezados que tu navegador envió al servidor. Si no tienes este encabezado, intenta con un navegador diferente porque el servidor no se comprimirá si el navegador no envía el encabezado de compresión.
  • Finalmente, ubica el encabezado “codificación de contenido“. Esto se ubicará en la sección “Encabezados de respuesta“. Estos son los encabezados que tu servidor envió al navegador antes de enviar tu sitio web. Esto le dice al navegador que el servidor eligió Brotli como la compresión y debe descomprimir los flujos de contenido a medida que ingresan antes de mostrarlos.

Honestamente, la mayoría de los desarrolladores, incluido yo mismo, lo hacen de esta manera. Sí, para los no iniciados, este el camino difícil. Si normalmente no usas la pestaña Inspeccionar para profundizar en la conversación que tienen tu navegador y el servidor, entonces puede ser confuso. Sin embargo, una vez que comprendas qué buscar y dónde, esta forma requiere muy poco esfuerzo y está disponible en todas partes.

La manera fácil

Aún así, hay personas que no se sienten cómodas haciéndolo de esta manera. Para aquellos de vosotros que están leyendo este artículo y caen en esta categoría, os presento la manera fácil.

En serio, eso es todo. Al revisar mi sitio, obtuve los siguientes resultados.

Esto no solo me dice que mi servidor web es capaz de codificar mi sitio web en Brotli, sino que también me dice que el 80,66% de mi sitio web se encuentra encriptado.

Conclusión

La compresión en los sitios web ahora es la norma porque ayuda a que tu sitio se cargue más rápido.


Actualmente, Brotli es el mejor algoritmo de compresión disponible para sitios web. Si ves que no se te está ofreciendo Brotli, muévete a un proveedor de alojamiento web que lo tenga habilitado. ¡Un proveedor de alojamiento como SiteGround! Puedes obtener archivos más pequeños entre un 15 y un 20 % con Brotli, y los archivos más pequeños significan un sitio web que se carga más rápido. Obtenga más información sobre la implementación de SiteGround en nuestro artículo, Más velocidad del sitio con el algoritmo de compresión de Brotli. También puedes aprovechar todos nuestros otros aceleradores de velocidad que harán que tu sitio vuela.

Posted on

Optimización del uso de RAM que hace MySQL en la nube

Configuración RAM para bases de datos mySQL en SiteGround

Durante los últimos 6 meses, todo ha sido cuestión de velocidad en SiteGround. Hemos mejorado hasta 5 veces más el rendimiento de los sitios web alojados en SiteGround al lanzar nuevas configuraciones de PHP Ultrarrápido y MySQL, y habilitar la caché dinámica (almacenamiento en caché de página completa) para todos los sitios web. Como siguiente paso importante en este proceso, nos hemos centrado en nuestros servidores cloud y estamos muy contentos de anunciar que hemos implementado un nuevo algoritmo dinámico de asignación de memoria RAM que mejora aún más la utilización de recursos de MySQL y hace que los sitios web alojados en nuestros planes de hosting cloud que utilizan bases de datos se ejecuten más rápido.

¿Cuál es el problema con MySQL?

MySQL puede ser una verdadera fuente de problemas. Cuando le dejamos que actúe a sus anchas, devora recursos y sigue pidiendo más. Si no obtiene lo que quiere, comienza a ralentizar los procesos uno tras otro y se convierte en un cuello de botella para las aplicaciones impulsadas por bases de datos como WordPress. Por lo tanto, la configuración de MySQL es la clave para resolver muchos de los problemas de lentitud web, pero muchos webmasters tienen dificultades para rastrear el origen del rendimiento lento. No se trata solo de agregar más RAM. Esta RAM debe utilizarse inteligentemente de una manera que permita que MySQL se ejecute lo más rápido posible, pero aún así evitar consumir todos los recursos disponibles.

Hasta el momento, hemos estado ayudando a nuestros clientes a evaluar cuál es una asignación óptima de RAM para MySQL, dados los servicios específicos que se ejecutan en el sitio web y las especificaciones disponibles, y resolviéndolos manualmente caso por caso. Sin embargo, ahora hemos encontrado una forma de automatizar el proceso y disminuir la cantidad de trabajo y experiencia requerida por nuestros clientes.

[subscribe_cta]

¿Qué hemos hecho?

Hemos implementado una configuración dinámica en nuestros servidores cloud que depende de la cantidad de memoria que tenga tu cuenta de hosting cloud. Esto significa que la configuración de MySQL se ajustará según los recursos disponibles. No solo iniciaremos nuevas instancias Cloud con configuraciones predefinidas, sino que, en caso de un evento de autoescalado (o actualización), la configuración del servidor se ajustará para una utilización óptima de los recursos sin intervención manual. Esto significa que las consultas a la base de datos se procesarán más rápido y el uso de E/S será menor. Por último, pero no menos importante, la RAM adicional que añadas ahora se utilizará de manera más eficiente e incluso los sitios web de rápido crecimiento tendrán que añadir menos RAM y con menos frecuencia, por lo que te supondrá un gran ahorro en tus gastos de hosting.

¿Quién se puede beneficiar de ello?

¡Este nuevo sistema ya está implementado en todos los servidores cloud de SiteGround! No es necesario habilitarlo ni configurarlo. Solo mantente al tanto de las mejoras de rendimiento que ya puedes experimentar y déjanos un comentario en este artículo contándonos tu experiencia. Cuanto más intensivo sea el uso de bases de datos de tu sitio web (como, por ejemplo, sitios de membresía, tiendas online, foros, etc.), ¡mayor será la mejora del cambio!

Posted on

El coste oculto de lo gratis

el coste escondido de lo gratuito

He estado involucrado en el movimiento del software open-source (no confundir con el software libre) desde sus inicios. Con el tiempo, he visto cambiar su percepción. Al principio, había mucha gente escribiendo software y contribuyendo porque podía. Les hacía sentir bien aportar a los demás.

Los usuarios de software open-source reconocieron este regalo que se les estaba dando y lo respetaron, al igual que al talento de quienes lo daban. Muchos usuarios contribuyeron a sus proyectos favoritos a través de código, documentación, promoción y, a veces, incluso dinero.

Con el tiempo, las cosas han cambiado. Hoy en día veo a más personas que utilizan software open-source porque creen que es gratis. Piensan que, como no tuvieron que pagarle a un programador por sus esfuerzos, se libran. A veces, esto es cierto, a veces puedes instalar un software y comenzar a generar valor a partir de él. WordPress solía ser así.

Sin embargo, actualmente el software, incluso el Open source, es complejo. Sí, WordPress solía tener la “instalación en 5 minutos”, y sí, es posible que aún puedas instalar WordPress así de rápido, pero si tu objetivo es hacer algo más que escribir en tu propio blog, tendrás que añadir algunas horas o días a esos 5 minutos.

A día de hoy, el software es complicado. Los temas de WordPress solían ser bastante simples, pero ahora son más complejos, con páginas de ajustes y muchas opciones de configuración. Opciones que, si no estás familiarizado con el tema, pueden resultar difíciles de navegar.

Este es el coste oculto de lo gratis. Muy alto actualmente.

Muchos plugins son “gratuitos” pero requieren que te suscribas a su servicio de backend subyacente. Técnicamente son gratis, pero igual te van a costar. Otros plugins ofrecen una versión gratuita, pero bloquean sus mejores funciones hasta que pagues. Nuevamente, técnicamente gratis, pero si quieres que hagan cosas interesantes, tendrás que pagar.

No me malinterpretes, no estoy defendiendo que todo el software sea gratuito. Como alguien que se gana la vida escribiendo código, recomiendo encarecidamente pagar a los desarrolladores. Es solo que, como propietario de un sitio no técnico, debes comprender el coste de “gratis”.

[subscribe_cta]

Prepárate para contratar a alguien que te ayude. En la mayoría de los casos, necesitarás:

  • Un Project Manager. Esta es una persona técnica, pero no necesariamente un programador. Entienden sobre WordPress, los plugins y saben cómo hacer que trabajen juntos para hacer las cosas. También saben cuándo se necesita un desarrollador y, por lo general, conocen a unos cuantos a los que poder pedir ayuda.
  • Un diseñador. Definitivamente necesitarás a alguien que pueda hacer que tu sitio web se vea bien. Puntos extra si también es un experto en experiencia de usuario (UX) para que pueda hacer que tu web sea fácil de entender y usar.
  • Un copywriter. (Pensaste que iba a decir desarrollador, ¿no?) Sí, vas a necesitar un redactor, alguien que sea un artífice de las palabras. Vas a querer que vean cada palabra de tu sitio web y se asegure de que lo que estás diciendo sea claro y fácil de entender para el usuario.
  • Opcionalmente, es posible que necesites un desarrollador. Si es así, tu project manager lo sabrá y debería saber a quién contratar. No te adelantes en contratar a tu sobrina y ponerla en el equipo. Deja que los expertos hagan el trabajo por el que los contrataste.

Una vez que hayas creado tu sitio web, todavía no será gratuito. Asegúrate de alojarlo en un hosting de buena reputación que entienda de WordPress. Puede ser una sorpresa para algunos de vosotros, pero tengo sitios web que no están alojados en SiteGround. Algunas de mis instalaciones de WordPress están alojadas en un servidor virtual que yo mismo administro. Entiendo lo que se debe hacer y entiendo los riesgos de administrar mi propio servidor.

Los proyectos que yo mismo alojo son proyectos complementarios con requisitos especiales que muchos proveedores de hosting no proporcionan de forma inmediata. Si bien en un sentido técnico, sí, cada sitio adicional que pongo en mi servidor virtual es “gratis”, también es una cosa más de la que tengo que preocuparme. Mi tiempo no es gratis, por lo que alojar sitios web en ese servidor resulta muy caro.

Para todos mis sitios web que no tienen requisitos muy específicos, uso SiteGround. Después de más de 25 años administrando servidores web y más de 15 años administrando WordPress, sé lo que necesito en un proveedor de alojamiento web, y SiteGround marca todas las casillas.

El software gratuito y libre (FOSS) es increíble. Literalmente impulsa el mundo en el que vivimos. Pero muchas veces, gratis solo se aplica al precio que pagas por el código en sí. Cuando te estes preparando para lanzar tu próximo sitio web, ten en cuenta algo más que el coste del código. Si tu sitio web va a añadir valor a tu empresa, prepara un presupuesto que te permita hacerlo bien. No te olvides del alto coste de la gratuidad.

Posted on

Nueva configuración MySQL para un procesamiento más rápido de consultas

nueva configuracion MYSQL de SiteGround

Dos de las razones más frecuentes por las que un sitio web puede ser lento son los procesos PHP no optimizados y las pesadas consultas de MySQL. La optimización del código del sitio web es siempre una parte crucial de la batalla constante por una mayor velocidad del sitio web. Sin embargo, los webmasters que se alojan con SiteGround siempre han tenido un aliado confiable a su lado en esta búsqueda.

Recientemente hemos anunciado el nuevo PHP ultrarrápido, que acelera significativamente el procesamiento de scripts PHP y mejora el rendimiento del sitio web hasta en un 30%.

Como siguiente paso natural en nuestros esfuerzos por ofrecer un servicio premium y superrápido, hemos implementado una solución del lado del servidor para optimizar las consultas de la base de datos que ya ha reducido el número de consultas lentas entre 10 y 20 veces.

¿Qué son las consultas MySQL lentas y por qué son importantes?

Si estás administrando un sitio activo con una base de datos, probablemente comprendas que cuando un visitante accede a tu sitio, hay toneladas de scripts que comienzan a ejecutarse, algunos de los cuales solicitan información a tu base de datos.

Por ejemplo, si tienes una tienda online y un visitante está tratando de comprar un artículo, tu tienda debe verificar su disponibilidad en la base de datos y mostrar si es posible realizar un pedido.

Esa verificación activa una consulta MySQL y, dependiendo de cómo se escriba esa consulta, puede ser bastante pesada y llevar mucho tiempo al servidor procesarla .

Para ti, como webmaster, estas consultas lentas son un problema porque perderás clientes.

¿Sabes cómo los visitantes abandonan el sitio cuando tienen que esperar más de 2-3 segundos para que se cargue una página? Bueno, lo entiendes.

Para nosotros, como tu proveedor de hosting, no nos gusta cuando nuestros servidores se ralentizan al procesar demasiadas consultas lentas porque esto significa que la CPU y la RAM de la máquina se bloquean y no se pueden usar para otros procesos, que también son importantes para el tuyo y los otros sitios web alojados en el servidor.

¿Qué hemos hecho?

La batalla con las consultas lentas de MySQL es un proceso continuo que involucra tanto al webmaster como al anfitrión. Es por eso que recientemente lanzamos una nueva configuración de MySQL en nuestros servidores, que adopta un enfoque innovador para distribuir la RAM del servidor y asignarla a MySQL.

La nueva configuración permite procesar simultáneamente un número mucho mayor de solicitudes paralelas y esto tiene un gran impacto en el manejo efectivo de las consultas MySQL pesadas.Tan buena es que los administradores de sistemas, al ver cómo se cargaba el servidor después del lanzamiento de la nueva configuración de MySQL, todavía no lo creían: ¡vieron una caída en las consultas lentas entre 10 y 20 veces!

Todas nuestras últimas mejoras de servicio, como PHP ultrarrápido y ahora la configuración de MySQL, son posibles gracias a dos cosas: la plataforma Google Cloud y el cambio de cPanel a Site Tools. Desde que nos mudamos a Google Cloud, actualizamos nuestras configuraciones de servidor con más RAM. El precio unitario de la RAM no es más económico, pero trabajar en la nube ofrece posibilidades para una mejor distribución de ese recurso entre diferentes máquinas. Y el hecho de que no cumplamos con los requisitos de recursos de software de terceros, como cPanel, nos da más libertad para innovar. ¡Nuestros DevOps se sienten capacitados para crear y seguir desarrollando tecnologías inteligentes que beneficien a la gran mayoría de los sitios que alojamos!

¿Quién se beneficia de ello?

¡Todos los alojados en nuestros servidores compartidos de Site Tools ya tienen la nueva configuración de MySQL! Si has observado una mejora en el rendimiento durante la última semana, se debe a la nueva configuración.

Esto significa que es menos probable que te pidamos corregir una consulta lenta y “distanciar socialmente” tu sitio web debido a ello. ¡Menos consultas lentas, servidores más rápidos, menos molestias para ti!

Las cuentas Cloud también están programadas para recibir la nueva configuración de MySQL a finales de febrero de 2021.

¿Todavía estás en cPanel? Esperamos terminar con todas las migraciones a Site Tools a finales de marzo, por lo que todo lo que tienes que hacer es esperar tan solo un poco más.

Posted on

Consigue más velocidad web con el algoritmo de compresión Brotli

compresion_brotli

Estamos entusiasmados de anunciar que hemos implementado y habilitado de forma predeterminada el algoritmo de compresión Brotli en todos nuestros servidores con Site Tools, por lo que los sitios web alojados en ellos podrán obtener un aumento de velocidad de hasta un 15-20% al usarlo.

¿Qué es Brotli?

Brotli es un algoritmo de compresión de última generación desarrollado por Google como sucesor del popular método gzip, que hemos estado ejecutando en nuestros servidores durante años. La idea es simple: una vez que su aplicación produce la salida HTML de tu sitio web y se comprime junto con todos los recursos que carga, los datos se transmiten a través de Internet y luego el navegador descomprime el contenido antes de procesarlo. Este proceso reduce significativamente el tamaño de los datos que se han movido del servidor al visitante, lo que resulta en un aumento de velocidad (mucho) mayor que los milisegundos perdidos por/en la compresión y descompresión.

¿Cuánto más rápido es Brotli en comparación con gzip?

El nuevo algoritmo proporcionado por Brotli comprime el sitio web en un tamaño de datos más pequeño, lo que agiliza la transferencia. Los archivos JavaScript comprimidos con Brotli son aproximadamente un 15% más pequeños que los comprimidos con gzip. Los archivos HTML son alrededor de un 20% más pequeños y los archivos CSS tienen una reducción de tamaño de alrededor del 16%. Por supuesto, estos números diferirán dependiendo de tus archivos en particular.

A continuación puedes ver una prueba con uno de los temas predeterminados de WordPress: TwentyTwenty muestra que produce 19584 bytes de datos sin comprimir, 6003 bytes comprimidos con gzip y solo 4863 bytes cuando se comprime con Brotli. Esto significa que consigues más del 75% de reducción de tamaño del contenido sin comprimir y un 19,5% respecto a gzip.

¿Cómo usar Brotli?

Hemos habilitado Brotli en todos nuestros servidores con Site Tools y, si tu cuenta está alojada en uno de ellos, tu sitio web lo aprovechará automáticamente. ¡No tienes que hacer nada para conseguirlo! 🙂  Los navegadores que admiten la compresión Brotli, que son la mayoría de los navegadores ahora, pasan el encabezado “accept-encoding: br” apropiado al realizar la solicitud y obtienen el contenido Brotli comprimido. Los navegadores más antiguos que no lo admitan recibirán datos comprimidos con gzip. Si todavía estás alojado en un servidor cPanel, no te preocupes: esperamos que las migraciones a Site Tools se completen a finales de marzo, por lo que no tendrás que esperar mucho para disfrutar de Brotli también.

Posted on

¿Qué es CRON y para qué puedes usarlo?

“¿Qué es cron?” Respondo a esta pregunta al menos una vez al mes por parte de personas que no son desarrolladores. Es una gran pregunta. Sin embargo, voy a dividirlo en dos preguntas.

“¿Qué es CRON?”
“¿Qué es WP-CRON?”

¿Qué es CRON?

En esencia, un cron es un “programador basado en el tiempo”. Gestiona tareas que deben realizarse de forma regular y en un momento específico.

Por ejemplo, si quieres que tu blog en WordPress muestre el pronóstico del tiempo en el encabezado, entonces cada mañana debes obtener el pronóstico del tiempo. Sí, puedes contratar a alguien para que inicie sesión cada mañana, obtenga el pronóstico y lo pegue en un widget. Pero un plan mejor es tener un programa que se ejecute todas las mañanas y que conecte con una API para obtener el pronóstico del día y actualizar tu base de datos por ti. El programa que ejecuta tu programa de búsqueda del pronóstico del tiempo se llama CRON. El nombre se deriva de “cronológico”, que se traduce aproximadamente como “en orden de tiempo”.

La mayoría de los sistemas hoy en día tienen algún concepto de cron. Los sistemas basados ​​en Unix (Unix, Linux, macOS, etc.) en realidad tienen una versión de un cron tradicional. Si bien algunos pueden ponerles una interfaz gráfica más amigable, todos se reducen a un programa llamado cron y un archivo llamado crontab.

El programa cron siempre se está ejecutando en segundo plano y cada minuto mira el crontab y averigua si es necesario hacer algo. Si no, vuelve a dormir.

El archivo crontab contiene cuándo se debe ejecutar un programa y qué programa se debe ejecutar. Cada línea representa una tarea diferente. Se ven parecido a esto:

1 0 * * * ~/fetchForcast.sh

Si bien esto puede parecer críptico, todo lo que le dice a cron es que a las 12:01 AM todos los días, ejecute un programa llamado fetchForcast.sh. Aquí te dejo una guía fácil para leer un crontab:

# ┌───────────── minutos (0 – 59)

# │ ┌───────────── horas (0 – 23)

# │ │ ┌───────────── día del mes (1 – 31)

# │ │ │ ┌───────────── mes (1 – 12)

# │ │ │ │ ┌───────────── día de la semana (0 – 6) (Sábado a Domingo;

# │ │ │ │ │                                   7 también es Domingo en algunos sistemas)

# │ │ │ │ │

# │ │ │ │ │

# * * * * * <comando para ejecutar>

  1 0 * * * ~/fetchForcast.sh

Ahora que tienes la clave, es bastante fácil, ¿eh?

Esto es realmente todo lo que hay en un cron tradicional. La mayoría de los hosting como SiteGround te permiten acceder al cron de tu sistema. A veces, tienes que editar el crontab manualmente, pero muchos hosting tienen una interfaz mucho mejor para facilitar su uso. De cualquier manera, tienes la capacidad de ejecutar programas en un momento específico y de forma regular.

¿Qué es WP-CRON?

WordPress hace las cosas de manera un poco diferente. Debido a que muchos autores de plugins necesitaban poder programar las cosas para que sucedan regularmente, y debido a que muchos propietarios de sitios WordPress no saben dónde está su crontab, y mucho menos cómo editarlo, WordPress reinventó el cron.

En esencia, WP-CRON actúa como un cron tradicional en el sentido de que un desarrollador puede “programar” una tarea para que se realice de forma regular. Sin embargo, a diferencia de un cron tradicional, WordPress no tiene un programa que siempre se ejecute en segundo plano en tu servidor. Entonces, para hacerlo, WP-CRON es un proceso que se llama cada vez que se ve una página. En sitios web concurridos, esto funciona bien. Sin embargo, si tu web no es muy visitado, una tarea programada para las 2:00 a.m. podría ejecutarse a las 5:24 a.m. si nadie visita tu web hasta entonces. A veces esto está bien, otras veces es un problema.

Si las tareas que necesitas ejecutar son urgentes y deben ejecutarse a la hora programada, WP-CRON no es el programador que debes utilizar. Si, por otro lado, las tareas que debe realizar pueden ejecutarse “aproximadamente” en el momento en que las programas, entonces WP-CRON está bien. Nuevamente, depende mucho de lo visitado que sea tu sitio web.

¿Cuáles son las alternativas?

Si tienes tareas que son urgentes y tu proveedor de hosting no te permite acceder al cron del sistema, tienes 2 alternativas.

Primero, puedes cambiar a un proveedor como SiteGround que te brinde este acceso. Si esto no te es posible, hay varios servicios gratuitos o de pago que no son más que servicios cron. Ejecutan cron y puedes configurar un trabajo para que se ejecute a través de una interfaz web amigable. El trabajo usaría un programa como curl o wget que conectan a las URL de tu sitio web para activar una tarea específica.

La mayoría de los plugins que requieren un cron te darán la URL a la que conectar si deseas usar un cron externo. Todo lo que tienes que hacer es pegar esa URL, configurar el tiempo para que se ejecute y listo.

CRON es una herramienta de mucho valor y una vez que comprendas cómo trabajar con ella, encontrarás cómo darle más usos. Si tienes plugins, casi te puedo garantizar que tu sitio web tiene trabajos wp-cron en ejecución. Si tienes curiosidad, ve al repositorio de plugins de WordPress y busca cron. Hay plugins que puedes instalar que te mostrarán toda la actividad de WP-CRON en tu sitio web. Pero ten mucho cuidado. Los plugins los establecen por una razón. Si decides que no te gusta uno y lo eliminas, el plugin que depende del trabajo del WP-CRON dejará de funcionar.

Posted on

PHP8 disponible en nuestros servidores

Estamos muy contentos de anunciar que hemos implementado la última versión candidata a lanzarse de PHP 8 en todos nuestros servidores. Como siempre, estamos entre las primeras empresas en proporcionar el nuevo PHP en nuestra plataforma de hosting. Se espera que PHP 8 facilite a los desarrolladores escribir código más limpio, con mejor calidad y que se ejecute más rápido. Dado que las versiones beta no son adecuadas para sitios web activos, te invitamos a probarlo en una copia staging de tu sitio web o en proyectos que aún no hayas lanzado. Regalaremos unos fabulosos elefantes PHP de peluche a 5 de los primeros usuarios que lo probéis y compartáis vuestra opinión sobre PHP 8 con nosotros.

¿De qué se trata el nuevo PHP8?

Ejecución de código más rápida

La última versión de PHP trae muchas cosas nuevas, pero con la que estamos especialmente obsesionados es JIT (just in time compiler, o compilador justo a tiempo). Es la primera vez que la versión de PHP tiene un compilador JIT, que almacena en caché una versión de su código ya interpretado y genera un código máquina como salida (el código máquina utiliza solo 0’s y 1’s). El compilador JIT promete mejoras de velocidad para tareas y algoritmos complejos y abre nuevas oportunidades para que el lenguaje PHP amplíe su alcance y aplicación.

Algunos de vosotros os preguntaréis cómo se relaciona JIT con Opcache, que trajo mejoras de rendimiento significativas a muchos sitios web. El trabajo principal de Opcache es cortar los procesos de tokenización, análisis y compilación de Opcodes, que luego son procesados ​​por el motor Zend. El papel de JIT es ahorrar en la ejecución de los Opcodes por parte del motor Zend, por lo que une fuerzas e interviene para ahorrar recursos donde Opcache no puede ayudar.

Vale la pena mencionar también algunas desventajas que hemos notado hasta ahora:

  • La ejecución de PHP8 con JIT puede dificultarte la resolución de errores de código porque puede ser más difícil localizar qué parte de tu código en esta versión interpretada es realmente la culpable.
  • Si estás ejecutando un sitio web WordPress, es posible que no notes mejoras significativas en el rendimiento gracias a JIT. Los desarrolladores de WordPress todavía están trabajando para hacer que WordPress sea compatible con PHP 8 y ​​ahora están en busca de personas que lo prueben, lo que significa que no podrás probar PHP8 en tu sitio web WordPress de inmediato. Además, debido a la forma en que WordPress interactúa con MySQL, gran parte del tiempo de espera no proviene de la compilación de PHP, sino del tiempo de respuesta de MySQL, que no se puede resolver con la ayuda del compilador JIT.

Código con mayor calidad

Una de las principales diferencias que notarás es que muchas de las advertencias y avisos que no se podían detectar ahora son excepciones o errores que se pueden detectar y registrar. Es posible que, debido a este cambio, ahora surjan muchos problemas que permanecían ocultos con las versiones anteriores de PHP. Esta es una gran mejora, ya que permitirá a los desarrolladores detectar problemas potenciales más fácilmente. Sin embargo, ten en cuenta que puede ser una buena idea configurar display_errors = Off si decides usar PHP 8 en un sitio en producción para no mostrar tales errores a los visitantes de tu web.

Código más limpio y más corto

Algunos de los elementos nuevos, como el operador nullsafe, mejoran enormemente la legibilidad del código haciéndolo más corto y ordenado. En lugar de anidar varios “if’s”, puede usar el operador “null” para escribirlos todos en solo una línea de código.

La tendencia “Type”

Desde varias versiones en adelante, PHP ha estado tratando de definir los argumentos que cada método podría adoptar y convertirse en un lenguaje escrito. En esta última versión, hay una función llamada “union types” que te permite definir 2 tipos de valor para cada función, lo cual es una continuación natural de esa tendencia. Como muestra el siguiente ejemplo, la función puede devolver un número entero o uno flotante:

public function getNumber(): int|float {
return $this->number;
}

La lista de nuevas características continúa y creemos que este artículo puede ser un buen punto de referencia para los desarrolladores de PHP:

https://stitcher.io/blog/new-in-php-8
https://stitcher.io/blog/php-jit
https://wiki.php.net/rfc/nullsafe_operator

¿Cómo aprovechar PHP 8 en nuestra plataforma?

Todos nuestros clientes pueden cambiar la versión PHP de sus sitios web desde su panel de control – Site Tools > sección Desarrolladores, o cPanel > Versiones PHP -. Dado que PHP8 sigue siendo una versión de prueba, te recomendamos encarecidamente que no lo habilites para tus sitios web activos, sino que ejecutes pruebas con él en nuestro entorno de pruebas (disponible para los planes GoGeek y Cloud), o crees copias de tus sitios web si no tienes la función de staging.

Por el momento, hemos implementado PHP 8 sin los siguientes módulos: mcrypt, geoip, ioncube.

Danos tu opinión y gana un elefante PHP

Hemos intentado darte una idea general de lo que es el nuevo PHP8. Ahora nos gustaría saber lo que realmente piensas al respecto, una vez tengas la oportunidad de probarlo. ¿Qué te gusta y qué no te gusta? ¿Cómo funciona en tu sitio web? ¿Ves alguna mejora en el rendimiento? Buscamos explorar cómo nuestros usuarios más experimentados aprovechan esta versión de prueba de forma anticipada antes de que se lance como versión oficial.

Para animarte compartir con nosotros los resultados de tus pruebas y tu opinión, ¡hemos creado peluches con el diseño de los elefantes PHP originales para celebrar este nuevo lanzamiento! Regalaremos 5 elefantes de forma aleatoria a 5 de los usuarios que compartáis vuestra opinión sobre PHP8 antes del 26 de noviembre de 2020 en un comentario debajo de este artículo, o haciendo una publicación en Facebook o Twitter, etiquetando a @SiteGround_ES para twitter o a @siteground.esp para Facebook, y usando el hashtag #PHP8 en vuestra publicación.

¡Déjanos tu comentario y mucha suerte!

Posted on

Informe de progreso del cambio de cPanel a Site Tools

Progreso del cambio de cPanel a Site Tools

Ha pasado poco más de un año desde que lanzamos nuestras nuevas interfaces de cliente: el nuevo Área de Cliente y Site Tools, que desarrollamos internamente y con el que reemplazamos cPanel. En agosto de 2019 comenzamos a incorporar a todos los nuevos clientes a las nuevas interfaces y poco después comenzamos a trabajar en la migración de nuestros clientes existentes. Actualmente, todos nuestros clientes ya están utilizando el nuevo Área de Cliente y también hemos migrado con éxito más de 9000 servidores de cPanel a Site Tools.

Mirando hacia atrás en los últimos 12 meses, evaluando la complejidad del proceso de migración y los desafíos no relacionados con ella que 2020 ha puesto frente a nosotros, creo que hemos logrado mantener un buen ritmo de migración. Esto se ha logrado gracias a la enorme cantidad de trabajo que han hecho todos los equipos involucrados en la migración, a pesar de los retrasos ocasionales que se dieron por diversas circunstancias. Aún así, nos quedan todavía muchas más cuentas y servidores por migrar y muchos de vosotros os estaréis preguntando por qué nos está llevando tanto tiempo y cuándo llegará el turno de tu sitio web. Es por eso que hemos decidido hacer un seguimiento y contarte la historia de lo que hemos hecho entre bastidores durante el año pasado y cuál es el pronóstico para los próximos meses.

La complejidad innata de la migración

No es sorprendente que la migración de más de un millón de sitios activos de cPanel a Site Tools sea un proceso tremendamente complejo. Podría decir que es comparable en términos de esfuerzos y recursos necesarios a la creación de las nuevas interfaces y sistemas en sí. Es todo un desafío mover los sitios operativos de una plataforma con una determinada estructura a una nueva plataforma con una completamente diferente, sin afectar la disponibilidad y el funcionamiento de estos sitios web.

En la superficie, parece que solo hay una diferencia simple entre los dos marcos: no hay sitios adicionales bajo un mismo capó. Lo que esto realmente significa es que tenemos que poder “desenredar” los sitios web secundarios de la cuenta principal de cPanel y volver a crearlos como cuentas independientes en nuestra nueva plataforma. Y para ilustrar cuán complejo puede ser este proceso para diferentes configuraciones de sitios web, enumeraré algunos ejemplos a continuación:

Múltiples dominios adicionales usando una misma base de datos

Normalmente, esto no es algo razonable, ya que cada sitio web, incluso los dominios adicionales, deberían utilizar su propia base de datos. Sin embargo, esto era técnicamente posible con cPanel y hay sitios web reales configurados de esta manera por nuestros clientes. Cuando un sitio web de este tipo necesita ser migrado, nuestro script de migración tiene que detectar el caso y crear una base de datos separada para cada sitio y copiar los datos. Después de eso, el script re-configura automáticamente cada sitio web para usar la respectiva base de datos.

Aplicaciones con rutas absolutas en su configuración

Otra cosa que el script de migración debería corregir es que múltiples aplicaciones estén configuradas para usar rutas absolutas en su configuración. El sistema tiene que detectarlos y, una vez que se conviertan en sitios independientes con diferentes usuarios del sistema, re-configurarlos automáticamente para usar las nuevas rutas del sistema.

Opciones de configuración infinitas para dominios adicionales, aparcados y subdominios

El número infinito de formas en que los usuarios pueden configurar y, a veces, estropear sus rutas al directorio raíz para las diferentes aplicaciones cuando usan la función de dominios adicionales, aparcados y subdominios en cPanel es el mayor desafío para nuestro proceso de migración. Hemos logrado identificar más de 30 formas diferentes de casos de rutas al directorio raíz poco ortodoxos. Uno de los ejemplos más comunes es cuando más de un dominio adicional está configurado para usar la misma carpeta. Este es un “truco” común del sistema cPanel que la gente usa para aparcar un segundo dominio en un sitio adicional, una opción que oficialmente no está permitida en cPanel. Entonces, en tales configuraciones, el sistema tiene que decidir automáticamente a qué sitio se dirige cada dominio y en qué rol (principal o aparcado). En algunos casos, la configuración es tan compleja que los dominios no se pueden configurar automáticamente y la migración debe realizarse manualmente.

Una compleja tarea de desarrollo 

Automatizar todos los procesos posibles

Comenzamos nuestras primeras migraciones en septiembre del año pasado con mucha cautela. Los sitios migrados se revisaron manualmente y cada uno de los problemas descritos anteriormente, además de muchos más que aparecieron, se han abordado con nuevas iteraciones del script de migración. No hace falta decir que las comprobaciones manuales de las primeras migraciones llevaron mucho tiempo y no era algo que pudiera ser sostenible a largo plazo, por lo que hemos añadido varias automatizaciones adicionales al script de migración.

Ahora realizamos comprobaciones previas automatizadas de todas las cuentas que se van a migrar. Si hay indicios de un posible problema, lo solucionamos antes de que comience la migración. Después, la cuenta se migra de cPanel a Site Tools. Una vez que finaliza la migración, realizamos otra verificación automática para detectar problemas posteriores a la migración. Si se detecta algún problema, la cuenta se marca para revisión manual. Además, hemos desarrollado un sistema automatizado para comunicar el progreso de este proceso al el cliente cuyas cuentas se están migrando. Con todos estos sistemas en uso, podemos migrar alrededor de 900 cuentas de cPanel por día con una tasa de fallos muy baja.

Cambiar primero al nuevo área de cliente

Al principio planificamos migrar a cada cliente simultáneamente al nuevo Área de Cliente y el nuevo Site Tools. Sin embargo, pronto nos dimos cuenta de que sería mucho mejor desligarlos y pasar a todos los clientes primero al Área de Cliente. Hubo varias razones para esta decisión:

  • En primer lugar, la migración del área del cliente tenía por sí misma menor riesgo, ya que no afectaba directamente la funcionalidad de los sitios web alojados.
  • En segundo lugar, nos dimos cuenta de que proporcionar primero el Área de cliente les daría a todos nuestros clientes algo de tiempo para acostumbrarse a las nuevas interfaces. Apreciamos el esfuerzo necesario para aprender una nueva interfaz, por lo que dando la oportunidad de acostumbrarse primero a nuestra nueva lógica de UX con el nuevo Área de cliente, pretendíamos hacer que la transición a Site Tools, con mayor cantidad de funcionalidades, fuera más fluida para nuestros usuarios.
  • Y tercero, el mantenimiento diario de dos interfaces distintas de Área de Cliente (la antigua y la nueva) le quitaba un tiempo muy valioso a nuestro equipo técnico. Tiempo que se podía invertir en perfeccionar los scripts de migración.

La decisión de desligar la migración de ambas interfaces requirió un cambio temporal de enfoque, ya que supuso invertir algo de tiempo de desarrollo para acomodar las cuentas de cPanel en la nueva interfaz del Área de Cliente, algo que no estaba planeado inicialmente. Sin embargo, a largo plazo creemos que esta decisión agilizó la fecha de finalización de toda la migración. Estamos muy orgullosos de que todos nuestros clientes estén utilizando con éxito el nuevo Área de Cliente desde mayo de 2020.

Los desafíos de 2020

Como todos sabemos, este año ha sido extremadamente impredecible y para perfeccionistas como nuestro equipo directivo, la planificación se ha convertido en un quebradero de cabeza con demasiadas variables y factores dinámicos que inevitablemente ralentizaron las migraciones durante el año.

Migración a la plataforma de Google Cloud

Una de las cosas que nos hizo reorganizar nuestros planes iniciales fue realmente positiva: la finalización de nuestro contrato con Google Cloud. Mover nuestro servicio a una plataforma basada en la nube fue el otro gran proyecto en el que hemos estado trabajando en los últimos años. Sabíamos que pasar a Google Cloud proporcionaría muchos beneficios inmediatos a todos nuestros clientes y completar primero esta migración nos permitiría dedicar todos los recursos al cambio, mucho más complejo, a Site Tools. Por lo tanto, una vez finalizado el contrato con Google, se priorizó la migración a Google Cloud en la cola de nuestros equipos DevOps y SysAdmin. Trabajaron rápido e hicieron un gran trabajo: logramos migrar toda nuestra plataforma a Google Cloud en menos de 4 meses. ¡Y estamos hablando de más de 4 PB de datos! Aunque una gran parte de nuestros recursos se invirtió en la migración de Google durante varios meses, mientras tanto logramos hacer un trabajo considerable para pulir los scripts de migración de Site Tools.

El efecto COVID-19

Por supuesto, no podemos olvidar el efecto COVID-19. Durante abril y mayo, con las cuarentenas que afectaron a muchos de nuestros mercados geográficos, hemos visto un aumento sin precedentes en las consultas de soporte. Era natural, ya que la presencia online de repente se volvió mucho más importante para una gran cantidad de personas y empresas, lo que ha llevado a un mayor nivel de actividad por parte de todos los propietarios de sitios web. Estábamos realmente abrumados y, por primera vez desde que comenzamos nuestra actividad, tuvimos que dedicar literalmente todos nuestros recursos a la atención al cliente. A pesar de contratar a nuevo personal, el volumen de trabajo era tan grande que cada departamento tenía que enfocarse y contribuir de alguna manera a la prestación del servicio y la optimización de cómo se entregaba ese servicio. Una vez más, eso nos estaba alejando el enfoque en las migraciones y, aunque mantuvimos un equipo central trabajando en ellas, la atención directiva y operativa estaba en otra parte y las migraciones fueron más lentas durante este período.

Dicho esto, sigo creyendo que logramos abordar los dos grandes eventos de 2020 bastante bien y logramos mantenernos razonablemente encaminados con nuestro tercer esfuerzo principal: la migración a las nuevas interfaces.

Estado actual de la migración

Por el momento, las cuentas Cloud se están migrando con la máxima prioridad. Nuestro objetivo es completar la migración de la mayoría de las cuentas Cloud a mediados de diciembre. Hay un pequeño porcentaje de cuentas Cloud que no están incluidas en este plan. Estas son cuentas en las que se utilizó la funcionalidad WHM existente para crear planes de cPanel personalizados. Esto significa que el propietario del Cloud estableció límites de recursos personalizados para las cuentas de cPanel separadas en la nube. Como preservar esta configuración es una seria complejidad adicional que debe abordar la secuencia de comandos de migración, tendremos que posponer la migración de dichas cuentas. (En caso de que tengas una cuenta Cloud de este tipo y creas que no necesitas mantener la configuración personalizada de tu cuenta de cPanel, puedes comunicarte con nosotros a través de la categoría “Otros problemas técnicos” que encontrarás en tu Centro de Ayuda y solicitar su inclusión en el programa de migración Cloud actual. )

Mientras tanto, también estamos trabajando duro en las migraciones de servidores compartidos. Debido al mayor volumen de datos en ellos y a las diferentes especificaciones de configuración, su tasa de migración es mucho menor en este momento. Sin embargo, ahora que estamos cerca de finalizar la migración de las cuentas Cloud, hemos concentrado más recursos en optimizar el proceso de migración de servidores compartidos y esperamos ver una mayor cantidad de cuentas compartidas migradas en las próximas semanas.

En nombre de todo el equipo de SiteGround, me gustaría daros las gracias a todos por la paciencia de este año. Somos plenamente conscientes de que hemos creado expectativas de un cambio y que puede llevar más tiempo de lo previsto, pero realmente hacemos todo lo posible para que este cambio tan complejo ocurra lo antes posible y, al mismo tiempo, para que sea  una experiencia segura y fácil para todos nuestros clientes.

Posted on

PHP ultrarrápido para webs hasta un 30% más rápidas

PHP ultrarrápido

La velocidad es uno de los pilares de nuestros servicios de alojamiento y trabajamos constantemente para hacer que nuestra infraestructura sea más rápida y estable. Uno de los elementos esenciales para una velocidad de carga rápida es la configuración del servidor PHP y ahora, con nuestra nueva plataforma Site Tools y sin las limitaciones del sistema anterior, nuestro equipo de DevOps ha tenido la oportunidad de desarrollar un PHP nuevo y mejor: la configuración de PHP ultrarrápido, que es hasta un 30% más rápido y tan seguro como todo lo que hacemos.

Configuración PHP ultrarrápido y súper seguro

Por sí solo, ejecutar un PHP rápido no es una tarea difícil. Sin embargo, si deseas un PHP rápido, estable y seguro, a la vez que sea compatible con Apache y la variedad de reglas .htaccess definidas por los usuarios y las aplicaciones, las cosas se complican. Queríamos resolver estos problemas y, al mismo tiempo, aumentar la velocidad de carga de la página y mejorar la estabilidad del servidor durante los picos de tráfico. Entonces, una vez que lanzamos el nuevo área de cliente y Site Tools y nos deshicimos de las principales limitaciones que nuestra antigua plataforma nos imponía, modificar nuestra configuración de PHP se convirtió en una de las prioridades de nuestro equipo de DevOps.

Después de varios intentos, logramos superar el mayor desafío de “velocidad sobre seguridad” y conseguimos ofrecer un PHP rápido con nuestro WAF y aislamiento de cuenta integrados, obteniendo así mejores resultados de rendimiento sin comprometer la seguridad. La nueva implementación es súper rápida, segura y eficiente.

[subscribe_cta]

PHP ultrarrápido vs PHP estándar

Si bien la configuración de PHP ultrarrápido es más rápida y se recomienda para sitios web con mucho tráfico, la configuración de PHP estándar proporciona cierta flexibilidad adicional para las versiones de PHP y la gestión de variables.

PHP ultrarrápido: recomendado para sitios web con muchas visitas

Los sitios web que se beneficiarán más de PHP ultrarrápido son los que tiene un tráfico sólido y pueden estar experimentando un déficit de recursos en el plan actual que utilizan. Según las estadísticas preliminares que hemos realizado, vemos los siguientes datos:

  • Respuesta de página más rápida: hasta un 50% de reducción en el TTFB (tiempo hasta el primer byte), lo que hará que tus páginas se carguen más rápido que antes;
  • Mayor capacidad del servidor: el nodo host podrá procesar entre un 20 y un 30% más de solicitudes, lo que significa que podrá manejar aún mejor los picos de tráfico;
  • Menor uso de la memoria del servidor: hasta un 15% menos de uso de la memoria, lo que nuevamente deja libres los recursos del servidor para manejar más tráfico y más rápido.
  • Se espera una mejora general de rendimiento: actualmente, el promedio de PHP ultrarrápido es un 30% más rápido que la configuración anterior.

Nota: los números anteriores son promedios basados en nuestras pruebas y los resultados particulares pueden variar según el sitio.

La configuración de PHP ultrarrápido está disponible para sitios web alojados en planes GoGeek y Cloud, ya que estos planes suelen alojar el tipo de sitios con mayor probabilidad de beneficiarse de las mejoras de rendimiento que aporta. También es importante señalar que funciona para sitios que se ejecutan en PHP 7.3 o superior y no es compatible con versiones anteriores. Además, en el momento en que utilices PHP ultrarrápido, todos los subdominios de tu sitio web heredarán la versión de PHP y la configuración de variables del dominio principal.

PHP estándar: permite diferentes configuraciones de PHP para cada subdominio

La configuración estándar de PHP es la que utilizan todas las cuentas basadas en StartUp, GrowBig y cPanel. También está disponible como una alternativa a la configuración de PHP ultrarrápido en cuentas GoGeek y Cloud con Site Tools. Su rendimiento sigue siendo bastante bueno para sitios web pequeños y estándar. Su mayor ventaja es que te permite administrar las versiones y variables de PHP por separado para cada subdominio de tu sitio web.

Como PHP estándar brinda más flexibilidad para experimentar, todos los sitios web de prueba también están configurados con él. Por lo tanto, si necesitas usar una versión de PHP anterior a 7.3 o necesitas una configuración con diferentes versiones de PHP y variables por subdominio, la configuración de PHP estándar es la adecuada para ti.

¿Cómo cambiar a PHP ultrarrápido?

  • Todos los sitios nuevos creados en el plan GoGeek o Cloud con Site Tools vienen con PHP Ultrarrápido activado de forma predeterminada.
  • Para los sitios existentes alojados en planes GoGeek y planes Cloud con Site Tools, PHP ultrarrápido ahora está disponible en Site Tools > Gestionar PHP y los clientes pueden habilitarlo instantáneamente desde allí.
  • Si tienes un plan StartUp y GrowBig con Site Tools, puedes actualizarlo a un plan superior para obtener acceso a la configuración de PHP ultrarrápido.
  • Si tienes una cuenta con cPanel, la opción PHP ultrarrápido estará disponible una vez que la cuenta se haya migrado a Site Tools.