{"id":3736,"date":"2026-07-31T11:43:14","date_gmt":"2026-07-31T09:43:14","guid":{"rendered":"https:\/\/mantenimientoweb.pro\/blog\/como-optimizar-el-codigo-html-css-y-js-para-alcanzar-un-100-100-en-google-pagespeed\/"},"modified":"2026-07-31T11:43:16","modified_gmt":"2026-07-31T09:43:16","slug":"como-optimizar-el-codigo-html-css-y-js-para-alcanzar-un-100-100-en-google-pagespeed","status":"publish","type":"post","link":"https:\/\/mantenimientoweb.pro\/blog\/como-optimizar-el-codigo-html-css-y-js-para-alcanzar-un-100-100-en-google-pagespeed\/","title":{"rendered":"\u00bfC\u00f3mo optimizar el c\u00f3digo HTML, CSS y JS para alcanzar un 100\/100 en Google PageSpeed?"},"content":{"rendered":"
\n

\u00bfC\u00f3mo optimizar el c\u00f3digo HTML, CSS y JS para alcanzar un 100\/100 en Google PageSpeed? \u26a1<\/p>\n

Hay p\u00e1ginas que pesan como una biblioteca mud\u00e1ndose en cami\u00f3n y aun as\u00ed sus due\u00f1os se preguntan, con sincera inocencia, por qu\u00e9 Google PageSpeed Insights les devuelve un 43 en m\u00f3vil. El rendimiento web no es magia negra: es arquitectura, poda, criterio y una pizca de humildad t\u00e9cnica. Alcanzar un 100\/100 en Google PageSpeed<\/strong> es posible en muchos casos, pero exige entender qu\u00e9 se mide, qu\u00e9 estorba y qu\u00e9 decisiones conviene tomar antes de instalar \u201cun plugin m\u00e1s\u201d, ese ritual moderno que a veces cura y a veces agrava la fiebre.<\/p>\n

Optimizar HTML, CSS y JavaScript no consiste solo en minificar archivos. Eso ser\u00eda como limpiar el parabrisas de un coche sin motor. La verdadera mejora aparece cuando el navegador recibe menos trabajo, en el orden correcto y con menos interrupciones. Un sitio r\u00e1pido no grita; respira. Carga lo esencial, difiere lo accesorio y no obliga al usuario a esperar mientras media docena de scripts de seguimiento discuten entre ellos en la sala de m\u00e1quinas.<\/p>\n

Contenido de esta gu\u00eda<\/strong><\/p>\n

    \n
  1. Qu\u00e9 mide realmente Google PageSpeed Insights<\/a><\/li>\n
  2. Diagn\u00f3stico profesional antes de tocar c\u00f3digo<\/a><\/li>\n
  3. Optimizaci\u00f3n avanzada de HTML<\/a><\/li>\n
  4. Optimizaci\u00f3n de CSS: critical CSS, CSS no usado y renderizado<\/a><\/li>\n
  5. Optimizaci\u00f3n de JavaScript: menos bloqueo, m\u00e1s intenci\u00f3n<\/a><\/li>\n
  6. Caso WordPress: c\u00f3mo evitar que el CMS se convierta en lastre<\/a><\/li>\n
  7. Core Web Vitals y m\u00e9tricas clave<\/a><\/li>\n
  8. Checklist final para acercarte al 100\/100<\/a><\/li>\n<\/ol>\n

    Qu\u00e9 mide realmente Google PageSpeed Insights \ud83d\udd0d<\/h2>\n

    Antes de perseguir el famoso n\u00famero verde, conviene mirar el term\u00f3metro. Google PageSpeed Insights<\/strong> combina datos de laboratorio obtenidos mediante Lighthouse con, cuando existen, datos de campo procedentes del Chrome User Experience Report, conocido como CrUX. Es decir: una cosa es c\u00f3mo se comporta tu p\u00e1gina en una simulaci\u00f3n controlada y otra, m\u00e1s inc\u00f3moda y real, c\u00f3mo la sufren o disfrutan los usuarios con m\u00f3viles modestos, redes irregulares y navegadores cargados de vida.<\/p>\n

    La puntuaci\u00f3n de Lighthouse se calcula principalmente con m\u00e9tricas de rendimiento. Estas han cambiado con el tiempo, y precisamente ah\u00ed reside una paradoja interesante: el 100\/100 de ayer puede no ser el 100\/100 de ma\u00f1ana. La web avanza como una marea; quien optimiza solo para pasar un test termina construyendo castillos en la arena.<\/p>\n\n\n\n\n\n\n\n\n\n\n
    M\u00e9trica<\/th>\nQu\u00e9 eval\u00faa<\/th>\nPor qu\u00e9 afecta al usuario<\/th>\n<\/tr>\n<\/thead>\n
    LCP<\/strong> (Largest Contentful Paint)<\/span><\/td>\nTiempo hasta que se renderiza el elemento principal visible: una imagen hero, un bloque de texto grande o un banner.<\/td>\nDefine cu\u00e1ndo la p\u00e1gina \u201cparece\u201d \u00fatil. Si tarda, el usuario siente que est\u00e1 esperando frente a una puerta cerrada.<\/td>\n<\/tr>\n
    INP<\/strong> (Interaction to Next Paint)<\/span><\/td>\nCapacidad de respuesta ante interacciones del usuario.<\/td>\nUn bot\u00f3n que tarda en reaccionar transmite torpeza, aunque el dise\u00f1o sea impecable.<\/td>\n<\/tr>\n
    CLS<\/strong> (Cumulative Layout Shift)<\/span><\/td>\nEstabilidad visual de la p\u00e1gina durante la carga.<\/td>\nEvita que el usuario pulse \u201cComprar\u201d y termine pulsando \u201cCancelar\u201d porque un anuncio decidi\u00f3 caer del cielo.<\/td>\n<\/tr>\n
    FCP<\/strong> (First Contentful Paint)<\/span><\/td>\nPrimer contenido visible en pantalla.<\/td>\nReduce la sensaci\u00f3n de p\u00e1gina en blanco, ese silencio inc\u00f3modo que parece eterno.<\/td>\n<\/tr>\n
    TBT<\/strong> (Total Blocking Time)<\/span><\/td>\nTiempo en que el hilo principal queda bloqueado por tareas largas.<\/td>\nEst\u00e1 muy relacionado con JavaScript pesado y con interfaces que \u201cse congelan\u201d.<\/td>\n<\/tr>\n
    Speed Index<\/strong><\/td>\nRapidez con la que el contenido se muestra visualmente.<\/td>\nResume la percepci\u00f3n de velocidad durante la carga progresiva.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Dato importante:<\/strong> desde marzo de 2024, INP sustituy\u00f3 a FID<\/strong> como Core Web Vital de interacci\u00f3n. Si una gu\u00eda actual todav\u00eda insiste en FID como m\u00e9trica principal, quiz\u00e1 tambi\u00e9n recomiende optimizar para Internet Explorer con mirada nost\u00e1lgica. Encantador, s\u00ed. \u00datil, no tanto.<\/p>\n

    Diagn\u00f3stico profesional antes de tocar c\u00f3digo \ud83e\uddea<\/h2>\n

    Optimizar sin medir es decorar una habitaci\u00f3n a oscuras. Puede salir bien, pero no conviene presumir de m\u00e9todo. Antes de cambiar HTML, CSS o JavaScript, realiza una auditor\u00eda seria con varias herramientas, porque PageSpeed Insights no es un or\u00e1culo: es una linterna. Ilumina mucho, pero no todo.<\/p>\n

    Herramientas recomendadas<\/h3>\n
      \n
    • PageSpeed Insights:<\/strong> \u00fatil para Lighthouse y datos CrUX si hay suficiente tr\u00e1fico.<\/li>\n
    • Chrome DevTools:<\/strong> imprescindible para revisar Performance, Network, Coverage y Lighthouse local.<\/li>\n
    • WebPageTest:<\/strong> excelente para probar ubicaciones, velocidades de red, waterfalls y filmstrips.<\/li>\n
    • GTmetrix:<\/strong> pr\u00e1ctico para explicar problemas a clientes o equipos no t\u00e9cnicos.<\/li>\n
    • Query Monitor en WordPress:<\/strong> \u00fatil para detectar consultas lentas, hooks pesados y scripts cargados por plugins.<\/li>\n<\/ul>\n

      Una ma\u00f1ana, hace a\u00f1os, vi una p\u00e1gina corporativa cargar 37 archivos CSS. Treinta y siete. La home ten\u00eda tres p\u00e1rrafos, dos botones y una foto del equipo sonriendo como si no supieran nada. La explicaci\u00f3n era sencilla: cada plugin hab\u00eda tra\u00eddo su peque\u00f1a maleta de estilos, y nadie revis\u00f3 el equipaje. Aquello me record\u00f3 a esas bodas donde todos quieren dar un discurso y al final el postre llega fr\u00edo.<\/p>\n

      Qu\u00e9 revisar en el waterfall<\/h3>\n
        \n
      • Tiempo hasta el primer byte:<\/strong> si el servidor responde tarde, el frontend empieza tarde.<\/li>\n
      • Recursos render-blocking:<\/strong> CSS y JS que bloquean el primer renderizado.<\/li>\n
      • Tama\u00f1o total transferido:<\/strong> especialmente JavaScript, fuentes e im\u00e1genes.<\/li>\n
      • N\u00famero de solicitudes:<\/strong> HTTP\/2 y HTTP\/3 toleran m\u00e1s peticiones, pero no convierten el caos en virtud.<\/li>\n
      • Scripts de terceros:<\/strong> analytics, mapas, chatbots, p\u00edxeles, embeds sociales y publicidad.<\/li>\n<\/ul>\n

        Regla pr\u00e1ctica:<\/strong> si una optimizaci\u00f3n no mejora una m\u00e9trica relevante o la experiencia percibida, no es optimizaci\u00f3n; es gimnasia t\u00e9cnica. Bonita para quien la ejecuta, invisible para quien navega.<\/p>\n

        Optimizaci\u00f3n avanzada de HTML \ud83e\uddf1<\/h2>\n

        El HTML es el esqueleto de la p\u00e1gina. Si llega limpio, sem\u00e1ntico y ligero, el navegador trabaja con la serenidad de un bibliotecario ante estantes bien ordenados. Si llega inflado, duplicado y lleno de envoltorios innecesarios, cada renderizado se convierte en una peque\u00f1a excavaci\u00f3n arqueol\u00f3gica.<\/p>\n

        1. Reduce el DOM: menos nodos, menos fatiga<\/h3>\n

        Un DOM excesivo afecta al c\u00e1lculo de estilos, al layout y a la interacci\u00f3n. PageSpeed suele advertirlo con mensajes como \u201cAvoid an excessive DOM size\u201d<\/strong>. No hay una cifra universal, pero Lighthouse suele se\u00f1alar p\u00e1ginas con demasiados nodos, demasiada profundidad o demasiados hijos por nodo.<\/p>\n

        En constructores visuales de WordPress, este problema es habitual. Una simple tarjeta puede terminar envuelta en cinco divs, tres contenedores, dos wrappers y una promesa de dise\u00f1o \u201csin c\u00f3digo\u201d. La ant\u00edtesis es cruel: herramientas pensadas para simplificar la edici\u00f3n pueden complicar brutalmente el renderizado.<\/p>\n

        Buenas pr\u00e1cticas para un DOM m\u00e1s eficiente<\/h3>\n
          \n
        • Elimina contenedores sin funci\u00f3n visual, sem\u00e1ntica o t\u00e9cnica.<\/li>\n
        • Usa etiquetas sem\u00e1nticas: <header><\/code>, <main><\/code>, <nav><\/code>, <article><\/code>, <section><\/code>, <footer><\/code>.<\/li>\n
        • Evita listas, columnas y grids generados con estructuras innecesariamente profundas.<\/li>\n
        • No dupliques bloques para m\u00f3vil y escritorio si puedes resolverlo con CSS responsive.<\/li>\n
        • Revisa componentes repetidos: sliders, mega men\u00fas, acordeones y testimonios suelen multiplicar nodos sin piedad.<\/li>\n<\/ul>\n

          2. Minifica HTML, pero sin convertirlo en fetiche<\/h3>\n

          La minificaci\u00f3n elimina espacios, saltos de l\u00ednea y comentarios. Ayuda, s\u00ed, aunque normalmente su impacto es menor que reducir JavaScript o CSS. Minificar HTML es como doblar bien la ropa en una maleta; \u00fatil, pero no sirve de mucho si intentas viajar con un piano.<\/p>\n

          <!-- Antes -->\n<section>\n  <h1>Servicios de mantenimiento web<\/h1>\n  <p>Optimizamos velocidad, seguridad y rendimiento.<\/p>\n<\/section>\n\n<!-- Despu\u00e9s de minificar -->\n<section><h1>Servicios de mantenimiento web<\/h1><p>Optimizamos velocidad, seguridad y rendimiento.<\/p><\/section><\/code><\/pre>\n
          3. Prioriza recursos cr\u00edticos desde el HTML<\/h3>\n
          El navegador descubre recursos conforme parsea el documento. Si una imagen LCP aparece tarde en el HTML o est\u00e1 escondida detr\u00e1s de JavaScript, cargar\u00e1 tarde. Y PageSpeed, que no suele tener compasi\u00f3n est\u00e9tica, lo notar\u00e1.<\/p>\n
          Para recursos realmente importantes, utiliza preload<\/code>, fetchpriority<\/code> y dimensiones expl\u00edcitas. Pero con moderaci\u00f3n: si todo es prioritario, nada lo es. El navegador no necesita un director de orquesta hist\u00e9rico.<\/p>\n
          <link rel=\"preload\" as=\"image\" href=\"\/img\/hero.webp\" fetchpriority=\"high\">\n\n<img\n  src=\"\/img\/hero.webp\"\n  width=\"1440\"\n  height=\"720\"\n  alt=\"Panel de optimizaci\u00f3n web\"\n  fetchpriority=\"high\"\n  decoding=\"async\"><\/code><\/pre>\n
          4. Evita HTML generado por JavaScript cuando no sea necesario<\/h3>\n
          Una SPA puede ser magn\u00edfica para aplicaciones complejas, pero no toda p\u00e1gina corporativa necesita comportarse como si fuera el panel de control de una nave espacial. Si el contenido principal depende de JavaScript para aparecer, el navegador debe descargar, parsear y ejecutar c\u00f3digo antes de mostrar algo \u00fatil. En SEO y rendimiento, eso puede ser una cuesta arriba.<\/p>\n
          Para sitios de contenido, tiendas peque\u00f1as, blogs, landings y p\u00e1ginas de servicios, suele ser mejor entregar HTML renderizado desde el servidor o usar generaci\u00f3n est\u00e1tica. El viejo HTML, ese abuelo discreto, sigue ganando carreras mientras frameworks modernos se atan los cordones.<\/p>\n
          Optimizaci\u00f3n de CSS: critical CSS, CSS no usado y renderizado \ud83c\udfa8<\/h2>\n
          El CSS tiene una peculiaridad: bloquea el renderizado por defecto. El navegador no quiere pintar una p\u00e1gina para tener que repintarla un instante despu\u00e9s con estilos definitivos. Es prudente, casi educado. Pero si le entregamos 300 KB de CSS para mostrar una cabecera, una frase y un bot\u00f3n, la prudencia se vuelve atasco.<\/p>\n
          1. Identifica y elimina CSS no utilizado<\/h3>\n
          Chrome DevTools incluye una pesta\u00f1a llamada Coverage<\/strong> que muestra cu\u00e1nto CSS y JavaScript se usa realmente durante la carga. Es com\u00fan encontrar hojas de estilo con 70%, 80% o incluso 95% de c\u00f3digo no utilizado en la p\u00e1gina inicial.<\/p>\n
          Esto ocurre mucho con frameworks CSS completos, temas multiprop\u00f3sito y plugins que cargan estilos globales aunque solo se usen en una p\u00e1gina. El resultado es una iron\u00eda dom\u00e9stica: instalamos herramientas para \u201cahorrar tiempo\u201d y luego gastamos horas quitando lo que trajeron.<\/p>\n
          C\u00f3mo reducir CSS no usado<\/h3>\n
            \n
          • Divide CSS por plantilla o componente:<\/strong> no cargues estilos de tienda en una entrada de blog si no son necesarios.<\/li>\n
          • Usa PurgeCSS, Lightning CSS o herramientas equivalentes:<\/strong> especialmente en proyectos con Tailwind, Bootstrap o CSS acumulado.<\/li>\n
          • Desactiva assets por p\u00e1gina en WordPress:<\/strong> plugins como Perfmatters, Asset CleanUp o soluciones personalizadas con wp_dequeue_style<\/code> pueden ayudar.<\/li>\n
          • Revisa constructores visuales:<\/strong> algunos permiten generar CSS optimizado por p\u00e1gina.<\/li>\n<\/ul>\n
            2. Extrae el Critical CSS<\/h3>\n
            El Critical CSS<\/strong> es el conjunto m\u00ednimo de estilos necesarios para renderizar la parte visible inicial, conocida como above the fold. Incluirlo en l\u00ednea dentro del <head><\/code> permite pintar antes el contenido principal, mientras el resto del CSS se carga de forma diferida.<\/p>\n
            <style>\n  body{margin:0;font-family:system-ui,sans-serif;color:#111}\n  .hero{padding:64px 24px;background:#f4f7fb}\n  .hero h1{font-size:clamp(2rem,5vw,4rem);line-height:1.1;margin:0}\n  .hero p{font-size:1.25rem;max-width:720px}\n<\/style>\n\n<link rel=\"preload\" href=\"\/css\/styles.css\" as=\"style\" onload=\"this.onload=null;this.rel='stylesheet'\">\n<noscript><link rel=\"stylesheet\" href=\"\/css\/styles.css\"><\/noscript><\/code><\/pre>\n
            Cuidado:<\/strong> insertar demasiado CSS cr\u00edtico en l\u00ednea puede inflar el HTML y perjudicar el cacheo. El objetivo no es meter toda la casa en la mochila, sino llevar las llaves, el mapa y una linterna.<\/p>\n
            3. Evita @import<\/code> en CSS<\/h3>\n
            Usar @import<\/code> dentro de hojas CSS puede retrasar el descubrimiento de recursos, porque el navegador debe descargar un archivo para descubrir que necesita otro. Es una conversaci\u00f3n burocr\u00e1tica entre archivos: \u201cvaya a la ventanilla B\u201d. Mejor enlazar los estilos directamente desde el HTML.<\/p>\n
            \/* Evitar *\/\n@import url(\"\/css\/fonts.css\");\n@import url(\"\/css\/components.css\");\n\n\/* Mejor: enlazar desde el HTML *\/\n<link rel=\"stylesheet\" href=\"\/css\/fonts.css\">\n<link rel=\"stylesheet\" href=\"\/css\/components.css\"><\/code><\/pre>\n
            4. Optimiza fuentes web<\/h3>\n
            Aunque el t\u00edtulo hable de HTML, CSS y JS, las fuentes merecen silla en la mesa. Una tipograf\u00eda externa mal cargada puede retrasar texto visible y afectar LCP o CLS. Usa formatos modernos como WOFF2<\/strong>, limita variantes y declara font-display: swap<\/code> para evitar texto invisible.<\/p>\n
            @font-face {\n  font-family: \"Inter\";\n  src: url(\"\/fonts\/inter-var.woff2\") format(\"woff2\");\n  font-weight: 100 900;\n  font-style: normal;\n  font-display: swap;\n}<\/code><\/pre>\n
            5. Usa CSS moderno para reducir JavaScript<\/h3>\n
            Muchas interacciones que antes requer\u00edan JavaScript hoy pueden resolverse con CSS: men\u00fas sencillos, acordeones con <details><\/code>, animaciones discretas, layouts complejos con Grid y estilos condicionales con :has()<\/code> en navegadores modernos. Menos JavaScript significa menos parseo, menos ejecuci\u00f3n y menos bloqueo del hilo principal.<\/p>\n
            <details>\n  <summary>\u00bfPageSpeed afecta al SEO?<\/summary>\n  <p>S\u00ed, especialmente a trav\u00e9s de la experiencia de p\u00e1gina y Core Web Vitals, aunque el contenido y la intenci\u00f3n de b\u00fasqueda siguen siendo fundamentales.<\/p>\n<\/details><\/code><\/pre>\n
            Optimizaci\u00f3n de JavaScript: menos bloqueo, m\u00e1s intenci\u00f3n \ud83e\udde0<\/h2>\n
            JavaScript es poderoso. Tambi\u00e9n es caro. Cada kilobyte debe descargarse, parsearse, compilarse y ejecutarse. El navegador no mastica JS como quien come aire; lo procesa como una m\u00e1quina fina a la que le hemos pedido tocar viol\u00edn mientras levanta pesas.<\/p>\n
            En la mayor\u00eda de auditor\u00edas de PageSpeed, JavaScript es el principal sospechoso detr\u00e1s de advertencias como \u201cReduce unused JavaScript\u201d<\/strong>, \u201cMinimize main-thread work\u201d<\/strong>, \u201cAvoid long main-thread tasks\u201d<\/strong> y \u201cEliminate render-blocking resources\u201d<\/strong>.<\/p>\n
            1. Usa defer<\/code> y async<\/code> con criterio<\/h3>\n
            Los scripts cl\u00e1sicos bloquean el parseo del HTML si se cargan sin atributos. Para evitarlo, se utilizan defer<\/code> o async<\/code>. Parecen primos, pero no son iguales.<\/p>\n\n\n\n\n\n\n
            Atributo<\/th>\nComportamiento<\/th>\nCu\u00e1ndo usarlo<\/th>\n<\/tr>\n<\/thead>\n
            defer<\/code><\/td>\nDescarga el script en paralelo y lo ejecuta despu\u00e9s de parsear el HTML, respetando el orden.<\/td>\nIdeal para scripts propios que dependen del DOM o de otros scripts.<\/td>\n<\/tr>\n
            async<\/code><\/td>\nDescarga en paralelo y ejecuta tan pronto como est\u00e9 listo, sin garantizar orden.<\/td>\n\u00datil para scripts independientes: analytics, p\u00edxeles, widgets no cr\u00edticos.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
            <script src=\"\/js\/app.js\" defer><\/script>\n<script src=\"https:\/\/www.googletagmanager.com\/gtag\/js?id=XXXX\" async><\/script><\/code><\/pre>\n
            2. Divide el c\u00f3digo: code splitting<\/h3>\n
            No todas las p\u00e1ginas necesitan todo el JavaScript de tu sitio. La p\u00e1gina de contacto no deber\u00eda cargar el carrusel de testimonios, el configurador de producto y el m\u00f3dulo de checkout si no los usa. El code splitting<\/strong> permite dividir bundles y cargar solo lo necesario.<\/p>\n
            \/\/ Ejemplo con import din\u00e1mico\ndocument.querySelectorAll(\"[data-gallery]\").forEach(async (gallery) => {\n  const { initGallery } = await import(\".\/gallery.js\");\n  initGallery(gallery);\n});<\/code><\/pre>\n
            Esta t\u00e9cnica mejora especialmente el Total Blocking Time<\/strong> y el INP<\/strong>, porque reduce el trabajo inicial del hilo principal. La p\u00e1gina se vuelve m\u00e1s \u00e1gil, menos teatral. No intenta desplegar todo el escenario antes de que el espectador se siente.<\/p>\n
            3. Elimina JavaScript no usado<\/h3>\n
            El c\u00f3digo muerto es una forma elegante de llamar a lo que nadie usa pero todos cargan. Puede venir de librer\u00edas enteras importadas para usar una funci\u00f3n diminuta, plugins antiguos, polyfills innecesarios o funcionalidades desactivadas que siguen viajando en producci\u00f3n como fantasmas con contrato indefinido.<\/p>\n
              \n
            • Importa funciones espec\u00edficas en lugar de librer\u00edas completas.<\/li>\n
            • Usa tree shaking con bundlers modernos como Vite, Rollup, esbuild o Webpack bien configurado.<\/li>\n
            • Retira polyfills para navegadores que ya no forman parte de tu soporte real.<\/li>\n
            • Sustituye librer\u00edas pesadas por APIs nativas cuando sea viable.<\/li>\n
            • Audita dependencias con herramientas como Bundle Analyzer.<\/li>\n<\/ul>\n
              \/\/ Evitar si solo necesitas una funci\u00f3n\nimport _ from \"lodash\";\nconst items = _.uniq(lista);\n\n\/\/ Mejor\nimport uniq from \"lodash\/uniq\";\nconst items = uniq(lista);\n\n\/\/ O incluso mejor si basta JS nativo\nconst items = [...new Set(lista)];<\/code><\/pre>\n
              4. Retrasa scripts de terceros<\/h3>\n
              Los scripts de terceros son los invitados que llegan con amigos. Chatbots, mapas, p\u00edxeles publicitarios, embeds de redes sociales, herramientas de mapas de calor, gestores de consentimiento y sistemas de rese\u00f1as pueden degradar PageSpeed de manera severa. No porque sean malvados, sino porque no viven bajo tu techo.<\/p>\n
              Un enfoque profesional consiste en retrasar su carga hasta que exista interacci\u00f3n, consentimiento o necesidad visual real.<\/p>\n
              function loadScript(src) {\n  const script = document.createElement(\"script\");\n  script.src = src;\n  script.async = true;\n  document.head.appendChild(script);\n}\n\n[\"mousemove\", \"scroll\", \"keydown\", \"touchstart\"].forEach((event) => {\n  window.addEventListener(event, () => {\n    loadScript(\"https:\/\/example.com\/widget.js\");\n  }, { once: true, passive: true });\n});<\/code><\/pre>\n
              Nota legal y t\u00e9cnica:<\/strong> si trabajas con scripts de anal\u00edtica, publicidad o remarketing, coordina la carga diferida con el banner de consentimiento y la normativa aplicable, como RGPD en la Uni\u00f3n Europea. La velocidad no justifica atropellar la privacidad; bastante hemos aprendido ya, o eso queremos creer.<\/p>\n
              5. Rompe tareas largas<\/h3>\n
              Una tarea larga en el hilo principal puede bloquear la interacci\u00f3n. Para mejorar INP y TBT, divide procesos pesados en fragmentos m\u00e1s peque\u00f1os, usa requestIdleCallback<\/code> cuando sea apropiado o traslada c\u00e1lculos complejos a Web Workers.<\/p>\n
              \/\/ Evita bloquear el hilo principal con grandes lotes\nfunction processItems(items) {\n  const chunk = items.splice(0, 100);\n\n  chunk.forEach(processItem);\n\n  if (items.length > 0) {\n    setTimeout(() => processItems(items), 0);\n  }\n}<\/code><\/pre>\n
              6. Minifica, comprime y sirve JS moderno<\/h3>\n
              La minificaci\u00f3n reduce el tama\u00f1o del archivo. La compresi\u00f3n Brotli o Gzip reduce el tama\u00f1o transferido. Pero adem\u00e1s conviene servir JavaScript moderno a navegadores modernos, evitando transformaciones excesivas que inflan el c\u00f3digo.<\/p>\n
              <script type=\"module\" src=\"\/js\/app.modern.js\"><\/script>\n<script nomodule src=\"\/js\/app.legacy.js\" defer><\/script><\/code><\/pre>\n
              El atributo type=\"module\"<\/code> implica comportamiento diferido por defecto. Es una peque\u00f1a cortes\u00eda del est\u00e1ndar, como si el navegador dijera: \u201ctranquilo, esto lo ejecuto cuando corresponda\u201d.<\/p>\n
              Caso WordPress: c\u00f3mo evitar que el CMS se convierta en lastre \ud83d\udee0\ufe0f<\/h2>\n
              WordPress puede ser r\u00e1pido. Muy r\u00e1pido. Tambi\u00e9n puede convertirse en una criatura barroca hecha de plugins duplicados, temas gigantes y sliders que nadie mira. El contraste es magn\u00edfico: el mismo CMS que impulsa proyectos editoriales \u00e1giles puede arrastrar una landing de tres secciones como si fuera un elefante cruzando un puente de madera.<\/p>\n
              1. Elige un tema ligero<\/h3>\n
              La optimizaci\u00f3n empieza antes de escribir c\u00f3digo. Temas como GeneratePress, Astra, Blocksy o Kadence pueden funcionar muy bien si se configuran con sobriedad. Un tema multiprop\u00f3sito con decenas de demos, sliders integrados, icon packs, animaciones y constructores embebidos puede ser c\u00f3modo al principio y caro despu\u00e9s.<\/p>\n
              2. Desactiva scripts y estilos por p\u00e1gina<\/h3>\n
              WordPress permite retirar assets con wp_dequeue_script<\/code> y wp_dequeue_style<\/code>. Esto requiere conocer bien las dependencias, pero ofrece un control fino.<\/p>\n
              add_action('wp_enqueue_scripts', function() {\n  if (!is_contact_page()) {\n    wp_dequeue_script('contact-form-7');\n    wp_dequeue_style('contact-form-7');\n  }\n}, 100);<\/code><\/pre>\n
              Tambi\u00e9n puedes usar plugins especializados para gestionar assets sin tocar c\u00f3digo. Eso s\u00ed, prueba cada cambio: desactivar un script incorrecto puede romper formularios, men\u00fas o carritos de compra. La velocidad no sirve de mucho si el bot\u00f3n de compra queda como estatua decorativa.<\/p>\n
              3. Optimiza el editor de bloques y constructores<\/h3>\n
                \n
              • Evita bloques con animaciones innecesarias above the fold.<\/li>\n
              • No uses sliders hero si una imagen est\u00e1tica comunica lo mismo.<\/li>\n
              • Reduce columnas anidadas y wrappers generados por el constructor.<\/li>\n
              • Activa generaci\u00f3n de CSS por p\u00e1gina si tu builder lo permite.<\/li>\n
              • Desactiva icon libraries completas si solo usas dos iconos SVG.<\/li>\n<\/ul>\n
                4. Cach\u00e9, compresi\u00f3n y servidor<\/h3>\n
                Aunque esta gu\u00eda se centra en HTML, CSS y JavaScript, ser\u00eda poco honesto ignorar el servidor. Un frontend pulcro sobre un hosting lento es como poner neum\u00e1ticos de F\u00f3rmula 1 a una carreta. Para PageSpeed, el TTFB importa.<\/p>\n
                  \n
                • Usa cach\u00e9 de p\u00e1gina completa para contenido p\u00fablico.<\/li>\n
                • Activa Object Cache con Redis o Memcached en sitios din\u00e1micos.<\/li>\n
                • Sirve recursos est\u00e1ticos con CDN cuando tenga sentido geogr\u00e1fico.<\/li>\n
                • Activa Brotli si el servidor o CDN lo soporta.<\/li>\n
                • Usa HTTP\/2 o HTTP\/3.<\/li>\n
                • Mant\u00e9n PHP actualizado: PHP 8.x ofrece mejoras relevantes frente a versiones antiguas.<\/li>\n<\/ul>\n
                  5. WooCommerce: el caso delicado<\/h3>\n
                  Optimizar una tienda online exige m\u00e1s cautela. Carrito, checkout, sesiones, fragmentos AJAX y pasarelas de pago no deben tocarse con alegr\u00eda quir\u00fargica. En WooCommerce, conviene desactivar scripts del carrito solo en p\u00e1ginas donde no sean necesarios y mantener intactos procesos cr\u00edticos.<\/p>\n
                  add_action('wp_enqueue_scripts', function() {\n  if (!is_cart() && !is_checkout() && !is_product()) {\n    wp_dequeue_script('wc-cart-fragments');\n  }\n}, 100);<\/code><\/pre>\n
                  Recomendaci\u00f3n profesional:<\/strong> prueba cualquier optimizaci\u00f3n de WooCommerce en staging antes de producci\u00f3n. El 100\/100 pierde encanto si la tienda deja de vender. Nadie imprime facturas con capturas de PageSpeed.<\/p>\n
                  Core Web Vitals: el n\u00famero verde no lo es todo \ud83d\udcca<\/h2>\n
                  El objetivo no deber\u00eda ser \u00fanicamente \u201csacar 100\u201d, sino mejorar la experiencia real del usuario. PageSpeed es una medici\u00f3n de laboratorio; los Core Web Vitals<\/strong> de campo reflejan condiciones reales. Una web puede obtener 98 en Lighthouse y fallar en usuarios reales por culpa de redes lentas, dispositivos modestos o scripts cargados tras consentimiento.<\/p>\n
                  Valores de referencia recomendados por Google<\/h3>\n\n\n\n\n\n\n\n
                  M\u00e9trica<\/th>\nBueno<\/th>\nNecesita mejorar<\/th>\nPobre<\/th>\n<\/tr>\n<\/thead>\n
                  LCP<\/strong><\/td>\n\u2264 2,5 s<\/td>\n2,5 s – 4 s<\/td>\n> 4 s<\/td>\n<\/tr>\n
                  INP<\/strong><\/td>\n\u2264 200 ms<\/td>\n200 ms – 500 ms<\/td>\n> 500 ms<\/td>\n<\/tr>\n
                  CLS<\/strong><\/td>\n\u2264 0,1<\/td>\n0,1 – 0,25<\/td>\n> 0,25<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                  C\u00f3mo mejorar LCP desde HTML, CSS y JS<\/h3>\n
                    \n
                  • Coloca el elemento LCP pronto en el HTML.<\/li>\n
                  • Evita que el hero dependa de JavaScript para renderizarse.<\/li>\n
                  • Precarga la imagen principal si es realmente prioritaria.<\/li>\n
                  • Reduce CSS bloqueante y extrae Critical CSS.<\/li>\n
                  • Optimiza fuentes para que el texto principal aparezca r\u00e1pido.<\/li>\n
                  • No uses lazy loading en la imagen LCP above the fold.<\/li>\n<\/ul>\n
                    C\u00f3mo mejorar INP<\/h3>\n
                      \n
                    • Reduce JavaScript inicial y elimina tareas largas.<\/li>\n
                    • Difiere scripts no cr\u00edticos.<\/li>\n
                    • Evita listeners excesivos o costosos en scroll, resize y input.<\/li>\n
                    • Usa delegaci\u00f3n de eventos cuando sea apropiado.<\/li>\n
                    • Optimiza componentes interactivos: men\u00fas, filtros, buscadores, carritos y formularios.<\/li>\n<\/ul>\n
                      C\u00f3mo mejorar CLS<\/h3>\n
                        \n
                      • Define width<\/code> y height<\/code> en im\u00e1genes y v\u00eddeos.<\/li>\n
                      • Reserva espacio para banners, iframes y anuncios.<\/li>\n
                      • Evita insertar contenido above the fold despu\u00e9s de la carga.<\/li>\n
                      • Controla el comportamiento de fuentes para reducir saltos visuales.<\/li>\n
                      • No cambies dimensiones de componentes al hidratar JavaScript.<\/li>\n<\/ul>\n
                        Presupuesto de rendimiento: la disciplina que evita reca\u00eddas \ud83d\udcbc<\/h2>\n
                        Una web optimizada puede deteriorarse en silencio. Hoy tiene 100\/100; ma\u00f1ana alguien instala un chat, pasado ma\u00f1ana se a\u00f1ade un mapa interactivo, la semana siguiente entra un p\u00edxel publicitario \u201cimprescindible\u201d, y al mes la p\u00e1gina carga como un barco con el ancla echada. La degradaci\u00f3n rara vez llega con trompetas. Llega en reuniones.<\/p>\n
                        Por eso conviene establecer un performance budget<\/strong>, es decir, l\u00edmites t\u00e9cnicos aceptados por el equipo.<\/p>\n\n\n\n\n\n\n\n\n\n
                        Elemento<\/th>\nL\u00edmite sugerido para una landing optimizada<\/th>\n<\/tr>\n<\/thead>\n
                        JavaScript inicial<\/td>\nMenos de 150 KB comprimidos, idealmente mucho menos<\/td>\n<\/tr>\n
                        CSS inicial<\/td>\nMenos de 50 KB comprimidos<\/td>\n<\/tr>\n
                        Solicitudes cr\u00edticas<\/td>\nLas m\u00ednimas necesarias para pintar contenido \u00fatil<\/td>\n<\/tr>\n
                        Fuentes<\/td>\n1 familia, pocas variantes, formato WOFF2<\/td>\n<\/tr>\n
                        Scripts de terceros<\/td>\nSolo los que aporten valor medible<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                        Estos n\u00fameros no son mandamientos grabados en piedra. Dependen del proyecto. Una aplicaci\u00f3n SaaS no tiene el mismo presupuesto que una p\u00e1gina de captaci\u00f3n local. Pero tener l\u00edmites cambia la conversaci\u00f3n: ya no se pregunta \u201c\u00bfpodemos a\u00f1adir esto?\u201d, sino \u201c\u00bfqu\u00e9 coste tendr\u00e1 y qu\u00e9 retiramos a cambio?\u201d. Esa pregunta, aunque parezca peque\u00f1a, separa una web mantenible de un trastero digital.<\/p>\n
                        Ejemplo de estrategia completa para una p\u00e1gina de servicios \ud83d\ude80<\/h2>\n
                        Imaginemos una p\u00e1gina de servicios profesionales en WordPress. Tiene cabecera, hero con imagen, tres bloques de servicios, testimonios, formulario de contacto y footer. Quiere mejorar PageSpeed m\u00f3vil<\/strong>, reducir recursos bloqueantes y acercarse al 100\/100.<\/p>\n
                        Plan de optimizaci\u00f3n<\/h3>\n
                          \n
                        1. Auditar:<\/strong> ejecutar PageSpeed, WebPageTest y DevTools Coverage.<\/li>\n
                        2. HTML:<\/strong> reducir wrappers del constructor, dejar el H1 y texto principal renderizados desde servidor.<\/li>\n
                        3. Imagen LCP:<\/strong> convertir a WebP o AVIF, definir dimensiones, usar fetchpriority=\"high\"<\/code> y evitar lazy loading.<\/li>\n
                        4. CSS:<\/strong> generar Critical CSS, eliminar estilos de WooCommerce si no hay tienda en esa URL, desactivar CSS de plugins no usados.<\/li>\n
                        5. JS:<\/strong> aplicar defer<\/code> a scripts propios, retrasar chat y mapas hasta interacci\u00f3n.<\/li>\n
                        6. Formulario:<\/strong> cargar scripts del formulario solo en p\u00e1ginas con formulario.<\/li>\n
                        7. Fuentes:<\/strong> alojar localmente una variable font en WOFF2 con font-display: swap<\/code>.<\/li>\n
                        8. Cach\u00e9:<\/strong> activar cach\u00e9 de p\u00e1gina, Brotli y CDN si el tr\u00e1fico es internacional.<\/li>\n
                        9. Verificar:<\/strong> repetir pruebas en inc\u00f3gnito, m\u00f3vil simulado y dispositivo real.<\/li>\n<\/ol>\n
                          Resultado esperable<\/h3>\n
                          En casos t\u00edpicos, estos cambios pueden reducir cientos de kilobytes, eliminar bloqueos de renderizado y mejorar notablemente LCP y TBT. \u00bfGarantiza un 100\/100? No siempre. Depende del hosting, del tema, de terceros, del dise\u00f1o y del contenido. Pero s\u00ed coloca la web en el terreno donde el 100 deja de ser fantas\u00eda y se vuelve posibilidad t\u00e9cnica.<\/p>\n
                          Checklist final para alcanzar 100\/100 en Google PageSpeed \u2705<\/h2>\n
                          HTML<\/h3>\n
                            \n
                          • DOM reducido y estructura sem\u00e1ntica.<\/li>\n
                          • Contenido principal visible sin depender de JS.<\/li>\n
                          • Imagen LCP ubicada pronto en el documento.<\/li>\n
                          • Dimensiones declaradas en im\u00e1genes, v\u00eddeos e iframes.<\/li>\n
                          • HTML minificado en producci\u00f3n.<\/li>\n<\/ul>\n
                            CSS<\/h3>\n
                              \n
                            • Critical CSS inline bien calculado.<\/li>\n
                            • CSS no usado eliminado o separado por p\u00e1gina.<\/li>\n
                            • Hojas de estilo minificadas.<\/li>\n
                            • Sin @import<\/code> bloqueante.<\/li>\n
                            • Fuentes optimizadas con WOFF2 y font-display<\/code>.<\/li>\n<\/ul>\n
                              JavaScript<\/h3>\n
                                \n
                              • Scripts propios con defer<\/code>.<\/li>\n
                              • Terceros con async<\/code>, retraso o carga bajo consentimiento.<\/li>\n
                              • Code splitting aplicado cuando sea necesario.<\/li>\n
                              • JavaScript no usado eliminado.<\/li>\n
                              • Tareas largas divididas o enviadas a Web Workers.<\/li>\n<\/ul>\n
                                WordPress<\/h3>\n
                                  \n
                                • Tema ligero y plugins auditados.<\/li>\n
                                • Assets desactivados por p\u00e1gina.<\/li>\n
                                • Cach\u00e9 de p\u00e1gina activa.<\/li>\n
                                • Base de datos limpia y PHP actualizado.<\/li>\n
                                • Pruebas en staging antes de producci\u00f3n.<\/li>\n<\/ul>\n
                                  Errores frecuentes que impiden llegar al 100\/100 \ud83e\uddef<\/h2>\n
                                    \n
                                  • Optimizar solo escritorio:<\/strong> PageSpeed m\u00f3vil suele ser m\u00e1s exigente y m\u00e1s representativo del usuario com\u00fan.<\/li>\n
                                  • Instalar plugins de rendimiento sin configuraci\u00f3n:<\/strong> algunos duplican funciones, generan conflictos o rompen scripts cr\u00edticos.<\/li>\n
                                  • Usar lazy loading indiscriminado:<\/strong> aplicarlo a la imagen principal puede empeorar LCP.<\/li>\n
                                  • Ignorar scripts de terceros:<\/strong> muchas veces son el verdadero peso muerto.<\/li>\n
                                  • No reservar espacio para elementos din\u00e1micos:<\/strong> causa CLS y una experiencia visual inestable.<\/li>\n
                                  • Perseguir el 100 sacrificando funcionalidad:<\/strong> una web r\u00e1pida pero in\u00fatil es una bicicleta sin ruedas: ligera, desde luego.<\/li>\n<\/ul>\n
                                    \u00bfVale la pena obsesionarse con el 100\/100? \ud83c\udfaf<\/h2>\n
                                    S\u00ed y no. Qu\u00e9 c\u00f3moda respuesta, lo s\u00e9. Un 100\/100 en PageSpeed puede ser un excelente indicador de disciplina t\u00e9cnica, especialmente en p\u00e1ginas est\u00e1ticas, blogs optimizados, landings sencillas y sitios corporativos bien construidos. Pero en proyectos complejos, con personalizaci\u00f3n, comercio electr\u00f3nico, mapas, sistemas de reserva o marketing avanzado, quiz\u00e1 el objetivo sensato sea mantener Core Web Vitals en verde, reducir fricci\u00f3n y proteger conversiones.<\/p>\n
                                    La diferencia entre 96 y 100 puede consumir horas que aportar\u00edan m\u00e1s valor mejorando contenido, accesibilidad, seguridad o arquitectura de informaci\u00f3n. La excelencia no siempre est\u00e1 en exprimir cuatro puntos, sino en saber cu\u00e1ndo detener la lima antes de romper la pieza.<\/p>\n
                                    Aun as\u00ed, apuntar alto tiene virtud. Obliga a cuestionarlo todo: cada dependencia, cada animaci\u00f3n, cada plugin, cada kilobyte. Y esa mirada cr\u00edtica mejora la web incluso cuando el marcador no alcanza la perfecci\u00f3n redonda. Porque el verdadero premio no es complacer a Lighthouse, sino entregar una experiencia veloz, estable y clara. Una p\u00e1gina que aparece sin drama, responde sin pereza y deja al usuario avanzar como agua por piedra pulida.<\/p>\n
                                    En s\u00edntesis pr\u00e1ctica:<\/strong> para acercarte al 100\/100 en Google PageSpeed<\/span>, reduce el DOM, entrega HTML \u00fatil desde el inicio, extrae Critical CSS, elimina CSS y JavaScript no usados, difiere lo no esencial, controla terceros, optimiza fuentes y mide cada cambio. La velocidad web no nace de un truco aislado, sino de una suma de decisiones peque\u00f1as, persistentes y bien defendidas.<\/p>\n<\/article>\n","protected":false},"excerpt":{"rendered":"
                                    \u00bfC\u00f3mo optimizar el c\u00f3digo HTML, CSS y JS para alcanzar un 100\/100 en Google PageSpeed?<\/p>\n","protected":false},"author":1,"featured_media":3735,"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-3736","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\/3736","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=3736"}],"version-history":[{"count":1,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3736\/revisions"}],"predecessor-version":[{"id":3737,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/posts\/3736\/revisions\/3737"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media\/3735"}],"wp:attachment":[{"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/media?parent=3736"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/categories?post=3736"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mantenimientoweb.pro\/blog\/wp-json\/wp\/v2\/tags?post=3736"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}