He estado optimizando mi CSS durante mucho tiempo, eliminando plugins, redirecciones y todo lo posible para mejorar los tiempos de carga, pero al parecer los principales culpables son:
mobile_4-randomcharacters-.css, que contiene normalize.css y Pikaday y se carga en 1.5 segundos en móviles,
y /assets/ember_jquery-randomcharacter-.js, que se carga en 3.6 segundos en móviles.
No tengo idea de qué hacer con estos archivos, que tienen los tiempos de carga más altos.
La carga en escritorio es más rápida, pero no es buena.
El servidor tiene 1 CPU, 2 GB de RAM, 50 GB de SSD y 2 TB de ancho de banda en un servidor profesional basado en EE. UU.
Hay 2 workers de Unicorn; ni la CPU ni la RAM están bajo carga pesada, y no tengo muchos usuarios ni plugins.
¿Alguna idea? Gracias.
Gracias, https://developers.google.com/speed/pagespeed/insights/ indica que el tiempo de CPU (no el tiempo de entrega) específicamente para el segundo recurso fue de casi 4 segundos. ¿Un CDN como Fastly ayudaría con eso? Actualmente uso Cloudflare con almacenamiento en caché; ¿debería aplicar algún ajuste en Cloudflare o simplemente añadir algo como Fastly encima?
Esa es, en efecto, una gran ventaja que requerirá tiempo para analizar y evaluar. Dado que Discourse es una “aplicación de una sola página”, ese costo se paga por adelantado cuando el usuario llega por primera vez, y este es un compromiso de nuestro enfoque, que se centra en hacer que todas las interacciones posteriores, típicas del uso de foros, sean ligeras.
Hay planes para que EmberJS elimine la dependencia obligatoria de JQuery, lo que reducirá bastante esta carga, pero estamos a años de realizar esta transición en Discourse.
gracias por la respuesta. Creo que debe haber algo mal en mi configuración, ya que nunca he oído que otra persona haya reportado esos tiempos de carga.
Bueno, los valores predeterminados de PageSpeed fuerzan un Nexus 5X y una conexión 3G, lo cual, incluso para Brasil (un país en desarrollo), está en el extremo inferior según los estándares actuales, por lo que el rendimiento en el mundo real dependerá de eso.
En las estadísticas de rendimiento del servidor prácticamente no hay carga, pero la URL tarda una eternidad en cargar. Medí 1,2 minutos para un visitante no registrado en una ventana de incógnito, incluso cuando varios componentes ya estaban en caché. Los más lentos fueron los archivos de fuente OpenSans ttf, con más de un minuto; después, varios componentes .js tardaron entre 30 y 45 segundos.
Voy a investigar opciones de caché, pero viendo estos componentes, no creo que todos sean cacheables. En total, la transferencia de datos fue de solo 730 KB. Si los 3 vCPUs estuvieran funcionando a máxima capacidad, consideraría cambiar a un servidor más rápido, pero como incluso eso muestra poca o ninguna carga, simplemente no lo entiendo.
¿Hay algo que esté esperando a otra cosa antes de continuar? ¿Existe alguna forma de ejecutar pruebas en el servidor para verificar el estado de componentes como la base de datos?
¿Podría ser Docker lo que está ralentizando las cosas?
