Ir al contenido 
Muchos Fuentes web WordPress se cargan en paralelo, bloquean el renderizado y, por tanto, prolongan el LCP y el FCP, especialmente en dispositivos móviles. En este artículo, te mostraré por qué demasiadas fuentes cuestan tiempo, cómo se producen los FOIT/FOUT y qué medidas específicas acelerarán notablemente tu sitio.
Puntos centrales
- Reducción a unos pocos cortes reduce las peticiones y la transferencia de datos
- Precarga y Preconnect priorizan los archivos importantes
- fuente-display Evita el texto invisible (FOIT)
- Local el alojamiento ahorra latencias externas y CORS
- Subconjunto elimina los glifos no utilizados y reduce el tamaño de las fuentes
Por qué muchas fuentes web en WordPress cuestan tiempo de carga
Cada fuente adicional aporta más Solicitudes, más búsquedas DNS y kilobytes adicionales. Varias familias con normal, negrita y cursiva suman rápidamente entre 500 y 1000 KB antes de que el texto aparezca limpiamente. Esto tiene un efecto directo sobre el Largest Contentful Paint (LCP) porque el navegador sólo puede renderizar cuando las fuentes importantes están disponibles. Sólo tres tipos de letra pueden alargar la primera renderización entre un 20% y un 50%, lo que afecta mucho a los usuarios con conexiones lentas. Por eso me centro en unos pocos cortes claramente definidos y en fallbacks seguros para evitar el bloqueo de la renderización.
Cómo se cargan las fuentes web en WordPress - y dónde se atascan
Las fuentes web a menudo proceden de proveedores externos o de opciones de temas, lo que supone un coste adicional. DNS-lookups y apretones de manos TLS. Con FOIT (Flash of Invisible Text), el navegador espera a las fuentes y muestra texto invisible hasta entonces, lo que refuerza la impresión de que „no pasa nada“. FOUT (Flash of Unstyled Text) es mejor, pero produce breves saltos de diseño al pasar de la fuente fallback a la web. Sin priorización, preconexión y almacenamiento en caché sensato, el tiempo de carga y la sensación de TTFB aumentan. Planifico la integración de modo que el contenido principal aparezca siempre en primer lugar y las fuentes fluyan después sin tartamudear.
Auditoría y supervisión: haga visibles todas las fuentes
Antes de optimizar, obtengo una visión completa. En las DevTools, filtro en la pestaña Red para „Fuente“, compruebe los nombres de los archivos, el tamaño de las transferencias y Iniciador (tema, plugin, editor de bloques). Los tiempos de cascada me muestran si las fuentes están bloqueando la ruta crítica. En el panel Cobertura, puedo ver si los grandes bloques CSS @font-face sólo un mínimo puede utilizarse. Un rastreo de rendimiento revela si el renderizado de texto se bloquea hasta que los archivos WOFF2 están listos. A nivel de WordPress, desactivo plugins a modo de prueba para identificar fuentes de fuentes ocultas (creadores de páginas, paquetes de iconos). Mis métricas principales aquí: número de solicitudes de fuentes, KB totales, tiempo hasta la primera línea legible, duración de FOUT/FOIT e impacto en LCP/FCP en la tira de película.
Comparo datos de laboratorio y de campo: Un escritorio rápido vía LAN enmascara problemas que sólo se hacen visibles en la red 4G. Por eso hago las pruebas con una CPU y un ancho de banda reducidos para simular condiciones móviles realistas. Sólo cuando las cadenas están limpias y las fallbacks se renderizan de forma estable, añado más ajustes tipográficos.
Efectos mensurables en Core Web Vitals
LCP, FCP y CLS reaccionan sensiblemente a una carga imprudente Fuentes, porque las fuentes retrasadas cambian el diseño y oscurecen el contenido. Según HTTP Archive, las páginas con fuentes web transfieren muchos más datos de media, lo que se nota más en los dispositivos móviles. La documentación de PageSpeed Insights explica claramente que los recursos que bloquean la renderización alargan el camino hasta la primera visualización. Las peticiones priorizadas acortan esta cadena y reducen notablemente los tiempos de espera. Si desea profundizar en la priorización, puede encontrar información de fondo en Priorización de solicitudes, que utilizo específicamente para temas extensos.
Causas técnicas en detalle
Muchos archivos individuales, estilos no combinados y subconjuntos ausentes aumentan la Carga útil innecesario. Sin HTTP/2 o HTTP/3, las solicitudes suelen ponerse en cola y bloquear la ruta de renderizado. Los dominios externos como fonts.googleapis.com añaden latencias adicionales, que se suman para múltiples familias. Las cabeceras CORS son necesarias, de lo contrario el navegador cancela las precargas o no las utiliza. Yo evito estos escollos mediante la provisión local, la configuración limpia de las cabeceras y la limitación selectiva a dos o tres cortes.
Evite las trampas tipográficas: Métricas, calidad alternativa y falsos estilos
Además del tamaño puro del archivo, los detalles tipográficos influyen en la estabilidad de la visualización. Si las métricas de la fuente fallback y de la fuente web difieren mucho, se producen saltos visibles durante el intercambio. Igualo la altura mediante ajuste de tamaño y estilos sintéticos de bloque para evitar „falsas“ negritas/cursivas:
@font-face {
font-family: 'Inter';
src: url('/fonts/Inter-roman.var.woff2') format('woff2');
font-weight: 100 900;
font-style: normal;
font-display: swap;
/* Ajustar métricas para reducir CLS */
ajuste de tamaño: 100%;
ajuste ascendente: 90%;
descent-override: 20%;
line-gap-override: 0%;
}
/* Armonizar visualmente la fuente fallback */
body {
font-family: system-ui, -apple-system, Segoe UI, Roboto, Inter, sans-serif;
font-size-adjust: 0.5; /* Mejor ajuste de altura x */
font-synthesis: none; /* Evita falsas negritas/cursivas */
}Defino un eje o archivo estático separado para las variantes cursivas y evito las cursivas de imitación. También organizo font-weight con precisión (300/400/600/700) para que el navegador no interpola. Este trabajo de precisión lleva poco tiempo, pero evita que se produzcan cambios notables en el diseño al pasar de la fuente fallback a la fuente web.
Racionalización: tres medidas inmediatas
Reduzco el número de familias, sustituyo los cortes decorativos por fallbacks y utilizo sistemáticamente fuente-displayswap. Las pilas de sistema (-apple-system, Segoe UI, Roboto, Noto Sans, Ubuntu, Cantarell) dan salida rápidamente al texto mientras la fuente web se carga en segundo plano. Los encabezados suelen requerir sólo un corte en negrita, el cuerpo del texto una variante normal. También elimino las llamadas remotas innecesarias para generar menos peticiones. Si quieres sacarle aún más partido, puedes Reducir las peticiones HTTP y aliviar así todo el camino crítico.
Sustituir fuentes de iconos: SVG ahorra peticiones
Muchos temas vienen con fuentes de iconos (por ejemplo, para iconos sociales o de interfaz de usuario). Una sola fuente de iconos puede pesar entre 30 y 80 KB y puede ser @font-face influyen en la ruta de renderizado. Sustituyo estas fuentes por SVG - en línea o como sprite. Así se reducen las solicitudes, se evita el FOIT/FOUT para los iconos y se garantiza una visualización nítida en todas las pantallas. Si no es posible realizar un cambio completo de inmediato, subselecciono la fuente de los iconos para los pictogramas que se utilizan realmente y establezco font-display: opcional, para que la página nunca espere la fuente del icono:
@font-face {
font-family: 'ThemeIcons';
src: url('/fonts/theme-icons-subset.woff2') format('woff2');
font-display: opcional; /* La interfaz de usuario permanece operativa, los iconos aparecen más tarde */
}Inline SVG también me permite controlar colores y estados mediante CSS sin cargar nuevos archivos. Esto encaja perfectamente con el objetivo de mantener la cadena de renderizado crítica lo más corta posible.
Utilizar correctamente la precarga, la preconexión y el precalentamiento
Utilizo Preconnect para el decisivo Dominio, para priorizar DNS, TCP y TLS. Sólo uso la precarga para archivos WOFF2 realmente críticos, de lo contrario desperdicio la prioridad en recursos secundarios. La etiqueta debe establecer as=“font“, type=“font/woff2″ y crossorigin, de lo contrario el navegador ignorará parcialmente la sugerencia. Demasiadas precargas se sabotean entre sí y empujan contenidos más importantes al fondo. Un conjunto de sugerencias sencillo y probado acorta el tiempo hasta la primera línea legible:
Alojar localmente y seguir cumpliendo el GDPR
Descargo las fuentes que necesito, las subconjunto y las sirvo directamente desde mi propia Servidor. Esto ahorra búsquedas DNS externas, reduce los problemas de CORS y me da un control total de la caché. Un enfoque local facilita largos tiempos de ejecución de la caché y garantiza una disponibilidad constante. Para mayor claridad jurídica y aplicación práctica, mi guía de Google Fonts local. Así es como mantengo limpia la tecnología y la protección de datos sin sacrificar la tipografía.
Subconjuntos y fuentes variables: máximo efecto con tamaño pequeño
En lugar de cargar paquetes de idiomas completos, sólo guardo los necesarios Glifos y eliminar conjuntos exóticos. El latín sin extensiones suele ahorrar entre un 40 y un 70% de tamaño de archivo, lo que se nota especialmente en dispositivos móviles. Las fuentes variables sustituyen varios archivos estáticos por un único recurso con ejes para el peso y la cursiva. Esto reduce las peticiones y mejora la priorización si sólo precargo un archivo WOFF2. Al mismo tiempo, se mantiene la diversidad visual sin tener que transferir cinco secciones individualmente.
Fuentes variables en la práctica: uso específico de los ejes
En la realización, evito las zonas de eje innecesariamente anchas. Limito wght por ejemplo, a 400-700 si sólo se utilizan Regular y Negrita. Esto reduce la complejidad de la representación y mantiene la coherencia visual. Para la tipografía responsiva, utilizo sistemáticamente pesos numéricos, no palabras clave:
@font-face {
font-family: 'InterVar';
src: url('/fonts/Inter-roman.var.woff2') format('woff2');
font-weight: 400 700; /* Rango estrecho en lugar de 100-900 */
font-style: normal;
font-display: swap;
}
h1, h2 { font-family: 'InterVar', system-ui, sans-serif; font-weight: 700; }
p { font-family: 'InterVar', system-ui, sans-serif; font-weight: 400; }
:root { font-optical-sizing: auto; }
/* Casos especiales por eje, cuando proceda:
.element { font-variation-settings: 'wght' 650; } */Esto mantiene la flexibilidad de una fuente variable sin cargar el sistema con etapas intermedias innecesarias.
¿Qué optimización aporta cuánto? (Resumen)
El siguiente resumen muestra lo que utilizo en la práctica para conseguir el mayor Ahorro y a qué presto atención. Los valores son rangos empíricos y dependen del estado inicial, el tema y el número de ediciones. Pruebo cada cambio con PageSpeed Insights y una ejecución de WebPageTest para reconocer los efectos secundarios. A continuación, realizo ajustes específicos en los valores umbral y el almacenamiento en caché. Esto aumenta la certeza de que cada medida gana tiempo real.
| Enfoque de optimización | Ahorro típico | Nota importante |
|---|---|---|
| Reducción a 2 cortes | 150-400 KB | Limpiar Fallbacks configure |
| font-display: swap | + texto de lectura rápida | Aceptar FOUT en lugar de FOIT |
| Alojamiento local + caché larga | 2-3 solicitudes menos | Control de caché/ETag correcto |
| Preconexión + precarga específica | 50-200 ms | Sólo crítico Archivos |
| Subconjunto (base latina) | 40-70 % más pequeño | Ampliable posteriormente |
| Fuente variable en lugar de 4 archivos | -3 Solicitudes | Utilice sólo WOFF2 |
Utilice los plugins con sensatez: sin sobrecarga
OMGF carga localmente las fuentes de Google, las subconjunta automáticamente y acorta las innecesarias. Firme fuera. Asset CleanUp me permite desactivar fuentes página por página si una plantilla específica no las necesita. Autoptimise combina CSS, minifica y puede extraer fuentes para que los estilos críticos vayan primero. Pruebo las combinaciones cuidadosamente porque una agregación excesiva en HTTP/2 puede ser contraproducente. El objetivo sigue siendo una cadena estable y corta hasta el primer contenido visible.
Aplicación práctica en WordPress: ejemplos de código
Muchos temas o creadores de páginas incluyen las fuentes automáticamente. Elimino fuentes duplicadas, cambio a archivos locales y establezco prioridades claras - preferiblemente en el tema hijo.
1) Elimine las fuentes externas del tema y cargue las fuentes locales
/* functions.php en el tema hijo */
add_action('wp_enqueue_scripts', function() {
/* Personalizar/encontrar manejadores de ejemplo del tema/constructor */
wp_dequeue_style('google-fonts');
wp_dequeue_style('google-fonts');
/* Incluye tus propios estilos de fuente locales */
wp_enqueue_style('local-fonts', get_stylesheet_directory_uri() . '/assets/css/fonts.css', [], '1.0', 'all');
}, 20);2) Precarga específica para el crítico WOFF2
/* functions.php */
add_action('wp_head', function() {
echo '';
}, 1);3) Establecer el almacenamiento en caché y el encabezado CORS para las fuentes
# .htaccess (Apache)
AddType font/woff2 .woff2
Header set Cache-Control "public, max-age=31536000, immutable"
Header set Access-Control-Allow-Origin "*"# Nginx (bloque servidor)
location ~* .(woff2|woff)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
add_header Access-Control-Allow-Origin "*";
types { font/woff2 woff2; }
}4) Ejemplo de fonts.css con subconjuntos y swap
@font-face {
font-family: 'Inter';
src: url('/fonts/InterLatin-400.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
unicode-range: U+000-5FF; /* Base latina */
}
@font-face {
font-family: 'Inter';
src: url('/fonts/InterLatin-700.woff2') format('woff2');
font-weight: 700;
font-style: normal;
font-display: swap;
unicode-range: U+000-5FF;
}Páginas multilingües: Carga de subconjuntos por localización
Para proyectos internacionales, sólo cargo las fuentes necesarias. En WordPress, puedo cargar por Local registran estilos diferentes. Por ejemplo, el alemán/inglés se queda con un subconjunto de latín reducido, mientras que una variante polaca o turca obtiene glifos ampliados - pero sólo donde sea necesario.
/* functions.php */
add_action('wp_enqueue_scripts', function() {
$locale = get_locale();
if (in_array($locale, ['de_DE','en_US','en_GB'])) {
wp_enqueue_style('fonts-latin', get_stylesheet_directory_uri().'/assets/css/fonts-latin.css', [], '1.0');
} elseif (in_array($locale, ['pl_PL','tr_TR'])) {
wp_enqueue_style('fonts-latin-ext', get_stylesheet_directory_uri().'/assets/css/fonts-latin-ext.css', [], '1.0');
}
});Importante: Me aseguro de que el cuerpo del texto siempre tenga una sólida cadena de fallback del sistema. Esto garantiza que la página siga siendo legible aunque falle un archivo de idioma o se enfríe la caché.
Alojamiento, caché y CDN como multiplicadores
Las rápidas unidades SSD NVMe, HTTP/3 y una CDN acortan el TTFB y ofrecen Fuentes más rápido globalmente. Una caché del lado del servidor reduce las peticiones de backend, mientras que la caché del navegador obtiene las fuentes de la caché local durante meses. Brotli para WOFF2 apenas aporta nada, pero para CSS con @font-face sigue mereciendo la pena. También doy prioridad a las partes CSS críticas en línea para que el texto aparezca inmediatamente. Esto crea una cadena: backend fijo, entrega limpia, archivos de fuentes más pequeños - y al final un texto visible más rápido.
Plan de pruebas y puesta en marcha
Introduzco optimizaciones de fuentes paso a paso para minimizar los riesgos. Primero, documento el statu quo (peticiones, KB, LCP/FCP/CLS). A continuación, reduzco las familias y los cortes, sustituyo los iconos y cambio a archivos WOFF2 locales con una caché larga. Luego añado Preconnect/Preload - deliberadamente con moderación. Después de cada paso, compruebo la tira de película para ver si se ha reducido el FOIT y si han desaparecido los saltos de diseño. Sólo cuando ya no se aprecian regresiones, aplico los cambios a todas las plantillas.
Las páginas con encabezados poco habituales (tamaños de letra muy grandes, rastreo) o que utilizan mucho la cursiva son especialmente críticas. Aquí compruebo específicamente si ajuste de tamaño y las anulaciones métricas realmente captan los saltos de retroceso. Mi objetivo sigue siendo constante: la primera línea legible tan pronto como sea posible - sin actos de doma a través de fuentes tardías.
Breve resumen: reducción del tiempo de carga y aumento de la legibilidad
Demasiadas fuentes cuestan dinero Segundos, porque alargan las peticiones, bloquean el renderizado y aumentan el volumen de datos. Yo mantengo las fuentes al mínimo, priorizo específicamente y confío en el intercambio, el subconjunto y el alojamiento local. Esto disminuye de forma fiable el LCP y el FCP y reduce los saltos visuales. Con la monitorización a través de PageSpeed Insights y pruebas repetidas, aseguro el efecto y recojo valores históricos. Esto mantiene la tipografía fuerte sin que los usuarios tengan que esperar, que es exactamente lo que quiero conseguir.
