• WordPress Lento 7 Problemas

    WordPress Lento 7 Problemas

    WordPress Lento 7 Problemas

    WordPress Lento 7 Problemas ,existe una muy buena posibilidad de que, sin una optimización adecuada, su sitio de WordPress se cargue más lento que el objetivo de 3 a 5 segundos. Para remediar esto, debe comprender los problemas más comunes que hacen que un sitio de WordPress se cargue lentamente.

    Hay siete problemas principales que ocurren; definamos rápidamente cada uno antes de pasar a cómo puede lidiar con ellos.

     

    Cuando un visitante lee la parte superior de un artículo, no es necesario cargar imágenes que no se verán hasta que lleguen al final del artículo.

    Cargue el mínimo número posible de archivos separados. Es mejor tener un solo archivo de 100 kb que 10 archivos de 10 kb cada uno.

    Es muy común en WordPress tener complementos (o incluso el núcleo de WordPress), que cargan archivos que no se usan, o solo se usan parcialmente. Cada bit de datos innecesarios aumenta el tiempo de carga.

    Cuando los archivos del sitio como CSS, JS e imágenes son demasiado grandes, puede aumentar drásticamente los tiempos de carga.

    Si un servicio de alojamiento tiene un hardware insuficiente, como CPU de baja potencia / RAM insuficiente, o no emplea procesos de optimización adecuados, puede hacer que su sitio de WordPress se retrase.

    Si WordPress tiene que procesar demasiado en el servidor, puede causar un retraso significativo antes de que el contenido esté listo para cargarse. El almacenamiento en caché puede aliviar este problema.

    Si su visitante y su sitio de WordPress se encuentran en lados opuestos del planeta, esto puede causar un retraso considerable en el tiempo de carga. Una red de entrega de contenido, o CDN, puede resolver este problema.

    Ahora ya sabe cuáles son los problemas que pueden causar un sitio de carga lenta, pero aún necesita saber específicamente cuáles de estos problemas está experimentando su propio sitio para poder aplicar las soluciones correctamente.

    Veremos cómo evaluar los problemas 1 a 4, como se describe en la sección anterior. Nos estamos enfocando en estos cuatro problemas primero porque pueden o no ser un problema en un sitio determinado.

    Los problemas 5 a 7 deben abordarse en cada sitio mediante un host rápido, almacenamiento en caché y CDN, que discutiremos más adelante.

    A medida que avancemos en estos pasos, pondré mi dinero donde está mi boca y le mostraré los resultados de las pruebas de mi propio sitio web personal. (No es un sitio de WordPress, pero los métodos de optimización son los mismos).

    En comparación, te mostraré los resultados de la página de demostración de un tema de WordPress muy popular. (El tema permanecerá sin nombre ya que el objetivo no es llamar a nadie, sino mostrar cómo la velocidad de carga fuera de control puede llegar a los sitios de WordPress sin una optimización adecuada).

    Hay varios sitios web que puede usar para probar la velocidad de sus sitios, pero en este punto ya no son realmente necesarios ya que las herramientas que vienen incorporadas en los navegadores son excelentes. Te llevaré a través del uso de algunas herramientas incluidas en los navegadores basados ​​en Chromium y Firefox.

    Nota : los navegadores basados ​​en cromo son prácticamente todos los navegadores, excepto Firefox, por ejemplo, cromo no controlado, Vivaldi, la última versión de Edge, Opera, etc. Como tal, debería usar el navegador de su elección para acceder a estas herramientas.

    Un punto rápido a tener en cuenta durante las pruebas:

    • Use una “Ventana privada” o “Modo de incógnito” para asegurarse de que las extensiones estén deshabilitadas, ya que pueden afectar la velocidad de carga.

    Vamos a hacer un par de pruebas de velocidad para ver qué tan cerca estamos de tener un sitio listo para la interacción en menos de 5 segundos con 3G lento.

    En un navegador basado en Chromium, abra la ventana “Modo incógnito”, vaya al menú que se ve en la imagen a continuación y luego cargue su sitio web.

    Modo incognito

    Ahora abra Herramientas para desarrolladores yendo a este menú en la parte superior derecha del navegador:

    Herramientas de desarrollo

    Una vez que las herramientas estén abiertas, vaya a la pestaña Red , marque la casilla Deshabilitar caché y cambie la lista desplegable en el extremo derecho de la barra de herramientas a 3G lento . Esto emula una visita por primera vez de alguien en una conexión móvil bastante pobre. La configuración debería verse así:

    Desactivar el caché

    Actualice la página y observe cómo el panel realiza un seguimiento de la carga de todos los recursos de su sitio.

    Estamos buscando, una vez que se completa la carga de la página, los números en la parte inferior del panel, en particular el número azul y el número rojo. Sin entrar en tecnicismos, el número azul es cuando se han cargado los recursos básicos como el texto, y el número rojo es cuando se han cargado los recursos más visuales como los estilos y las imágenes. El punto en el que se puede interactuar con un sitio generalmente estará en algún lugar entre el número azul y el número rojo.

    Estos son los números de mi sitio personal:

    Estos son los números de mi sitio personal.

    Como puede ver, acabo de ingresar menos de 5 segundos en el número rojo, aunque en realidad el punto en el que puede comenzar a interactuar con mi sitio estaría más cerca del número azul.

    Y estos son los números del popular sitio de demostración de temas de WordPress:

    números del popular tema de WordPress

    26 segundos en el número azul y más de un minuto en el número rojo. Ay. Ni siquiera cerca del tiempo de carga de 5 segundos que estamos buscando. De hecho, en algún lugar entre 5 y 14 veces más lento que el objetivo.

    Está bastante claro que este sitio está perdiendo la marca en la velocidad de carga, por lo que la siguiente pregunta es ¿por qué? Para responder a esa pregunta, comenzaremos a verificar cuáles de los problemas que describimos anteriormente podrían estar teniendo impacto.

    Abra su sitio web en una ventana privada en Firefox:

    ventana privada en Firefox

    Abra las “Herramientas de red” yendo al menú superior derecho de Firefox, seleccionando Desarrollador web , luego Red :

    Herramientas de red

    Una vez que aparecen las herramientas de red, haga clic en el pequeño botón en la esquina inferior derecha que parece un cronómetro:

    pequeño botón en la esquina inferior derecha que parece un cronómetro

    Esto iniciará un análisis de rendimiento que evaluará lo que sucede durante una primera visita (sin recursos en caché) o una visita posterior (algunos recursos en caché).

    Aquí están los resultados de mi sitio personal:

    resultados de mi sitio personal

    El gráfico circular y la tabla inferiores representan una carga por primera vez, y el gráfico y la tabla superiores representan una carga posterior cuando un visitante tiene algunos recursos almacenados en caché en su navegador.

    Hay un par de cosas a tener en cuenta aquí que serán relevantes en breve:

    • Verás que solo tengo 1 archivo JS y 0 archivos CSS: mi CSS está en línea en el HTML
    • También verá que solo se cargan dos imágenes: esta página en realidad tiene 6 imágenes, pero solo las cargo cuando es necesario
    • Tengo un total de solo 4 solicitudes de página
    • El tamaño total transferido es 183.04 KB

    Y los resultados del sitio de demostración del tema:

     resultados del sitio de demostración del tema

    Estos resultados son un poco diferentes:

    • 11 archivos JS y 5 archivos CSS
    • 41 imágenes
    • A total of 59 page requests
    • Total transferred size is 5,237.26 KB

    These results are starting to form a picture of where the problems are, and sure enough they line up with problems 1 through 4 we outlined earlier:

    Images are loaded before they are needed; I counted 14 that were visible in the viewport size I was using, meaning the remaining 27 could be loaded later.

    There are too many JS and CSS files; 11 JS and 5 CSS, when typically you should only ever need one of each.

    This, plus the early loading of images, results in 41 unnecessary page requests.

    We can’t tell yet for certain, but with 59 page requests and over 5 MB of transfer there’s a pretty good chance some data is being loaded that isn’t really needed.

    The total amount of transferred data is 28 times greater than my site. This is certainly a more complex site than mine, but by no means is it even close to 28 times more complex, meaning there is a lot of unnecessary data being transferred.

    In the performance analysis results we can see 2,783.51 KB is images, which is a little over half the total data. With 40 images that’s an average of about 68 KB per image, which is fine on face value, so we’ll wait for more information in the next step before deciding if the files are too large.

    The next thing we can look at is that there is 2,282.71 KB worth of JS files, 207 KB per file. To contrast, each one of those files is 29 times larger than all the JS on my entire site. The total amount of JS is 326 times more than on my entire site. As I mentioned, the theme demo site is certainly more complex than my own, but in no way is it 326 times more complex. There is major room for decreasing JS file size.

    The analysis also shows us that the theme demo site has 1,233.16 KB of CSS, though only 148.18 KB of it is transferred. My personal site has its CSS inline in the HTML which is why it doesn’t appear on the analysis, but for contrast it has a file size of 9.5 KB before processing. Again, the theme demo site is more complex, but it is not 129 times more complex. There is also major room for decreasing CSS file size.

    Next up we’re going to use a second performance audit to confirm the information we have so far and help give us more specific direction on the areas that need attention.

    Chromium browsers come with a website auditing tool called “Lighthouse”. This is the same tool that powers the Google Page Speed website, but is available directly in the browser.

    To access it, with your site still open in an incognito window, go to the Audits tab in the developer tools. Set Device to Mobile, uncheck all the audits except Performance, leave Throttling set to Simulated Fast 3G, 4x CPU Slowdown, and leave Clear storage checked. Click the Run audits button to commence the performance audit:

    Faro

    These are the audit results from my personal page:

    Estos son los resultados de la auditoría de mi página personal.

    Como puede ver, la optimización cuidadosa ha llevado a un puntaje de 100 de 100, con todas las auditorías aprobadas. Es importante destacar que el tiempo para el valor interactivo es 1.9 segundos. Esta auditoría se realiza en 3G rápido simulado en lugar de 3G lento , pero está muy por debajo de la velocidad recomendada por Google de 5 segundos.

    Estos son los resultados de la auditoría de la página de demostración del tema (información de identificación eliminada):

    resultados de auditoría de la página de demostración del tema

    Este es un resultado bastante duro. El tiempo para la velocidad interactiva es de 12,4 segundos, y sin siquiera estar en 3G lento emulado , pierde la velocidad recomendada por Google en 7,4 segundos.

    Las secciones de Oportunidades y Diagnóstico nos dan una especie de lista de tareas para completar, y como se esperaba, las tareas se alinean con los problemas que identificamos en la última sección. Cada una de estas secciones se puede ampliar para mostrar más detalles sobre lo que se debe hacer para acelerar el sitio. En la próxima sección hablaremos sobre formas de actuar, pero por ahora echemos un vistazo más de cerca a algunos de los puntos de mayor prioridad en esta auditoría.

    Primero, verá en la parte superior de la lista de oportunidades Diferir imágenes fuera de pantalla . Esto significa que los archivos de imagen se están cargando antes de que sean necesarios y, por lo tanto, la auditoría admite lo que determinamos en la última sección. Estima que cargar imágenes más tarde podría ahorrar la friolera de 10 segundos de tiempo de carga. Por lo tanto, esta optimización por sí sola podría reducir el tiempo de medición interactivo por debajo del objetivo de 5 segundos.

    Expandir la sección muestra que se están cargando 31 imágenes antes de que sean necesarias, incluso más de lo que supuse inicialmente de 27. Los datos estimados que podrían guardarse en total suman 2,021 KB . Eso es enorme. (Información de identificación eliminada):

    Los datos estimados que potencialmente podrían guardarse totalizan 2021 KB

    La siguiente oportunidad de mayor prioridad enumerada estima que se podrían guardar 2,4 segundos de tiempo de carga si el sitio tuviera el “tamaño adecuado de las imágenes”. En la última sección vimos que el tamaño total del archivo de toda la imagen de la página era bastante considerable, pero no pudimos determinar si alguna imagen individual era demasiado grande. Expandir esta sección de la auditoría nos dice que, de hecho, 9 imágenes son demasiado grandes y podrían optimizarse significativamente, ahorrando potencialmente 487 KB (información de identificación eliminada):

    9 imágenes son demasiado grandes

    Mencionamos anteriormente que era probable que se estuvieran cargando datos innecesarios y aquí vemos que ese es el caso. La auditoría estima que se podrían ahorrar 0,75 segundos aplazando, es decir, no cargando, CSS no utilizado. Expandir la sección muestra que hay cuatro archivos CSS que no se usan en su totalidad o en parte, y 135 KB de datos (información de identificación eliminada):

    CSS no utilizado que se está cargando

    I also want to point out something that is working in this theme demo site’s favor, and that is the server it is hosted on is snappy. Note item 6 in the passed audits highlights that the server took only 350ms to respond and start sending back data.

    For contrast, here’s an example of a site that failed this audit with its server costing the site an extra half second due to slow response time:

    This metric doesn’t give us exact feedback on the quality of a host’s servers. Getting a response in the red doesn’t mean the host is bad, because it can be a configuration option that causes the slow response. However, getting a result in the green rules out that the host is bad, because if it were it wouldn’t be capable of generating an audit passing response time.

    Now that we’ve gone through our step-by-step evaluation process, we can identify some of the most prominent reasons the theme demo site we’ve been examining is so slow, categorizing them under the problems 1 through 4 we defined earlier:

    31 images are loaded too early, causing a wait for over 2 MB of transfer.

    11 JS files and 5 CSS files instead of one of each.

    135 KB of unused CSS is being loaded.

    9 of the 41 images are too large, an excess of 487 KB.

    We saw from the TTFB metric in the performance audit that this site’s server responds quickly, so Problem 5 of slow hosting is not an issue for this site. The slow loading was due to other issues.

    As to whether caching and a CDN is in use, Problem 6 and Problem 7, that doesn’t need to be a part of an evaluation process because you will already know whether or not you have set up caching and a CDN. (More on these in the next section).

    Alright, now we’re ready to get into the practical bit where we actually solve the kinds of problems you’ve seen occurring on the theme demo site we’ve been examining. Unfortunately, that site is not mine to fix, but if and when you see the same issues popping up in WordPress sites of your own, here’s what you should do about it.

    There are several plugins available that can handle most of the solutions I’m about to lay out. However as it happens there is a free plugin made by SiteGround, the sponsors of this post, that when used in conjunction with their WordPress hosting service, can implement every single one of the following solutions.

    See more details about what they offer and get up to 70% off their managed WordPress hosting through Themeforest:

    sitio web de alojamiento de wordpress
    get up to 70% off their managed WordPress hosting through Themeforest

    The plugin is named SG Optimizer and can be downloaded from wordpress.org.

    SG Optimizer por SiteGround

    Note: to use this plugin you need to be using SiteGround as your host, because it interfaces with WordPress specific configuration and optimization SiteGround performs on their servers.

    You can of course use any combination of plugins you like to implement each of the following solutions, but as SG Optimizer can take care of them all I will use it to provide examples.

    Lazy loading is a site optimization technique whereby only the images that are in the visible area of the page, as well as those about to be scrolled to, are loaded right away. We saw in our earlier example that lazy loading can have a huge impact, and can be the difference between a site that loads at the required speed and one that lags in a damaging way.

    Lazy loading can be baked right into a theme, but in WordPress it is more typically enabled by way of a plugin.

    In the SG Optimizer plugin it can be activated in the Image Optimization section by flicking on these switches:

    It’s worth reiterating: if our theme demo page had installed this plugin and flipped those switches, they’d have saved over 2 MB and 10 seconds of loading and quite possibly met the Google recommended time.

    The reason there is no need to have more than one JS file or CSS file is you can take all the separate files and combine them into one through an automated process. This is typically also done with a plugin so that as you add and remove things from your site your CSS and JS can be re-combined as required.

    In SG Optimizer you can activate combining in the Frontend Optimization section by flipping the Minify JavaScript Files and Minify CSS Files switches:

    Plugins being active when they aren’t critical to a site’s operation is one of the leading ways to load a whole bunch of CSS and JS files you really don’t need.

    Be severe with culling plugins out of your setup. If there is a way you can run your site without a given plugin, do so. Even if they have no associated CSS or JS files to load, every plugin adds processing load to your server. The benefit of each plugin has to be clear and significant, otherwise cut it loose.

    Additionally, go through the settings of the plugins you need to keep and see if there are configuration options that allow you to load fewer resources. For example, if a plugin has sub-modules deactivate as many as you can. If it offers custom styles try to avoid them. Be as spartan as possible, remembering that every extra second of load time causes lost visitors.

    One additional point is that WordPress itself will automatically load files that add emoji images to your site. This, for most sites, falls squarely into the unnecessary data category. To prevent WordPress loading emojis you can go to SG Optimizer’s Frontend Optimizations area and activate the Disable Emojis option:

    At this point you’ll have reduced the amount of HTML, JS and CSS to a minimum, and combined your JS and CSS into single files. Now you’re ready to make sure those files as as small in size as possible by doing something called minifying.

    Minifying text based files like HTML, JS and CSS removes all the white space and line breaks. Doing this can reduce files down to half their former size.

    As with combining, minifying for WordPress is done via a plugin so files can be re-minified as required.

    In the SG Optimizer plugin this is done in the Frontend Optimization area with the same switches that activate combining. Turn all three on:

    We saw in our theme demo site examination that 487 KB could have been saved with further image compression.

    Generally speaking, images should be properly optimized and compressed before they are added to a site, but sometimes you don’t get the opportunity and have to optimize images as you go.

    SG Optimizer can optimize existing and new images via the Image Optimization section. Activate the first switch, and if you need to optimize existing images click the Start optimization button:

    I’m sure you will have had the experience of downloading files that have been zipped, i.e. compressed so they are smaller and faster to transfer. Well, effectively the same thing can be done to your site via GZIP, allowing it too to become smaller and faster.

    As with many of our solutions so far, on WordPress enabling GZIP is done via a plugin.

    In SG Optimizer go to the Environment Controls section and flip this switch:

    Controles ambientales

    When you are evaluating hosts try to find the page on their site that gives information about their data centers and technology stack. This is a bit more difficult a topic to pin down than the others we’ve discussed so far, but see what the company has to say about how they ensure their servers deliver sites fast. Do they own their own data center? If so, where is it, and how reliable is it? If not, which company’s data centers are they running on top of? Google Cloud? AWS? How reputable are said data centers?

    Something easier to evaluate about a host for WordPress though is whether or not they offer system optimizations made explicitly for WordPress sites. For example, you’ve already seen in the solutions we covered above how SiteGround offers the SG Optimizer plugin to interface with servers that are configured to help optimize WordPress sites. Try to find a host that knows WordPress, and undertakes special measures to cater for it.

    Caching, that is storing of data for faster delivery, can be controlled at multiple levels with a WordPress site. As with many of the solutions above, caching is implemented in WordPress by way of a plugin, and with some hosts there will be control panel settings that need to be activated as well.

    The first of those levels is in the browser itself. Rules can be communicated to the browser about how long it should store files from your site. In SG Optimizer, under the Environment Optimization section, you can flip the Browser Caching switch to extend the duration cached resources are stored in the browser:

    Interruptor de almacenamiento en caché del navegador

    You can also have SG Optimizer remove the strings that get added to the end of file names by WordPress by default, which will further assist browser caching. This is done in the Frontend Optimization section:

    eliminar las cadenas que se agregan al final de los nombres de archivo

    Depending on the host and caching plugin you are using there will be various kinds of caching that can happen on the server.

    By default, every time a person visits a webpage the whole thing has to be generated by WordPress, through combining content from the database in with information from your theme and plugin files. Caching on the server stores a copy of what gets generated so that the next person can just load that stored copy instead of waiting for the page to get created from scratch again.

    In the case of using SiteGround hosting plus SG Optimizer you get access to Dynamic Caching and Memcached. (Each of them have to be enabled in the hosting account control panel prior to use with WordPress).

    Both are activated in the SG Optimizer plugin’s Super Cacher area, by activating the Dynamic caching switch:

    activar el interruptor de almacenamiento en caché dinámico

    Y el interruptor Memcached :

    Incluso si su sitio se carga súper rápido para usted, eso no necesariamente significa que se cargará tan rápido para alguien más alejado del servidor que usted. Para garantizar que todos obtengan una experiencia de carga rápida de su sitio, lo mejor que puede hacer es usar un CDN o red de entrega de contenido.

    Un CDN es una red de servidores adicionales en todo el mundo en los que se duplicará su sitio web. Luego, en lugar de cargar su sitio desde su centro de datos original, un visitante lo cargará desde el punto CDN más cercano.

    Para ilustrar cómo puede funcionar esto, la siguiente imagen muestra los centros de datos propios de SiteGround, en naranja, y los puntos CDN con los que se integran, en azul:

    WordPress Lento 7 Problemas

    Observe cuánto más cerca están los servidores de CDN de las personas en Oceanía, América del Sur, África y gran parte de Europa y Asia.

    En mi experiencia, la mayoría de los hosts no incluyen el acceso a un CDN y debe organizarse por separado, o si tienen un CDN integrado, hay un precio adicional para usarlo. Sin embargo, en el caso de SiteGround, el uso de CDN integrado (Cloudflare) se incluye sin cargo adicional.

    A veces, después de haber hecho todo lo anterior, puede encontrar que su sitio todavía es demasiado lento, y la razón podría ser que solo tiene un tema mal diseñado. Si el desarrollador de su tema no fue consciente de cómo crearon el código que ejecuta su sitio, no se puede hacer mucho sin que ellos realicen una revisión completa de la optimización.

    Si cree que su tema podría ser el mayor culpable de su sitio lento, intente cambiar temporalmente algunos temas diferentes y ver cuánta variación tiene. Si cambiar los temas provoca una aceleración importante en la velocidad de carga, sabrá que lamentablemente recibió un fracaso, y es hora de obtener un nuevo tema que esté mejor diseñado para una carga rápida.

    He compartido absolutamente todo lo que sé de mis 12 años de experiencia en hacer que los sitios de WordPress se carguen súper rápido, y ahora todo lo que necesita hacer es implementar los pasos de evaluación y las soluciones que le presenté.

    La velocidad de carga del sitio todavía se pasa por alto sorprendentemente, dados los costos potencialmente altos de una optimización deficiente. Es de importancia crítica y es algo que todo administrador de sitios web debe encargarse de aprender íntimamente y dominar.

    Apunte a ese puntaje de auditoría de desempeño de 100 de 100, haga que sus visitantes disfruten de su sitio web en menos de unos segundos y luego vea cómo aumenta el éxito de su sitio.

    Gracias a SiteGround por patrocinar esta publicación, ¡no olvide que puede obtener hasta un 70% de descuento en su  alojamiento administrado de WordPress a través de Themeforest !

    Llama ahora
    Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Al hacer clic en el botón Aceptar, aceptas el uso de estas tecnologías y el procesamiento de sus datos para estos propósitos.
    Privacidad