Ir al contenido 
Optimizo la velocidad de wordpress sin plugins con intervenciones manuales que reducen visiblemente los tiempos de carga y alcanzan de forma fiable los valores vitales de la web. Así mantengo el control sobre Solicitudesrecursos y efectos secundarios y eliminar el lastre en su origen.
Puntos centrales
- fotos Comprime de forma consistente antes de subirlo y conviértelo a formato WebP
- Carga perezosa de forma nativa mediante atributos HTML en lugar de extensiones sobrecargadas.
- Almacenamiento en caché mediante .htaccess/server y estrategia de cabecera limpia
- Código Minimizar, agrupar y evitar los bloqueadores de renderizado
- Lastre eliminar en WordPress, base de datos y temas
Por qué optimizo sin plugins
Los plugins parecen prácticos, pero añaden peticiones, scripts y estilos que bloquean las rutas de renderizado iniciales y hacen que mi TTFB se deterioran. Cada dependencia adicional aumenta la superficie de error y dificulta el análisis de las causas de las caídas de rendimiento. Utilizo medidas manuales para reducir las cadenas de carga y minimizar el número de componentes activos. Esto me permite reducir los gastos generales, mantener la flexibilidad y reaccionar más rápidamente ante nuevas necesidades. Este enfoque evita los efectos secundarios causados por las cadenas de actualización y mantiene el mantenimiento al mínimo. esbelto.
Adelgazar imágenes: Formatos, tamaños y compresión
Las imágenes grandes no matan el tiempo hasta el primer byte, pero dominan el tiempo de transferencia y el LCP, por lo que reduzco cada activo de antemano. Exporto las fotos como JPEG o WebP y sólo utilizo PNG para las transparencias reales. Escalo las dimensiones exactamente a los anchos de ventana requeridos en lugar de cargar 4000px cuando 800px son suficientes. A continuación, comprimo de forma coherente con Squoosh, ImageOptim o Photoshop y compruebo que no haya artefactos visibles. Para las variantes responsive, confío en srcset/sizes y me gusta utilizar esta abreviatura Guía de imágenes responsivaspara que el navegador cargue automáticamente la fuente más pequeña con sentido y mi Transferencia de datos disminuye.
Utilizar lazy loading de forma nativa
Sólo cargo imágenes e iFrames cuando entran en la ventana gráfica, de forma nativa a través de HTML5, en lugar de integrar scripts adicionales que supongan Tema principal load. El atributo loading="lazy" es totalmente suficiente en los navegadores modernos. De este modo, reduzco el número de bytes iniciales e igualo la fase crítica de renderizado. Al mismo tiempo, el control sigue siendo transparente y yo decido qué elementos de la mitad superior de la página cargo deliberadamente con ansia. Las imágenes hero críticas reciben loading="eager", todo lo demás carga offset.
<img src="beispiel.jpg" alt="Ejemplo de imagen" loading="lazy">
<iframe src="video.html" title="Video" loading="lazy"></iframe>Acelerar el PCL de forma selectiva: Prioridades y marcadores de posición
Para mejorar la estabilidad de Largest Contentful Paint, marco explícitamente mi elemento más grande por encima del pliegue. A las imágenes se les da fetchpriority="high" y dimensiones definidas para que el navegador las prefiera y CLS evita. Si es necesario, añado una precarga si el camino está despejado.
<!-- LCP-Image priorisieren -->
<link rel="preload" as="image" href="/assets/hero.webp" imagesrcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w" imagesizes="(min-width: 800px) 1200px, 100vw">
<img src="/assets/hero-800.webp"
srcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w"
sizes="(min-width: 800px) 1200px, 100vw"
width="1200" height="700"
fetchpriority="high"
loading="eager"
decoding="async"
alt="Héroe">Para las imágenes y los contenedores, establezco la anchura/altura o relación de aspectopara excluir los saltos de trazado. Para las zonas no críticas utilizo contenido-visibilidad: auto y contener-tamaño-intrínsecopara que el navegador renderice posteriormente las zonas fuera de la ventana gráfica sin mover el diseño.
/* Reserva por encima de la página */
.hero { relación de aspecto: 12 / 7; }
/* Disposición de las secciones no visibles más tarde */
.section { content-visibility: auto; contain-intrinsic-size: 1000px; }
Configurar específicamente la caché del navegador
Los visitantes recurrentes deben cargar los activos estáticos desde la caché, por lo que establezco los tiempos de caducidad directamente a nivel de servidor a través de .htacceso o en el vHost. TTLs largos para imágenes, moderados para CSS/JS, y cortos por defecto para HTML me dan el equilibrio entre puntualidad y velocidad. Presto atención al versionado coherente de los archivos para que las actualizaciones surtan efecto inmediatamente a pesar de los TTL largos. Combinado con ETags o cabeceras Last-Modified, el tráfico se reduce drásticamente. Esto me ahorra ancho de banda y acorta la duración percibida de las actualizaciones. Tiempo de carga.
ExpiresActive On
ExpiresByType image/jpg "acceso más 1 año"
ExpiresByType image/jpeg "acceso más 1 año"
ExpiresByType image/gif "acceso más 1 año"
ExpiresByType image/png "acceso más 1 año"
ExpiresByType text/css "acceso más 1 mes"
ExpiresByType application/pdf "acceso más 1 mes"
ExpiresByType text/javascript "acceso más 1 mes"
ExpiresByType application/x-javascript "acceso más 1 mes"
ExpiresDefault "acceso más 2 días"Estrategia de caché, versionado y revalidación
Combino TTLs largos con hashing de nombre de archivo para que los clientes almacenen en caché durante el mismo tiempo (style.9c2a.css) y las actualizaciones surten efecto inmediatamente. Para los paquetes que se modifican con frecuencia, establezco Cache-Control: public, max-age=31536000, immutablemientras que HTML corto no-cache-estrategias. Para respuestas dinámicas prefiero Solicitudes condicionales a través de ETag o Última modificaciónpara que los clientes revaliden con moderación:
Conjunto de encabezados Cache-Control "public, max-age=31536000, immutable"
Header set Cache-Control "no-cache, no-store, must-revalidate"Para los contenidos con variantes de formato (por ejemplo, WebP frente a JPEG), compruebo que Vary: Aceptar está configurado correctamente en Edge; esto evita que versiones erróneas acaben en la caché. Mantengo la coherencia de las versiones mediante procesos de compilación para que ningún activo quede obsoleto de forma incontrolada.
Optimice CSS y JavaScript
Minifico CSS/JS localmente en mi proceso de compilación y elimino comentarios, espacios y archivos no utilizados. Selectores. Empaqueto los estilos críticos para la parte superior de la página en línea, el resto los cargo de forma asíncrona o como un archivo diferido. Muevo los scripts que bloquean el renderizado al final, les añado defer/async y mantengo pequeño el número de librerías externas. En el caso de los frameworks, compruebo el temblor del árbol y los ámbitos de importación para no cargar todo lo que rara vez utilizo. En la medida de lo posible, agrupo los archivos para reducir las peticiones sin almacenar en caché el backend. deteriorarse.
Mejorar el INP: Aliviar el hilo principal
Para conseguir una interacción baja, divido las tareas largas en trozos más pequeños, evito el desorden del diseño y desacoplar los manejadores complejos de las interacciones. Utilizo aplazar para módulos, establecer escuchadores de eventos pasivos y programar el trabajo no crítico en los tiempos muertos:
document.addEventListener('touchstart', onTouch, { passive: true });
const expensiveInit = () => { /* ... */ };
requestIdleCallback(expensiveInit, { timeout: 1500 });
// Dividir tareas largas
function chunkedWork(items) {
const lote = items.splice(0, 50);
// procesa...
if (items.length) requestAnimationFrame(() => chunkedWork(items));
}Mido las tareas largas en DevTools, elimino las bibliotecas duplicadas y sustituyo las utilidades de jQuery por API nativas. Resumo las actualizaciones de DOM, utilizo transformar en lugar de arriba/izquierda y mantener los reflujos al mínimo.
Deshazte del lastre de WordPress
No necesito muchas funciones de WP en sitios productivos, así que desactivo emojis, oEmbeds y partes de la API REST y ahorro dinero. Solicitudes. Esto reduce la cabeza y menos scripts bloquean First Paint. También compruebo los pingbacks, los enlaces RSD y el manifiesto WLW y los desactivo. También desactivo los trackbacks y XML-RPC si no juegan ningún papel. De esta forma, reduzco la superficie de ataque y mantengo la fase de inicio luz.
// Desactivar emojis
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
// reducir oEmbeds y REST API
remove_action( 'wp_head', 'wp_oembed_add_host_js' );
add_filter('rest_enabled', '_return_false');
add_filter('rest_jsonp_enabled', '_return_false');Domar los scripts de terceros
El código de terceros suele ser el mayor freno. Yo lo inicializo con retraso, sólo incluyo lo absolutamente necesario y sólo lo cargo tras interacción o consentimiento. Llega la analítica y el seguimiento async Después de la primera pintura, sustituyo los widgets sociales por enlaces estáticos. Para iFrames utilizo loading="lazy" y areneropara limitar los efectos secundarios. Las incrustaciones de YouTube reciben una imagen de previsualización y sólo cargan el reproductor cuando se hace clic en él, lo que ahorra varias peticiones en el momento del inicio.
Mantenimiento de bases de datos sin ayudantes
Elimino las revisiones superfluas, vacío los transitorios y limpio los comentarios de spam a través de phpMyAdmin para que las consultas sean más rápidas. responder. Compruebo si las opciones de carga automática tienen un tamaño excesivo, porque acaban apareciendo en todas las consultas. En instalaciones más pequeñas, unas pocas sentencias SQL específicas bastan para optimizar las tablas. Compruebo si los cron jobs están colgados y ordeno los postmeta dejados por antiguos plugins. Un mantenimiento regular evita que las consultas se descontrolen y que mi backend se sature. lento ...lo hará.
Cron del sistema en lugar de WP Cron
Para garantizar que los cron jobs se ejecutan de forma fiable y eficiente, los desacoplamos de la carga de la página. Desactivo el WP-Cron y programo trabajos reales del sistema que funcionan en momentos de calma.
// en wp-config.php
define('DISABLE_WP_CRON', true);# crontab -e (cada 5 minutos)
*/5 * * * * * /usr/bin/php -q /ruta/hacia/wp/wp-cron.php >/dev/null 2>&1Esto significa que ningún cron bloquea el tiempo de respuesta de una solicitud regular, y se pueden programar tareas recurrentes como la limpieza transitoria o la generación de mapas del sitio.
Comprobación crítica del tema, los plugins y las fuentes
Elimino los temas inactivos y todas las extensiones que duplican funciones o que rara vez aportan algún beneficio, para que el Cargador automático carga menos. Para las fuentes, reduzco las variantes a normal/negrita y dos estilos de fuente, las alojo localmente y activo la precarga para el archivo principal. Preparo los recursos externos con DNS prefetch si realmente los necesito. Para las incrustaciones de YouTube, utilizo miniaturas para inicializar iFrames más tarde. De esta forma mantengo el control sobre las rutas de renderizado y conservo la carga inicial. pequeño.
Fuentes: comportamiento de carga, subconjuntos, fallbacks
Las fuentes web influyen mucho en la velocidad percibida. Yo utilizo font-display: swap o opcionalpara que el texto sea inmediatamente visible. Compruebo críticamente las fuentes variables y subconjunto las áreas Unicode para ahorrar bytes. Una precarga selectiva del archivo WOFF2 más importante reduce el FOIT.
@font-face {
font-family: 'Marca';
src: url('/fonts/brand-regular.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
unicode-range: U+000-5FF; /* latin base set */
}En la pila de fuentes, defino sistemas de retroceso limpios (por ejemplo, Segoe UI, Roboto, SF Pro, Arial) para minimizar los saltos de diseño. Acerca de ajuste de tamaño Ajusto las diferencias métricas para que el cambio de la fuente fallback a la web sea apenas visible.
Servidor, PHP y protocolos
Sin la infraestructura adecuada, cualquier optimización fracasará, por eso presto atención a las unidades SSD rápidas, actualizadas PHP-versiones y compatibilidad con HTTP/2. OPcache, Brotli/Gzip y la multiplexación HTTP/2 aceleran la entrega y reducen los bloqueos. Si es posible, considero HTTP/3/QUIC y compruebo la instalación y la configuración TLS cuidadosamente; este breve artículo sobre Implantar HTTP/3. Las pruebas de carga y estrés me muestran cómo reacciona la página bajo carga. Así me aseguro de que mi pila soporta la aplicación. lleva y mis medidas son eficaces.
| Proveedor de alojamiento | Características | Actuación | Apoyo | Relación calidad-precio |
|---|---|---|---|---|
| webhoster.de | SSD, PHP 8.*, HTTP/2 | ★★★★★ | ★★★★★ | ★★★★★ |
| Competidor 1 | SSD, PHP 7.*, HTTP/2 | ★★★★☆ | ★★★★☆ | ★★★★☆ |
| Competidor 2 | HDD, PHP 7.*, sin HTTP/2 | ★★★☆☆ | ★★★☆☆ | ★★★☆☆ |
Optimizar PHP-FPM, OPcache y transporte
Configuro PHP-FPM para que las peticiones no acaben en colas. pm, pm.max_hijos y pm.max_requests Dimensiono la carga. OPcache obtiene suficiente memoria para evitar recompilings.
php.ini / www.conf
opcache.enable=1
opcache.consumo_memoria=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
PHP-FPM (valores de ejemplo)
pm = dinámico
pm.max_children = 20
pm.servidores_inicio = 4
pm.min_servidores_servicio = 2
pm.max_servidores_servicio = 8
pm.max_peticiones = 500En la capa de transporte, activo Brotli antes que Gzip, mantengo Keep-Alive abierto y compruebo la reanudación de TLS. Con HTTP/2, compruebo la priorización para que CSS/font y la imagen LCP tengan prioridad. En HTTP/3, controlo la pérdida de paquetes y ajusto el ritmo.
CDN, cabecera de caché y geografía
Para el tráfico internacional, utilizo una red de borde para reducir la latencia y mantener los activos estáticos cerca del usuario. entregar. Presto atención a claves de caché limpias, cabeceras variantes (por ejemplo, para WebP) y versionado coherente. Cacheo cuidadosamente las páginas HTML críticas, las respuestas API de forma selectiva y las imágenes de forma agresiva. Un breve resumen de la Optimización CDN me ayuda a evitar errores como la doble compresión. Así es como combino la caché de servidor y de borde y mantengo los costes bajos. Ver.
Formatos, negociación y deduplicación en la periferia
Reproduzco imágenes en formatos modernos (WebP, AVIF opcional) y me aseguro de que la CDN respete la negociación de contenidos. Importante son correctos Acepte-variantes y una unicidad de las claves de caché. Evito el doble-Gzip comprimiendo sólo una vez (servidor o Edge) y desactivo la bandera en el otro extremo. Para HTML establezco TTL conservadores y ETags fuertes, los activos permanecen en caché de forma agresiva.
Medición, cifras clave y priorización
Empiezo con un presupuesto de rendimiento claro y me centro en LCP, CLS e INP en lugar de en cada valor en milisegundos. aislado a tener en cuenta. Los datos de campo están por encima de los valores de laboratorio, así que comparo las señales de usuarios reales con las ejecuciones de prueba. Los diagramas de cascada revelan activos bloqueantes, los mapas de peticiones muestran bibliotecas duplicadas y archivos de fuentes innecesarios. Mido cada cambio individualmente para reconocer rápidamente las regresiones. Sólo cuando las cifras mejoran de forma sistemática, los aplico de forma más generalizada. de.
Método de trabajo: despliegue limpio, reversión rápida
Incorporo comprobaciones de rendimiento en mi proceso de despliegue: Las compilaciones generan artefactos versionados, las pruebas de Lighthouse/DevTools se ejecutan en la fase de despliegue y sólo los paquetes verificados salen a la luz. Las banderas de características me permiten desplegar cambios arriesgados de forma controlada y desactivarlos inmediatamente si es necesario. Esto me permite mantener estable el rendimiento mientras desarrollo nuevas funciones.
Brevemente resumido: Cómo lo aplico
Primero optimizo los contenidos con mayor aprovechamiento: reduzco el tamaño de las imágenes, activo la carga lenta, alineo las partes críticas de CSS y bloqueo los scripts... turno. A continuación, aseguro las estrategias de almacenamiento en caché en el navegador y en el lado del servidor, ordeno las funciones de WordPress y la base de datos y elimino los plugins innecesarios. Compruebo la infraestructura, HTTP/2/3, Brotli y OPcache y aseguro procesos de despliegue limpios con versionado. Si es necesario, añado una CDN y regulo cabeceras y variantes. Por último, compruebo iterativamente los ratios hasta que LCP, CLS e INP son estables y verdes. Zonas mentira.
