{"id":3879,"date":"2026-10-04T11:42:31","date_gmt":"2026-10-04T09:42:31","guid":{"rendered":"https:\/\/mantenimientoweb.pro\/blog\/como-interpretar-las-metricas-de-rendimiento-web-usando-google-lighthouse-2\/"},"modified":"2026-10-04T11:42:33","modified_gmt":"2026-10-04T09:42:33","slug":"como-interpretar-las-metricas-de-rendimiento-web-usando-google-lighthouse-2","status":"publish","type":"post","link":"https:\/\/mantenimientoweb.pro\/blog\/como-interpretar-las-metricas-de-rendimiento-web-usando-google-lighthouse-2\/","title":{"rendered":"\u00bfC\u00f3mo interpretar las m\u00e9tricas de rendimiento web usando Google Lighthouse?"},"content":{"rendered":"<header>\n    <span>Rendimiento web, SEO t\u00e9cnico y experiencia de usuario \u26a1<\/span><br \/>\n    C\u00f3mo interpretar las m\u00e9tricas de rendimiento web usando Google Lighthouse<\/p>\n<p>Google Lighthouse no es una bola de cristal, aunque a veces se le consulte con la fe de quien pregunta el clima antes de una boda. Es una herramienta poderosa, s\u00ed; tambi\u00e9n limitada, sensible al contexto y peligrosamente f\u00e1cil de malinterpretar. La diferencia entre un informe \u00fatil y un ritual de n\u00fameros verdes est\u00e1 en saber leerlo.<\/p>\n<\/header>\n<article>\n<p>Hay una escena que se repite en agencias, departamentos de marketing y peque\u00f1os negocios con WordPress: alguien ejecuta Lighthouse, ve un 63 en rendimiento y el aire se espesa. Se acusa al hosting, al tema, al plugin de cookies, al dise\u00f1ador que \u201cpuso muchas im\u00e1genes\u201d, al becario que instal\u00f3 un carrusel en 2019 y quiz\u00e1, si la tarde viene dram\u00e1tica, a Google entero.<\/p>\n<p>Pero Lighthouse no dice simplemente \u201ctu web es lenta\u201d. Dice algo m\u00e1s interesante: <strong>en estas condiciones simuladas, esta p\u00e1gina se comport\u00f3 as\u00ed<\/strong>. Y esa frase, tan poco \u00e9pica, es el comienzo de cualquier diagn\u00f3stico serio.<\/p>\n<p>Interpretar Google Lighthouse exige mirar m\u00e1s all\u00e1 de la puntuaci\u00f3n. La nota global seduce porque es simple, redonda, casi escolar. Un 94 tranquiliza; un 48 averg\u00fcenza. Qu\u00e9 iron\u00eda tan moderna: pasamos a\u00f1os defendiendo que la experiencia de usuario es compleja y luego la reducimos a un sem\u00e1foro, como si un sitio web fuera una tostadora con Wi-Fi. \ud83d\udfe2\ud83d\udfe0\ud83d\udd34<\/p>\n<p>En esta gu\u00eda aprender\u00e1s a leer Lighthouse con criterio:<\/p>\n<ul>\n<li><a href=\"#que-es\">Qu\u00e9 mide Google Lighthouse y qu\u00e9 no mide<\/a><\/li>\n<li><a href=\"#score\">C\u00f3mo se calcula la puntuaci\u00f3n de rendimiento<\/a><\/li>\n<li><a href=\"#metricas\">C\u00f3mo interpretar FCP, LCP, Speed Index, TBT y CLS<\/a><\/li>\n<li><a href=\"#core-web-vitals\">Relaci\u00f3n entre Lighthouse y Core Web Vitals<\/a><\/li>\n<li><a href=\"#diagnostico\">C\u00f3mo convertir el informe en acciones concretas<\/a><\/li>\n<li><a href=\"#wordpress\">Recomendaciones espec\u00edficas para WordPress<\/a><\/li>\n<li><a href=\"#errores\">Errores comunes al usar Lighthouse<\/a><\/li>\n<\/ul>\n<section id=\"que-es\">\n<h2>Qu\u00e9 es Google Lighthouse y por qu\u00e9 no debe leerse como una sentencia<\/h2>\n<p><strong>Google Lighthouse<\/strong> es una herramienta automatizada de auditor\u00eda web creada por Google. Eval\u00faa p\u00e1ginas en varias categor\u00edas: rendimiento, accesibilidad, buenas pr\u00e1cticas, SEO y, seg\u00fan el contexto, PWA. Puede ejecutarse desde Chrome DevTools, PageSpeed Insights, la l\u00ednea de comandos, WebPageTest, extensiones o integraciones de CI\/CD.<\/p>\n<p>Su apartado de <strong>Performance<\/strong> analiza c\u00f3mo carga una p\u00e1gina bajo condiciones controladas. Lighthouse abre la URL, simula un dispositivo y una red determinados, observa el proceso de carga, captura m\u00e9tricas y propone oportunidades de mejora.<\/p>\n<p>Suena objetivo. Y lo es, hasta cierto punto. Pero conviene recordar algo: Lighthouse no vive en el bolsillo de tus usuarios. No sabe si una persona visita tu web desde un iPhone antiguo en el metro, desde fibra \u00f3ptica en Madrid, desde una cafeter\u00eda con una red que agoniza lentamente, o desde un m\u00f3vil Android de gama media saturado de aplicaciones. Lighthouse crea un laboratorio. El mundo real, por desgracia o por belleza, es una calle llena de ruido.<\/p>\n<p><strong>Idea clave:<\/strong> Lighthouse ofrece datos de laboratorio \u2014<em>lab data<\/em>\u2014. PageSpeed Insights, adem\u00e1s, puede mostrar datos reales de usuarios \u2014<em>field data<\/em>\u2014 procedentes del Chrome User Experience Report, si la URL o el origen tienen suficiente tr\u00e1fico registrado.<\/p>\n<h3>Datos de laboratorio frente a datos reales<\/h3>\n<table>\n<thead>\n<tr>\n<th>Tipo de dato<\/th>\n<th>De d\u00f3nde sale<\/th>\n<th>Qu\u00e9 aporta<\/th>\n<th>Limitaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Lab data<\/strong><\/td>\n<td>Lighthouse ejecutado en condiciones simuladas<\/td>\n<td>Diagn\u00f3stico reproducible, \u00fatil para depurar problemas t\u00e9cnicos<\/td>\n<td>No representa necesariamente a todos los usuarios reales<\/td>\n<\/tr>\n<tr>\n<td><strong>Field data<\/strong><\/td>\n<td>Chrome User Experience Report, usuarios reales de Chrome<\/td>\n<td>Refleja la experiencia agregada de visitantes reales<\/td>\n<td>Depende del volumen de datos y no siempre est\u00e1 disponible por URL<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Esta distinci\u00f3n es fundamental. Los datos de laboratorio son como probar un coche en una pista cerrada: controlas el viento, el asfalto y la velocidad. Los datos reales son conducir por una ciudad con obras, lluvia, peatones distra\u00eddos y un sem\u00e1foro que parece tener problemas filos\u00f3ficos. Ambos escenarios importan. Ninguno cuenta toda la historia por s\u00ed solo.<\/p>\n<\/section>\n<section id=\"score\">\n<h2>La puntuaci\u00f3n de rendimiento: \u00fatil, visible y un poco traicionera<\/h2>\n<p>La puntuaci\u00f3n de rendimiento de Lighthouse va de 0 a 100. En general:<\/p>\n<ul>\n<li><span>90 a 100<\/span>: buen rendimiento.<\/li>\n<li><span>50 a 89<\/span>: necesita mejoras.<\/li>\n<li><span>0 a 49<\/span>: rendimiento pobre.<\/li>\n<\/ul>\n<p>Ahora bien: esa puntuaci\u00f3n no es una media simple. Lighthouse calcula el resultado combinando varias m\u00e9tricas con pesos distintos. En versiones recientes, las m\u00e9tricas principales del score de rendimiento son:<\/p>\n<table>\n<thead>\n<tr>\n<th>M\u00e9trica<\/th>\n<th>Peso aproximado en Lighthouse<\/th>\n<th>Qu\u00e9 representa<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>First Contentful Paint, FCP<\/strong><\/td>\n<td>10%<\/td>\n<td>Cu\u00e1ndo aparece el primer contenido visible.<\/td>\n<\/tr>\n<tr>\n<td><strong>Speed Index<\/strong><\/td>\n<td>10%<\/td>\n<td>Qu\u00e9 tan r\u00e1pido se pinta visualmente el contenido principal.<\/td>\n<\/tr>\n<tr>\n<td><strong>Largest Contentful Paint, LCP<\/strong><\/td>\n<td>25%<\/td>\n<td>Cu\u00e1ndo se carga el elemento visible m\u00e1s grande.<\/td>\n<\/tr>\n<tr>\n<td><strong>Total Blocking Time, TBT<\/strong><\/td>\n<td>30%<\/td>\n<td>Cu\u00e1nto tiempo bloquea JavaScript la capacidad de respuesta.<\/td>\n<\/tr>\n<tr>\n<td><strong>Cumulative Layout Shift, CLS<\/strong><\/td>\n<td>25%<\/td>\n<td>Cu\u00e1nta inestabilidad visual ocurre durante la carga.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Los pesos pueden cambiar con nuevas versiones de Lighthouse, pero esta distribuci\u00f3n refleja el enfoque actual: experiencia visual, estabilidad e interactividad potencial.<\/p>\n<p>La tentaci\u00f3n es perseguir el 100 como quien persigue una medalla ol\u00edmpica. Pero el objetivo profesional no deber\u00eda ser \u201csacar 100\u201d, sino <strong>mejorar la experiencia real del usuario y el impacto de negocio<\/strong>. Una p\u00e1gina puede tener 100 y convertir mal. Otra puede tener 82 y vender magn\u00edficamente porque su propuesta es clara, su contenido es s\u00f3lido y sus formularios no parecen dise\u00f1ados por un enemigo.<\/p>\n<p>        El n\u00famero global es la portada del peri\u00f3dico; las m\u00e9tricas individuales son la investigaci\u00f3n. Si solo lees el titular, no te quejes de no entender el caso.<\/p>\n<\/section>\n<section id=\"metricas\">\n<h2>Las m\u00e9tricas principales de Lighthouse, explicadas sin niebla t\u00e9cnica<\/h2>\n<p>Cada m\u00e9trica cuenta un fragmento de la carga. Una mira cu\u00e1ndo aparece algo. Otra, cu\u00e1ndo aparece lo importante. Otra, si la p\u00e1gina se mueve como una mesa coja. Juntas componen una especie de electrocardiograma de la experiencia web. \ud83d\udcca<\/p>\n<h3>1. First Contentful Paint, FCP: el primer \u201caqu\u00ed estoy\u201d<\/h3>\n<p><strong>First Contentful Paint<\/strong> mide el tiempo que tarda el navegador en mostrar el primer contenido del DOM: texto, imagen, SVG o canvas no vac\u00edo. No significa que la p\u00e1gina est\u00e9 lista. Significa que el usuario ya no mira una pantalla blanca, ese peque\u00f1o desierto digital que tanto da\u00f1o hace a la paciencia.<\/p>\n<table>\n<thead>\n<tr>\n<th>Resultado FCP<\/th>\n<th>Interpretaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><span>Bueno: 0 a 1,8 s<\/span><\/td>\n<td>El usuario recibe una se\u00f1al temprana de vida.<\/td>\n<\/tr>\n<tr>\n<td><span>Mejorable: 1,8 a 3,0 s<\/span><\/td>\n<td>La p\u00e1gina tarda en empezar a comunicar.<\/td>\n<\/tr>\n<tr>\n<td><span>Pobre: m\u00e1s de 3,0 s<\/span><\/td>\n<td>La pantalla blanca puede generar abandono.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Problemas frecuentes que empeoran el FCP:<\/strong><\/p>\n<ul>\n<li>Servidor lento o alto <strong>Time to First Byte<\/strong>.<\/li>\n<li>CSS bloqueante demasiado pesado.<\/li>\n<li>Fuentes web mal cargadas.<\/li>\n<li>JavaScript cr\u00edtico ejecut\u00e1ndose antes de pintar contenido.<\/li>\n<li>Demasiados redireccionamientos iniciales.<\/li>\n<\/ul>\n<p><strong>C\u00f3mo mejorarlo:<\/strong> optimiza la respuesta del servidor, reduce CSS no utilizado, incrusta CSS cr\u00edtico cuando tenga sentido, usa cach\u00e9 de p\u00e1gina, revisa fuentes y elimina bloqueos innecesarios en el renderizado inicial.<\/p>\n<h3>2. Largest Contentful Paint, LCP: el momento en que aparece lo que importa<\/h3>\n<p><strong>Largest Contentful Paint<\/strong> mide cu\u00e1ndo se renderiza el elemento de contenido m\u00e1s grande visible en el viewport: una imagen hero, un bloque de texto, una imagen de producto, un banner principal. Es una m\u00e9trica crucial porque se aproxima a una pregunta sencilla: \u201c\u00bfcu\u00e1ndo siente el usuario que la p\u00e1gina principal ya carg\u00f3?\u201d<\/p>\n<p>El LCP suele ser el rey silencioso del rendimiento web. No hace ruido, pero decide si la visita empieza con confianza o con fastidio. Si tu imagen principal tarda cinco segundos, no tienes una portada: tienes una cortina pesada bajando lentamente en un teatro vac\u00edo.<\/p>\n<table>\n<thead>\n<tr>\n<th>Resultado LCP<\/th>\n<th>Interpretaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><span>Bueno: hasta 2,5 s<\/span><\/td>\n<td>El contenido principal aparece con rapidez.<\/td>\n<\/tr>\n<tr>\n<td><span>Mejorable: 2,5 a 4,0 s<\/span><\/td>\n<td>Hay fricci\u00f3n perceptible.<\/td>\n<\/tr>\n<tr>\n<td><span>Pobre: m\u00e1s de 4,0 s<\/span><\/td>\n<td>La experiencia inicial se deteriora seriamente.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Causas habituales de un mal LCP:<\/strong><\/p>\n<ul>\n<li>Imagen hero demasiado pesada o servida en dimensiones excesivas.<\/li>\n<li>Falta de formatos modernos como <strong>WebP<\/strong> o <strong>AVIF<\/strong>.<\/li>\n<li>El recurso LCP se carga tarde porque est\u00e1 detr\u00e1s de CSS, JavaScript o lazy loading mal aplicado.<\/li>\n<li>Tiempo de respuesta del servidor elevado.<\/li>\n<li>Uso de sliders, v\u00eddeos de fondo o constructores visuales con exceso de marcado.<\/li>\n<\/ul>\n<p><strong>Atenci\u00f3n:<\/strong> no apliques <code>loading=\"lazy\"<\/code> a la imagen principal si esa imagen es el LCP. Es una de esas optimizaciones que parecen sensatas y luego, con una sonrisa de cuchillo, arruinan la m\u00e9trica m\u00e1s importante de la p\u00e1gina.<\/p>\n<p><strong>Acciones recomendadas para mejorar LCP:<\/strong><\/p>\n<ul>\n<li>Identifica el elemento LCP en el informe de Lighthouse.<\/li>\n<li>Comprime y redimensiona la imagen principal al tama\u00f1o real de visualizaci\u00f3n.<\/li>\n<li>Usa <code>fetchpriority=\"high\"<\/code> en la imagen LCP cuando sea apropiado.<\/li>\n<li>Preload del recurso cr\u00edtico con <code>rel=\"preload\"<\/code>, especialmente si el navegador lo descubre tarde.<\/li>\n<li>Evita sliders en la parte superior salvo que sean realmente imprescindibles.<\/li>\n<li>Reduce el HTML, CSS y JavaScript que bloquean el primer render.<\/li>\n<li>Mejora hosting, cach\u00e9 y CDN si el servidor tarda demasiado en responder.<\/li>\n<\/ul>\n<h3>3. Speed Index: la velocidad visual, no la velocidad absoluta<\/h3>\n<p><strong>Speed Index<\/strong> mide qu\u00e9 tan r\u00e1pido se llena visualmente la pantalla durante la carga. No pregunta solo \u201ccu\u00e1ndo termin\u00f3\u201d, sino \u201cc\u00f3mo se sinti\u00f3 el camino\u201d. Dos p\u00e1ginas pueden finalizar en tiempos similares, pero una mostrar contenido progresivamente y otra permanecer vac\u00eda para luego aparecer de golpe. La primera se siente \u00e1gil; la segunda, sospechosa.<\/p>\n<table>\n<thead>\n<tr>\n<th>Resultado Speed Index<\/th>\n<th>Interpretaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><span>Bueno: hasta 3,4 s<\/span><\/td>\n<td>El contenido visual aparece con fluidez.<\/td>\n<\/tr>\n<tr>\n<td><span>Mejorable: 3,4 a 5,8 s<\/span><\/td>\n<td>La carga visual se siente lenta.<\/td>\n<\/tr>\n<tr>\n<td><span>Pobre: m\u00e1s de 5,8 s<\/span><\/td>\n<td>La p\u00e1gina parece congelada o torpe.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Para mejorar Speed Index suelen funcionar las mismas medidas que mejoran FCP y LCP: reducir recursos bloqueantes, priorizar contenido visible, optimizar im\u00e1genes y simplificar la parte superior de la p\u00e1gina. Menos teatro antes de abrir el tel\u00f3n.<\/p>\n<h3>4. Total Blocking Time, TBT: cuando JavaScript secuestra la p\u00e1gina<\/h3>\n<p><strong>Total Blocking Time<\/strong> mide el tiempo total en el que el hilo principal del navegador queda bloqueado por tareas largas entre el FCP y el momento en que la p\u00e1gina se vuelve razonablemente interactiva. Una tarea larga es aquella que supera los 50 milisegundos; el exceso sobre esos 50 ms se suma al TBT.<\/p>\n<p>Traducido: TBT revela cu\u00e1nto tiempo el navegador est\u00e1 tan ocupado ejecutando JavaScript que no puede atender bien al usuario. El visitante toca un bot\u00f3n y nada. Toca otra vez. Frunce el ce\u00f1o. El sitio, mientras tanto, calcula, hidrata, etiqueta, rastrea, personaliza y carga tres scripts de marketing para descubrir que el usuario ya se fue. Maravillas del progreso. \ud83e\udde0<\/p>\n<table>\n<thead>\n<tr>\n<th>Resultado TBT<\/th>\n<th>Interpretaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><span>Bueno: hasta 200 ms<\/span><\/td>\n<td>La p\u00e1gina mantiene buena capacidad de respuesta inicial.<\/td>\n<\/tr>\n<tr>\n<td><span>Mejorable: 200 a 600 ms<\/span><\/td>\n<td>Puede haber retrasos perceptibles.<\/td>\n<\/tr>\n<tr>\n<td><span>Pobre: m\u00e1s de 600 ms<\/span><\/td>\n<td>JavaScript est\u00e1 bloqueando de forma grave.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Causas t\u00edpicas de TBT alto:<\/strong><\/p>\n<ul>\n<li>Demasiado JavaScript de frameworks, constructores visuales o plugins.<\/li>\n<li>Scripts de terceros: anal\u00edtica, mapas, chat, p\u00edxeles, A\/B testing, widgets sociales.<\/li>\n<li>Bundles sin dividir, enviados completos aunque la p\u00e1gina use solo una parte.<\/li>\n<li>Hidrataci\u00f3n pesada en aplicaciones JavaScript.<\/li>\n<li>Plugins de WordPress que cargan assets en todas las p\u00e1ginas aunque solo se usen en una.<\/li>\n<\/ul>\n<p><strong>C\u00f3mo reducir TBT:<\/strong><\/p>\n<ul>\n<li>Elimina JavaScript no utilizado.<\/li>\n<li>Retrasa scripts no cr\u00edticos con <code>defer<\/code> o carga bajo interacci\u00f3n.<\/li>\n<li>Divide bundles y aplica code splitting.<\/li>\n<li>Evita cargar formularios, mapas o chats hasta que el usuario los necesite.<\/li>\n<li>Revisa scripts de terceros con esp\u00edritu de auditor financiero, no de coleccionista.<\/li>\n<li>Usa Web Workers para tareas pesadas cuando sea viable.<\/li>\n<\/ul>\n<h3>5. Cumulative Layout Shift, CLS: el suelo que se mueve bajo los pies<\/h3>\n<p><strong>Cumulative Layout Shift<\/strong> mide la inestabilidad visual inesperada. Es decir, cu\u00e1nto se mueven los elementos mientras el usuario intenta leer o interactuar. Nada irrita m\u00e1s que ir a pulsar \u201cComprar\u201d y terminar pulsando \u201cCancelar\u201d porque apareci\u00f3 un banner tard\u00edo, como un fantasma con ambiciones comerciales.<\/p>\n<table>\n<thead>\n<tr>\n<th>Resultado CLS<\/th>\n<th>Interpretaci\u00f3n<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><span>Bueno: hasta 0,1<\/span><\/td>\n<td>La p\u00e1gina es visualmente estable.<\/td>\n<\/tr>\n<tr>\n<td><span>Mejorable: 0,1 a 0,25<\/span><\/td>\n<td>Hay movimientos que pueden molestar.<\/td>\n<\/tr>\n<tr>\n<td><span>Pobre: m\u00e1s de 0,25<\/span><\/td>\n<td>La inestabilidad afecta claramente la experiencia.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><strong>Causas comunes de CLS elevado:<\/strong><\/p>\n<ul>\n<li>Im\u00e1genes sin atributos <code>width<\/code> y <code>height<\/code>.<\/li>\n<li>Anuncios, iframes o embeds sin espacio reservado.<\/li>\n<li>Banners de cookies que empujan contenido.<\/li>\n<li>Fuentes web que cambian el tama\u00f1o del texto al cargar.<\/li>\n<li>Contenido din\u00e1mico insertado por encima del contenido existente.<\/li>\n<\/ul>\n<p><strong>C\u00f3mo corregir CLS:<\/strong><\/p>\n<ul>\n<li>Define dimensiones o relaci\u00f3n de aspecto para im\u00e1genes y v\u00eddeos.<\/li>\n<li>Reserva espacio para anuncios, iframes y componentes externos.<\/li>\n<li>Evita insertar contenido encima de lo ya visible salvo por acci\u00f3n del usuario.<\/li>\n<li>Usa estrategias de carga de fuentes con <code>font-display<\/code> y m\u00e9tricas compatibles.<\/li>\n<li>Dise\u00f1a banners de cookies como overlays o bloques con espacio previsto.<\/li>\n<\/ul>\n<\/section>\n<section id=\"core-web-vitals\">\n<h2>Lighthouse y Core Web Vitals: primos cercanos, no gemelos<\/h2>\n<p>Los <strong>Core Web Vitals<\/strong> son m\u00e9tricas de experiencia de usuario que Google considera especialmente relevantes para la calidad de una p\u00e1gina. Actualmente se centran en tres dimensiones:<\/p>\n<h3>LCP \u26a1<\/h3>\n<p><strong>Carga percibida.<\/strong> Debe estar en 2,5 segundos o menos para considerarse bueno.<\/p>\n<h3>INP \ud83d\uddb1\ufe0f<\/h3>\n<p><strong>Interactividad real.<\/strong> Debe estar en 200 milisegundos o menos. INP reemplaz\u00f3 a FID como Core Web Vital en marzo de 2024.<\/p>\n<h3>CLS \ud83e\uddf1<\/h3>\n<p><strong>Estabilidad visual.<\/strong> Debe ser 0,1 o menos.<\/p>\n<p>Aqu\u00ed conviene hilar fino: Lighthouse mide <strong>LCP<\/strong> y <strong>CLS<\/strong> en laboratorio, pero no puede medir <strong>INP<\/strong> como lo hacen los datos reales, porque INP depende de interacciones de usuarios aut\u00e9nticos a lo largo de la vida de la p\u00e1gina. Lighthouse usa <strong>TBT<\/strong> como una m\u00e9trica de laboratorio relacionada: si tienes TBT alto, es probable que la interactividad real sufra, aunque no sea una equivalencia perfecta.<\/p>\n<p><strong>Lectura profesional:<\/strong> usa Lighthouse para encontrar causas t\u00e9cnicas y usa PageSpeed Insights, Search Console o datos RUM para confirmar c\u00f3mo lo viven los usuarios reales. Es la diferencia entre mirar una radiograf\u00eda y preguntarle al paciente d\u00f3nde le duele.<\/p>\n<h3>\u00bfAfectan estas m\u00e9tricas al SEO?<\/h3>\n<p>S\u00ed, pero con matices. Google ha indicado que la experiencia de p\u00e1gina, incluidos los Core Web Vitals, forma parte de sus sistemas de evaluaci\u00f3n, aunque no suele pesar m\u00e1s que la relevancia, la calidad del contenido, la autoridad tem\u00e1tica y la satisfacci\u00f3n de la intenci\u00f3n de b\u00fasqueda. Un sitio r\u00e1pido con contenido mediocre no se convierte m\u00e1gicamente en referencia. Un sitio magn\u00edfico pero desesperadamente lento tampoco se ayuda a s\u00ed mismo.<\/p>\n<p>La ant\u00edtesis es clara: <strong>velocidad sin valor es una autopista hacia ninguna parte; valor sin velocidad es una biblioteca con la puerta atascada<\/strong>.<\/p>\n<\/section>\n<section id=\"diagnostico\">\n<h2>C\u00f3mo leer un informe Lighthouse paso a paso<\/h2>\n<p>Un informe de Lighthouse puede parecer una feria de advertencias: m\u00e9tricas, oportunidades, diagn\u00f3sticos, capturas, recursos, \u00e1rboles de dependencias. Respira. No todo pesa igual. No todo merece una semana de trabajo. Y no todo lo que Lighthouse sugiere conviene aplicarlo sin juicio.<\/p>\n<h3>Paso 1: mira primero la pel\u00edcula, no el cartel<\/h3>\n<p>Antes de obsesionarte con el score, revisa la tira visual o <em>filmstrip<\/em>. Observa cu\u00e1ndo aparece el primer contenido, cu\u00e1ndo llega el contenido principal y si hay saltos visuales. A veces una captura cuenta m\u00e1s que tres tablas.<\/p>\n<p>Preg\u00fantate:<\/p>\n<ul>\n<li>\u00bfLa pantalla permanece blanca demasiado tiempo?<\/li>\n<li>\u00bfEl contenido principal aparece tarde?<\/li>\n<li>\u00bfSe cargan elementos irrelevantes antes que lo importante?<\/li>\n<li>\u00bfHay movimientos visuales bruscos?<\/li>\n<\/ul>\n<h3>Paso 2: identifica la m\u00e9trica que m\u00e1s est\u00e1 da\u00f1ando el score<\/h3>\n<p>No intentes arreglar todo a la vez. Si el problema principal es LCP, no empieces por minificar un archivo CSS que ahorra 2 KB. Si el TBT est\u00e1 disparado, mirar solo im\u00e1genes ser\u00e1 como barrer la playa durante una tormenta.<\/p>\n<table>\n<thead>\n<tr>\n<th>Si falla principalmente&#8230;<\/th>\n<th>Mira primero&#8230;<\/th>\n<th>Acciones probables<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>FCP<\/strong><\/td>\n<td>Servidor, CSS bloqueante, fuentes, redirecciones<\/td>\n<td>Cach\u00e9, optimizaci\u00f3n de CSS cr\u00edtico, mejora de TTFB, reducci\u00f3n de recursos iniciales<\/td>\n<\/tr>\n<tr>\n<td><strong>LCP<\/strong><\/td>\n<td>Elemento LCP, imagen hero, preload, prioridad de recursos<\/td>\n<td>Optimizar imagen principal, priorizar carga, eliminar sliders pesados, mejorar respuesta del servidor<\/td>\n<\/tr>\n<tr>\n<td><strong>TBT<\/strong><\/td>\n<td>JavaScript, tareas largas, scripts externos<\/td>\n<td>Reducir JS, diferir scripts, eliminar plugins, cargar terceros bajo demanda<\/td>\n<\/tr>\n<tr>\n<td><strong>CLS<\/strong><\/td>\n<td>Im\u00e1genes sin dimensiones, banners, anuncios, fuentes<\/td>\n<td>Reservar espacio, definir tama\u00f1os, estabilizar banners, ajustar carga de fuentes<\/td>\n<\/tr>\n<tr>\n<td><strong>Speed Index<\/strong><\/td>\n<td>Renderizado progresivo, recursos visibles, bloqueo inicial<\/td>\n<td>Priorizar above the fold, reducir CSS\/JS bloqueante, optimizar im\u00e1genes iniciales<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3>Paso 3: distingue \u201cOpportunities\u201d de \u201cDiagnostics\u201d<\/h3>\n<p>En Lighthouse, las <strong>Opportunities<\/strong> sugieren mejoras que podr\u00edan reducir tiempos de carga: eliminar recursos que bloquean renderizado, reducir JavaScript no usado, servir im\u00e1genes en formatos modernos, etc. Los <strong>Diagnostics<\/strong> dan informaci\u00f3n adicional sobre el comportamiento de la p\u00e1gina.<\/p>\n<p>No todas las oportunidades tienen el mismo impacto. Lighthouse puede decirte que ahorres 15 KiB en un recurso mientras tu imagen principal pesa 1,8 MB. T\u00e9cnicamente tiene raz\u00f3n; estrat\u00e9gicamente, ser\u00eda como recomendar cambiar las servilletas mientras la cocina arde.<\/p>\n<h3>Paso 4: revisa el \u00e1rbol de recursos y los terceros<\/h3>\n<p>Muchos sitios no son lentos por su contenido, sino por su s\u00e9quito: p\u00edxeles publicitarios, scripts de remarketing, mapas, chats, reproductores, herramientas de grabaci\u00f3n de sesi\u00f3n, pop-ups, etiquetas duplicadas. Cada una promete inteligencia. Juntas, a veces, producen torpeza.<\/p>\n<p>Haz inventario:<\/p>\n<ul>\n<li>\u00bfQu\u00e9 scripts externos se cargan?<\/li>\n<li>\u00bfSon imprescindibles en todas las p\u00e1ginas?<\/li>\n<li>\u00bfHay etiquetas duplicadas en Google Tag Manager?<\/li>\n<li>\u00bfSe puede cargar el chat solo tras clic o tras unos segundos?<\/li>\n<li>\u00bfEl mapa debe cargarse como iframe inicial o basta una imagen est\u00e1tica con enlace?<\/li>\n<\/ul>\n<h3>Paso 5: repite la prueba varias veces<\/h3>\n<p>Un solo test no basta. Lighthouse puede variar por procesos del sistema, red, cach\u00e9s, extensiones, temperatura de la CPU o peque\u00f1as diferencias de ejecuci\u00f3n. Lo sensato es ejecutar varias pruebas y observar patrones, no accidentes.<\/p>\n<p><strong>Buenas pr\u00e1cticas de medici\u00f3n:<\/strong> ejecuta Lighthouse en modo inc\u00f3gnito, desactiva extensiones, prueba varias veces, compara siempre la misma URL y documenta cambios. Si trabajas en equipo, automatiza pruebas con Lighthouse CI para evitar discusiones basadas en capturas sueltas.<\/p>\n<\/section>\n<section id=\"wordpress\">\n<h2>Interpretar Lighthouse en WordPress: donde los plugins tienen biograf\u00eda propia<\/h2>\n<p>WordPress puede ser r\u00e1pido, muy r\u00e1pido. Tambi\u00e9n puede convertirse en una carreta cargada de adornos, dependiendo del hosting, el tema, los plugins y los h\u00e1bitos de mantenimiento. No es justo culpar al CMS por todo; tampoco es prudente absolverlo sin revisar la escena del crimen.<\/p>\n<h3>Problemas t\u00edpicos en sitios WordPress<\/h3>\n<ul>\n<li><strong>Temas multiprop\u00f3sito demasiado pesados:<\/strong> cargan estilos y scripts para funciones que la p\u00e1gina no usa.<\/li>\n<li><strong>Constructores visuales abusados:<\/strong> \u00fatiles, s\u00ed, pero capaces de generar DOM excesivo y CSS voluminoso.<\/li>\n<li><strong>Plugins redundantes:<\/strong> tres plugins haciendo cach\u00e9, dos optimizando im\u00e1genes, cuatro insertando scripts. La eficiencia, naturalmente, llorando en una esquina.<\/li>\n<li><strong>WooCommerce sin optimizaci\u00f3n:<\/strong> fragmentos de carrito, scripts globales y consultas pesadas en p\u00e1ginas no comerciales.<\/li>\n<li><strong>Fuentes e iconos cargados en exceso:<\/strong> familias completas cuando solo se usan dos pesos.<\/li>\n<li><strong>Base de datos descuidada:<\/strong> transients acumulados, revisiones infinitas, tablas hu\u00e9rfanas.<\/li>\n<\/ul>\n<h3>Acciones recomendadas para WordPress<\/h3>\n<h3>Cach\u00e9 de p\u00e1gina \ud83d\ude80<\/h3>\n<p>Activa cach\u00e9 a nivel de servidor o mediante un plugin fiable. En hosting administrado, suele ser mejor usar la cach\u00e9 nativa antes que apilar soluciones.<\/p>\n<h3>Optimizaci\u00f3n de im\u00e1genes \ud83d\uddbc\ufe0f<\/h3>\n<p>Usa WebP o AVIF, dimensiona correctamente, comprime sin destruir calidad y evita lazy loading en la imagen LCP.<\/p>\n<h3>Control de assets \ud83c\udf9b\ufe0f<\/h3>\n<p>Desactiva CSS y JavaScript por p\u00e1gina cuando no sean necesarios. Herramientas de gesti\u00f3n de assets pueden ayudar, con cuidado.<\/p>\n<h3>Fuentes locales \ud83d\udd24<\/h3>\n<p>Alojar fuentes localmente y cargar solo pesos necesarios puede reducir latencia y mejorar estabilidad visual.<\/p>\n<h3>CDN \ud83c\udf0d<\/h3>\n<p>Un CDN ayuda especialmente en sitios internacionales, recursos est\u00e1ticos pesados y picos de tr\u00e1fico.<\/p>\n<h3>Mantenimiento \ud83d\udee0\ufe0f<\/h3>\n<p>Actualiza n\u00facleo, tema y plugins; elimina lo que no uses; revisa seguridad y rendimiento como parte del mismo oficio.<\/p>\n<h3>Plugins de optimizaci\u00f3n: ni santos ni demonios<\/h3>\n<p>Plugins como WP Rocket, LiteSpeed Cache, Autoptimize, Perfmatters, FlyingPress, ShortPixel, Imagify o EWWW Image Optimizer pueden ayudar mucho. Pero no son conjuros. Mal configurados, rompen dise\u00f1os, retrasan scripts esenciales o esconden el problema bajo una alfombra muy bien minificada.<\/p>\n<p>La regla pr\u00e1ctica: activa una optimizaci\u00f3n, mide, verifica visualmente, prueba formularios, carrito, men\u00fas, buscador y eventos importantes. Despu\u00e9s contin\u00faa. La optimizaci\u00f3n profesional es cirug\u00eda, no jardiner\u00eda con motosierra.<\/p>\n<p><strong>Cuidado con combinar optimizadores:<\/strong> usar varios plugins que minifican, combinan, retrasan y cachean lo mismo puede producir conflictos dif\u00edciles de rastrear. M\u00e1s herramientas no siempre significan m\u00e1s velocidad; a veces solo significan m\u00e1s sospechosos.<\/p>\n<\/section>\n<section id=\"prioridades\">\n<h2>C\u00f3mo priorizar mejoras sin perderse en el informe<\/h2>\n<p>Una auditor\u00eda de rendimiento web debe terminar en un plan. No en una lista infinita. No en un PDF ornamental. Un plan.<\/p>\n<p>Prioriza con esta f\u00f3rmula sencilla:<\/p>\n<ol>\n<li><strong>Impacto en usuarios:<\/strong> \u00bfafecta a la carga inicial, compra, contacto o lectura?<\/li>\n<li><strong>Impacto en m\u00e9tricas:<\/strong> \u00bfmejora LCP, CLS, TBT o INP real?<\/li>\n<li><strong>Esfuerzo t\u00e9cnico:<\/strong> \u00bfrequiere minutos, horas o redise\u00f1ar media arquitectura?<\/li>\n<li><strong>Riesgo:<\/strong> \u00bfpuede romper checkout, formularios, anal\u00edtica o dise\u00f1o?<\/li>\n<\/ol>\n<h3>Plan de acci\u00f3n recomendado<\/h3>\n<table>\n<thead>\n<tr>\n<th>Prioridad<\/th>\n<th>Acci\u00f3n<\/th>\n<th>Por qu\u00e9 importa<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Alta<\/strong><\/td>\n<td>Optimizar imagen o elemento LCP<\/td>\n<td>Suele mejorar de forma visible la percepci\u00f3n de velocidad.<\/td>\n<\/tr>\n<tr>\n<td><strong>Alta<\/strong><\/td>\n<td>Reducir JavaScript bloqueante<\/td>\n<td>Mejora TBT y puede beneficiar la interactividad real.<\/td>\n<\/tr>\n<tr>\n<td><strong>Alta<\/strong><\/td>\n<td>Corregir CLS<\/td>\n<td>Evita frustraci\u00f3n, clics err\u00f3neos y sensaci\u00f3n de baja calidad.<\/td>\n<\/tr>\n<tr>\n<td><strong>Media<\/strong><\/td>\n<td>Optimizar fuentes<\/td>\n<td>Reduce bloqueos, cambios visuales y solicitudes externas.<\/td>\n<\/tr>\n<tr>\n<td><strong>Media<\/strong><\/td>\n<td>Revisar scripts de terceros<\/td>\n<td>Puede recortar carga y bloqueo sin tocar el contenido.<\/td>\n<\/tr>\n<tr>\n<td><strong>Variable<\/strong><\/td>\n<td>Minificar HTML, CSS y JS<\/td>\n<td>\u00datil, pero normalmente menos decisivo que eliminar peso innecesario.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Un comentario casi dom\u00e9stico: hace a\u00f1os, arreglando una web de una peque\u00f1a tienda, descubrimos que el mayor bloqueo no era WooCommerce, ni el tema, ni el hosting. Era un widget meteorol\u00f3gico incrustado en el footer. Nadie sab\u00eda qui\u00e9n lo hab\u00eda puesto. Nadie lo miraba. Nadie lo quer\u00eda. Pero all\u00ed estaba, ralentizando la tienda con una dignidad absurda, informando del clima a usuarios que solo quer\u00edan comprar caf\u00e9. Desde entonces miro los footers como quien revisa un desv\u00e1n familiar.<\/p>\n<\/section>\n<section id=\"errores\">\n<h2>Errores comunes al interpretar Google Lighthouse<\/h2>\n<h3>Obsesionarse con el 100<\/h3>\n<p>Un 100 puede ser excelente, pero no siempre es rentable perseguirlo. Pasar de 42 a 78 suele transformar la experiencia. Pasar de 96 a 100 quiz\u00e1 consuma horas valiosas para una mejora imperceptible. El perfeccionismo t\u00e9cnico, cuando olvida al usuario, se vuelve decoraci\u00f3n.<\/p>\n<h3>Medir solo la home<\/h3>\n<p>La p\u00e1gina de inicio no representa todo el sitio. Audita tambi\u00e9n plantillas de producto, categor\u00edas, art\u00edculos, landing pages, checkout, p\u00e1ginas con formularios y URLs con tr\u00e1fico org\u00e1nico relevante. En SEO t\u00e9cnico, la media enga\u00f1a; las plantillas revelan.<\/p>\n<h3>Ignorar m\u00f3viles<\/h3>\n<p>La prueba m\u00f3vil suele ser m\u00e1s exigente porque simula menos capacidad de CPU y red m\u00e1s limitada. Si solo miras escritorio, est\u00e1s escuchando la versi\u00f3n c\u00f3moda de la historia. El m\u00f3vil, con sus limitaciones, suele decir la verdad con menos modales.<\/p>\n<h3>Comparar informes bajo condiciones distintas<\/h3>\n<p>No compares una prueba hecha en DevTools local con otra de PageSpeed Insights como si fueran id\u00e9nticas. Cambian entorno, ubicaci\u00f3n, throttling, cach\u00e9 y versi\u00f3n. Para comparar mejoras, controla las condiciones tanto como puedas.<\/p>\n<h3>Aplicar recomendaciones sin probar efectos secundarios<\/h3>\n<p>Diferir JavaScript puede romper men\u00fas. Combinar CSS puede alterar estilos. Retrasar scripts puede afectar anal\u00edtica. Optimizar im\u00e1genes de forma agresiva puede destruir la est\u00e9tica de una marca. La velocidad no justifica una web rota; una web rota carga rapid\u00edsimo porque nadie la usa.<\/p>\n<ul>\n<li>No elimines scripts sin saber para qu\u00e9 sirven.<\/li>\n<li>No apliques lazy loading a todo por sistema.<\/li>\n<li>No cargues fuentes externas sin revisar pesos y variantes.<\/li>\n<li>No instales cinco plugins de optimizaci\u00f3n esperando que se organicen civilizadamente.<\/li>\n<li>No olvides medir despu\u00e9s de cada cambio.<\/li>\n<\/ul>\n<\/section>\n<section id=\"herramientas\">\n<h2>Herramientas complementarias para una lectura m\u00e1s completa<\/h2>\n<p>Lighthouse es excelente, pero no deber\u00eda trabajar solo. Una auditor\u00eda madura cruza varias fuentes, como un historiador que no se f\u00eda de una sola cr\u00f3nica.<\/p>\n<table>\n<thead>\n<tr>\n<th>Herramienta<\/th>\n<th>Uso recomendado<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>PageSpeed Insights<\/strong><\/td>\n<td>Combinar Lighthouse con datos reales de CrUX cuando est\u00e9n disponibles.<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Search Console<\/strong><\/td>\n<td>Revisar Core Web Vitals por grupos de URLs y detectar problemas SEO relacionados.<\/td>\n<\/tr>\n<tr>\n<td><strong>Chrome DevTools Performance<\/strong><\/td>\n<td>Analizar tareas largas, main thread, renderizado y ejecuci\u00f3n JavaScript con detalle.<\/td>\n<\/tr>\n<tr>\n<td><strong>WebPageTest<\/strong><\/td>\n<td>Probar ubicaciones, dispositivos, conexiones, waterfall y v\u00eddeo de carga con m\u00e1s control.<\/td>\n<\/tr>\n<tr>\n<td><strong>CrUX Dashboard<\/strong><\/td>\n<td>Visualizar experiencia real agregada por origen si hay datos suficientes.<\/td>\n<\/tr>\n<tr>\n<td><strong>RUM propio<\/strong><\/td>\n<td>Medir usuarios reales mediante herramientas como SpeedCurve, DebugBear, New Relic, Datadog o soluciones internas.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Si tu sitio tiene tr\u00e1fico y genera ingresos, considera implementar <strong>Real User Monitoring<\/strong>. No es lujo: es escuchar a la audiencia en vez de adivinar desde bambalinas.<\/p>\n<\/section>\n<section id=\"checklist\">\n<h2>Checklist profesional para interpretar Lighthouse<\/h2>\n<ul>\n<li>Ejecuta varias pruebas y evita sacar decisiones de una sola medici\u00f3n.<\/li>\n<li>Diferencia datos de laboratorio y datos reales.<\/li>\n<li>Analiza primero LCP, TBT y CLS por su peso e impacto.<\/li>\n<li>Identifica el elemento LCP exacto y su ruta de carga.<\/li>\n<li>Revisa si hay im\u00e1genes cr\u00edticas con lazy loading indebido.<\/li>\n<li>Busca JavaScript no utilizado y tareas largas en el hilo principal.<\/li>\n<li>Audita scripts de terceros con criterios de negocio.<\/li>\n<li>Comprueba dimensiones reservadas para im\u00e1genes, iframes y anuncios.<\/li>\n<li>Mide p\u00e1ginas representativas, no solo la portada.<\/li>\n<li>Documenta cada cambio y vuelve a medir.<\/li>\n<li>Valida visualmente la web despu\u00e9s de optimizar.<\/li>\n<li>Contrasta Lighthouse con Search Console, PageSpeed Insights y datos reales.<\/li>\n<\/ul>\n<\/section>\n<section id=\"cierre\">\n<h2>Leer Lighthouse como profesional: menos superstici\u00f3n, m\u00e1s criterio<\/h2>\n<p>Google Lighthouse no es un juez definitivo ni un adorno para informes. Es una linterna. Ilumina zonas oscuras: im\u00e1genes enormes, JavaScript excesivo, fuentes caprichosas, servidores lentos, dise\u00f1os inestables. Pero una linterna no camina por ti.<\/p>\n<p>La buena interpretaci\u00f3n exige t\u00e9cnica, paciencia y cierta desconfianza saludable. Hay que mirar la m\u00e9trica, s\u00ed, pero tambi\u00e9n la p\u00e1gina. Hay que atender al n\u00famero, pero preguntarse qu\u00e9 siente el usuario. Hay que mejorar el rendimiento sin sacrificar contenido, accesibilidad, conversi\u00f3n o mantenimiento. Ese equilibrio \u2014tan poco espectacular y tan dif\u00edcil\u2014 separa la optimizaci\u00f3n seria del maquillaje digital.<\/p>\n<p>En una web profesional, la velocidad no es vanidad. Es cortes\u00eda. Es respeto por el tiempo ajeno. Es seguridad percibida, confianza comercial y eficiencia t\u00e9cnica. Una p\u00e1gina r\u00e1pida no grita; simplemente abre la puerta antes de que el visitante piense en marcharse. Y en Internet, ese instante puede serlo todo. \u26a1<\/p>\n<\/section>\n<footer>\n<p><strong>Resumen pr\u00e1ctico:<\/strong> no persigas solo un n\u00famero verde. Usa Google Lighthouse para detectar cuellos de botella, prioriza LCP, TBT y CLS, contrasta con datos reales de Core Web Vitals y aplica mejoras medibles. La mejor optimizaci\u00f3n no es la m\u00e1s vistosa, sino la que tus usuarios notan sin tener que nombrarla.<\/p>\n<\/footer>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>Rendimiento web, SEO t\u00e9cnico y experiencia de usuario \u26a1 C\u00f3mo interpretar las m\u00e9tricas de rendimiento<\/p>\n","protected":false},"author":1,"featured_media":3878,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[2],"tags":[],"class_list":["post-3879","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mantenimiento"],"_links":{"self":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3879","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/comments?post=3879"}],"version-history":[{"count":1,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3879\/revisions"}],"predecessor-version":[{"id":3880,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3879\/revisions\/3880"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media\/3878"}],"wp:attachment":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media?parent=3879"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/categories?post=3879"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/tags?post=3879"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}