Eliminando el Parámetro de Versión en Scripts y Estilos en WordPress

La optimización de cacheo es uno de los pilares fundamentales para garantizar una experiencia de usuario fluida y un SEO competitivo. Por defecto, WordPress añade un parámetro de versión a cada archivo CSS y JavaScript que encola, resultando en URLs como style.css?ver=6.4. Aunque esta técnica es efectiva para forzar la actualización del navegador durante el desarrollo, puede convertirse en un obstáculo invisible para la infraestructura de red moderna y la escalabilidad de un sitio web.

#El Concepto: Query Strings en Recursos Estáticos

En el protocolo HTTP, los archivos estáticos como scripts, hojas de estilo e imágenes son, por naturaleza, candidatos ideales para ser almacenados en caché por tiempo prolongado. Sin embargo, la presencia de una «query string» (la parte de la URL que comienza con ?) indica técnicamente que el recurso podría ser dinámico y depender de parámetros externos.

#Impacto en CDNs y Proxies

Muchos servidores intermedios, como los CDNs (Content Delivery Networks) o balanceadores de carga tipo Varnish o Nginx, están configurados de forma conservadora. Por defecto, pueden omitir el cacheo de cualquier URL que contenga parámetros para evitar servir contenido desactualizado o incorrecto. Esto significa que, aunque tengamos un CDN configurado, los archivos .css y .js podrían estar solicitándose directamente al servidor de origen en cada visita, aumentando la latencia y el consumo de recursos de nuestro hosting.

#Patrones de Resolución Universal

La forma estándar de resolver este conflicto en la industria consiste en separar la lógica de versión del nombre del archivo. En lugar de usar parámetros, se recomienda usar versionado por nombre de archivo (ej. main.1.0.3.css) o, en su defecto, eliminar las query strings y confiar en las cabeceras de control de caché (Cache-Control) enviadas por el servidor. En ecosistemas como WordPress, podemos interceptar la generación de estas URLs antes de que lleguen al HTML final enviado al usuario.

#Estudio de Caso: Aplicación Práctica

Para implementar esta lección en un entorno real, podemos crear una función de filtrado que analice las rutas de los assets y elimine selectivamente el argumento ver. Esto asegura que los archivos se presenten con URLs limpias a cualquier sistema de optimización externo.

Consideremos el caso de Juan, un administrador de sistemas que gestionaba un blog técnico con picos de tráfico masivos. Juan notó que, a pesar de tener un CDN premium, el tiempo de carga desde dispositivos móviles era inconsistente. Tras auditar las cabeceras, descubrió que el parámetro ?ver= causaba que los archivos CSS se descargaran desde el servidor central en el 40% de las peticiones.

Para solucionar esto, integró el siguiente fragmento de código en la lógica de optimización del sitio:

// Archivo: inc/optimization.php

function github_theme_remove_script_version($src) {
    if (strpos($src, '?ver=') || strpos($src, '&ver=')) {
        $src = remove_query_arg('ver', $src);
    }
    return $src;
}
add_filter('style_loader_src', 'github_theme_remove_script_version', 9999);
add_filter('script_loader_src', 'github_theme_remove_script_version', 9999);

Tras aplicar este patrón, la tasa de acierto de caché de su CDN subió del 60% al 98%, reduciendo el Time To First Byte (TTFB) y mejorando la estabilidad del servidor durante lanzamientos de productos.

Aclarar que para que ese archivo cargue tiene que haber una llamada en el functions.php del theme

#Cuándo usar / Cuándo NO usar

#Resumen de Parámetros y Beneficios