¿Que es un Hosting WordPress?

En mi caso personal recuerdo aquellos tiempos cuando inicie con el diseño web investigando me encontré con WordPress el cual puede ejecutar en un Hosting Apache con Php, Las cosas eran mucho menos complicadas en aquel entonces. ¡Ahora, todo tiene que cargar a la velocidad del rayo! Los visitantes no tienen las mismas expectativas sobre los tiempos de carga que solían tener. Un sitio web lento puede tener serias implicaciones para usted o su cliente. En consecuencia, los Hosting WordPress ha tenido que evolucionar a lo largo de los años para mantenerse al día con esta necesidad de velocidad. Como parte de esta evolución, se han tenido que agregar algunos engranajes a su motor. Algunos de los engranajes más antiguos también han tenido que cambiar.

Para entenderlo mejor, vamos a explorar esta nueva pila en detalle. Verás cómo las diferentes piezas se unen para hacer que un sitio web de WordPress sea rápido.

Visión De Conjunto

Antes de sumergirse, alejémonos y veamos el panorama general. ¿Cómo se ve esta nueva pila de servidores de WordPress? Bueno, aquí está la respuesta:

¿Que es un Hosting WordPress?

El diagrama anterior ofrece una buena visión general de cómo se ve ahora los modernos servidores de WordPress. A un alto nivel, podemos dividir lo que está sucediendo en tres áreas:

  • el ciclo de solicitud-respuesta entre el navegador y WordPress;
  • WordPress (que es un script que ejecuta el tiempo de ejecución de PHP);
  • El ciclo de consulta-resultado entre WordPress y la base de datos MySQL.

El papel de los servidores de WordPress es optimizar estas tres áreas. Estas optimizaciones son las que hacen que todo se cargue más rápido. Y la mejor parte es que hay varias formas de hacerlo. (¡Hurra!)

En la mayoría de los casos, estas optimizaciones implican la instalación de nuevos servicios en su servidor. A veces, estos servicios necesitarán la ayuda de un complemento para interactuar con WordPress. También habrá momentos en los que podrá salirse con la simple instalación de un plugin. Verá muchas opciones diferentes a lo largo de este artículo.

El Ciclo De Solicitud-Respuesta

Todo comienza con el navegador. Digamos que desea ver la página de inicio de modern.wordpress-stack.org. Su navegador comenzará enviando una solicitud HTTP al servidor web que lo aloja. En el otro extremo, el servidor web tomará su solicitud y la convertirá en una respuesta HTTP .

Esta primera respuesta siempre debe ser el contenido HTML de la página de inicio de modern.wordpress-stack.org(a menos que haya un error). Sin embargo, el trabajo de su navegador no está terminado. No, esa página de inicio todavía necesita más archivos, los más comunes son CSS, JavaScript y archivos de imágenes.

Entonces, el navegador enviará solicitudes para esos archivos. El servidor web responderá con los archivos solicitados (nuevamente, siempre que no haya errores). Este ciclo continuará hasta que el navegador tenga suficiente información para representar la página de inicio. Cuanto más rápido ocurra este ciclo, más rápido parecerá que se carga el sitio web.

Ahora, esta es una simplificación obvia, pero es cómo funcionan las cosas para la mayoría de los sitios web de WordPress.

Optimizar El Ciclo De Solicitud-Respuesta

Muy bien, esto nos lleva a la pregunta obvia: ¿Cómo hacemos que un servidor web realice este ciclo más rápido? Esta es una gran pregunta y es parte de la razón por la cual existen los servidores de WordPress.

Estos existen porque no puedes simplemente hacer que un servidor web sea más rápido. Un servidor web también es un despachador. Puede recibir una solicitud y simplemente reenviarla a otros servicios.

Estos otros servicios son a menudo el cuello de botella de este ciclo de solicitud-respuesta. Con WordPress, este cuello de botella es PHP, por lo que la optimización del ciclo de solicitud-respuesta se reduce a dos cosas. Queremos que el servidor web:

  • recibir el menor número de solicitudes posible
  • reenviar la menor cantidad posible de solicitudes a PHP.

Los servidores de WordPress se centran en este último. Quieres reenviar la menor cantidad posible de solicitudes a PHP. Ese será el objetivo principal para optimizar.

Nos centramos en el segundo objetivo porque no puede hacer mucho sobre el primero; No tiene un impacto directo sobre él. El segundo se aborda mediante la configuración del servidor web o mediante técnicas de desarrollo modernas.

Entonces, ¿cuáles son los elementos que nos ayudarán a reducir las solicitudes enviadas a PHP? Bueno, dos elementos en particular nos ayudarán a lograr ese objetivo: el servidor web y el caché HTTP.

SERVIDOR WEB

Ya hemos estado hablando bastante sobre servidores web. Hay tres grandes jugadores en el espacio del servidor web:

Juntos, representan más del 90% de la cuota de mercado de los servidores web en Internet. Nos enfocaremos en Apache y nginx. Si bien IIS se puede usar para ejecutar WordPress, no es común porque está disponible solo para Windows, y la mayoría de los servidores de WordPress usan Linux.

Esto nos deja con Apache y nginx. Durante toda la vida de WordPress, Apache ha sido el servidor web recomendado. Teníamos LAMP (Linux, Apache, MySQL y PHP), que ejecutaba WordPress tanto en la computadora como en el servidor.

Pero detrás de escena, las cosas estaban cambiando. Había un nuevo jugador en la ciudad, y su nombre era nginx. Automattic y WordPress.com lo han estado utilizando desde 2008. Es el servidor web que ejecuta el mayor porcentaje de sitios web de alto tráfico (muchos de los cuales ejecutan WordPress). Es por eso que muchas empresas de alojamiento de alta gama y las principales agencias de WordPress lo usan como su servidor web.

No es que Apache sea un mal servidor web. Hay expertos de Apache que pueden hacer que funcione de manera excelente con mucho tráfico. Simplemente no funciona tan bien fuera de la caja o con la configuración estándar de WordPress.

Mientras tanto, el único propósito de nginx es manejar mucho tráfico. Es por eso que Igor Sysoev comenzó el proyecto cuando trabajaba en Rambler .

Una de las razones por las que nginx maneja mejor más tráfico es que usa FastCGI para comunicarse con PHP. ¿Qué es FastCGI? Es un protocolo que permite que PHP se ejecute como un servicio separado del servidor web.

Apache no hace esto por defecto. Cada vez que el servidor web recibe una solicitud, debe iniciar un proceso de tiempo de ejecución de PHP, incluso para imágenes, JavaScript y CSS. Esto reduce la cantidad de solicitudes que el servidor puede manejar y qué tan rápido puede manejarlas.

Esto va en contra de uno de los objetivos para los servidores de WordPress, que vimos anteriormente. Necesita mantener el tiempo del ciclo de solicitud-respuesta lo más bajo posible. Cargar PHP para cada solicitud, incluso cuando no lo necesita, va en contra de este objetivo. Entonces, si usa Apache, busque FastCGI.

HTTP / 2 es otra característica importante del servidor web que debe conocer. Es la próxima versión de HTTP, el protocolo que impulsa todo nuestro ciclo de solicitud-respuesta.

Antes de la llegada de HTTP / 2, un navegador solo podía tener seis conexiones al servidor web. Y cada conexión podría manejar solo una solicitud a la vez. Entonces, en la práctica, un ciclo de solicitud-respuesta se limitó a seis solicitudes por ciclo.

Ese es un problema real. La mayoría de los sitios web tienen docenas de solicitudes en su ciclo. Los desarrolladores y administradores de sistemas encontraron formas inteligentes de sortear esta limitación.

Una de las soluciones más conocidas es la práctica de combinar archivos CSS y JavaScript. En un escenario ideal, esto reduciría el número total de solicitudes de archivos CSS y JavaScript a dos: uno para JavaScript y otro para CSS.

Esto no es necesario con HTTP / 2. HTTP / 2 permite un número ilimitado de solicitudes por conexión. Esto permite que todas las solicitudes adicionales después de la respuesta HTML inicial sucedan al mismo tiempo.

Esto tiene enormes implicaciones de rendimiento. Gran parte del trabajo de optimización de del servidor se centra en el ciclo de solicitud-respuesta. Al reducir el número de ciclos a solo unos pocos, HTTP / 2 ha hecho una gran cantidad de trabajo por nosotros.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *