Publicado: 21 de noviembre de 2025
Históricamente, la compatibilidad con navegadores en Target.com se basó principalmente en la compatibilidad con todos los usuarios que realizan compras en Target.com. Esta política cambia en los puntos de decisión importantes, como dejar de admitir Internet Explorer por completo o segmentar anuncios para una versión mínima determinada de un navegador para obtener acceso a una función de alto valor. Esto sucede una vez cada dos años cuando surge la necesidad.
Sin una política progresiva sobre qué navegadores y funciones segmentar, Target.com solo permitía funciones modernas en la base de código con soluciones torpes, como polyfilling y transpilación a versiones muy antiguas de JavaScript. Cuando el Grupo de la comunidad de WebDX lanzó Baseline, las partes interesadas de Target.com consideraron que era el momento adecuado para pensar en encontrar un objetivo de compatibilidad mínimo más adecuado.
Con Baseline, Target ahora sabe con certeza qué funciones están disponibles en los navegadores compatibles y puede identificar las funciones más recientes que se volvieron disponibles con la mejora progresiva y los polyfills como posibles alternativas.
El problema
Decenas de ingenieros contribuyen con código a Target.com en un día cualquiera. Es común que, en las revisiones de código, se señalen las funciones que no funcionan con las versiones de navegador compatibles con Target.com usando Can I use como recurso. Cuando los ingenieros reciben comentarios de forma continua para cambiar su código y preferir las funciones heredadas en lugar de las modernas, el resultado es que se evitan las nuevas funciones web. Luego, Target recurre a técnicas "antiguas" que funcionan, pero la oportunidad de usar funciones modernas se pospone para otro momento. El uso de funciones web modernas suele brindar una mejor experiencia del desarrollador y también puede proporcionar una mejor experiencia del usuario, ya que se envía menos código.
Un enfoque basado en datos para la compatibilidad con navegadores
Target.com tiene una configuración de webpack que define las versiones mínimas admitidas del navegador. Históricamente, ha sido difícil justificar el aumento de estas versiones mínimas compatibles del navegador. A principios de 2025, las reglas eran las siguientes:
- Las dos versiones actuales y anteriores de Chrome, Edge y Firefox
- Safari 11 y versiones posteriores.
Safari se trata con más cuidado debido al gran volumen de tráfico y ventas que Target obtiene de Safari en iOS. Inicialmente, se tomó la decisión fundamentada de establecer Safari 11 como la versión mínima para la que se desarrollaría. Esta decisión fijó Target.com a las funciones web que estaban disponibles en 2017 y antes de ese año.
En el primer paso del recorrido de Target para integrar Baseline en su flujo de trabajo de desarrollo, se usó un enfoque basado en datos. A través de la investigación, Target descubrió que las versiones de Safari de la 11 a la 14 generaban un impacto comercial muy bajo, específicamente el 0 .0001% de las ventas de demanda en Target.com. Dada esta realidad, Target reconoció que quitar la transpilación y los polyfills para estas versiones obsoletas del navegador brindaría oportunidades significativas para mejorar el rendimiento del sitio.
Las investigaciones adicionales mostraron que Safari 15.4 fue la primera versión de Safari que generó al menos el 0.5% de las ventas de la demanda, y cada versión secundaria de Safari 15 posterior a esa tuvo un impacto similar. Cada vez que Target ejecuta una prueba A/B, alterar el 0.5% de las ventas de la demanda es muy valioso y lleva a la conclusión de que la versión mínima compatible de Safari debería estar en algún lugar dentro de la versión 15.
Una tendencia interesante que encontramos en esta investigación es la rapidez con la que se está dejando de usar el navegador Safari anterior. En septiembre de 2024, Safari 15 solo contribuyó al 0.94% de las ventas de demanda en Target.com. En enero de 2025, representó el 0.67% de las ventas de demanda, en mayo de 2025 disminuyó aún más hasta el 0.45% y, en noviembre de 2025, se ubicó en el 0.32%. Lo que Target aprendió de esto es que, si se determina un umbral de dinero real como porcentaje de las ventas de demanda en todo el sitio, la compatibilidad con estos navegadores puede finalizar de forma automática, y la próxima versión principal en Safari 16 se puede lograr para fin de año.
La suspensión de la compatibilidad no significa que se bloqueen los navegadores no compatibles. Es posible que las personas que los usan aún puedan encontrar una ruta de compra, pero también es posible que, en algunos casos, tengan una experiencia reducida. Tras realizar los cambios, los analistas informaron que no se produjo ningún impacto medible en las métricas comerciales, lo que demuestra que el enfoque basado en datos sigue siendo efectivo. Además, Target está analizando la posibilidad de mostrar un banner en las versiones de navegador no compatibles que advierta sobre la experiencia degradada.
Cómo elegir un objetivo de referencia para Target.com
Los ingenieros web de Target formaron un grupo de trabajo de Baseline para combinar estos esfuerzos y usar funciones modernas, y el objetivo en constante cambio de qué navegadores admitir para ayudar a impulsar la política. Con las herramientas de Baseline, analizaron cuál era el conjunto mínimo de navegadores de cada año. El objetivo más cercano a la nueva política de Target fue Baseline 2022:
{
"chrome": "108",
"edge": "108",
"firefox": "108",
"ios": "16",
"safari": "16"
}
Para alcanzar ese valor de referencia, Target debería ajustar su política de navegador a Safari 16 como mínimo, en lugar de la versión actual 15.4. Esto degradaría la experiencia de menos del 0.5% de los compradores que realizan conversiones. Aun así, ese porcentaje se está reduciendo, por lo que Target espera actualizar su política oficial para que se vincule con Baseline 2022 a fines de 2025. Esto coloca a los desarrolladores de Target.com en una posición en la que el objetivo se puede cambiar para que se encuentre alrededor de 3 años por detrás de la referencia anual publicada.
En general, los paquetes de webpack para Target.com son más pequeños debido a que se transpila menos código y se agregan polyfills. Target confía en que este destino cambiará con el tiempo y espera que, para esta fecha el próximo año, se pueda adoptar Baseline 2023, que incluye muchas funciones excelentes, como las consultas de contenedores, el selector :has, el atributo inert y mucho más.
Conjuntos de funciones de referencia más recientes
El grupo de trabajo de Target Baseline no se detendrá con la versión Baseline 2022. Si observamos las funciones de Baseline 2023, muchas de ellas están en el umbral de poder admitirse sin copias de seguridad, como los polyfills. Cada una de las funciones de Baseline 2023 en las que Target está interesado requiere que se haga lo siguiente:
- Explica qué hace la función.
- Documentar cómo su uso podría mejorar Target.com, incluidas las mejoras en la experiencia del desarrollador
- Encuentra un buen caso de prueba para implementar la función en la base de código de Target.com.
- Si es necesario, documenta qué alternativas usar, como la mejora progresiva o cualquier otra solución que se proporcione a través de la detección de funciones.
- Por último, ¿cuándo se espera que se apruebe el uso de la función? ¿Se puede usar ahora? ¿O se debería esperar a algún umbral futuro?
Un ejemplo de esto es el atributo inert. La versión mínima para usar inert en Safari es la 15.5, lo que significa que Target.com está cerca de poder usarlo. Target.com tiene muchas implementaciones modales en las que este atributo sería beneficioso en comparación con su solución actual de JavaScript. Que un ingeniero redacte el informe sobre esta función permite compartir conocimientos y prepararse para la próxima flexibilización de la política del navegador. Esto ayuda a demostrar que dejar de admitir una versión del navegador que aporta poco valor comercial puede habilitar funciones que sí tienen valor. La función se puede diseñar, revisar y lanzar con una marca de función, y estar lista en caso de que se pueda usar.
Además, otro ingeniero seguirá el mismo proceso para usar consultas de contenedor, que ahora están disponibles de forma general como Baseline. Las consultas de contenedor se podrían usar con un polyfill, pero este tiene problemas de rendimiento conocidos. La solución que propuso Target fue usar las consultas de contenedor solo como una mejora progresiva hasta que los mínimos del navegador aumenten para admitir por completo la función.
Este proceso funciona bien para Target.com, ya que, cuando llega el momento en que la versión mínima de la función se usa lo suficiente, ya no se necesita la mejora progresiva y se puede usar la función. Durante una auditoría reciente, se descubrió que Target.com enviaba demasiados polyfills innecesarios, por lo que implementar Baseline en su aplicación puede ayudar a mantener bajo control este tipo de deuda técnica.
Correlación de los conceptos de Baseline con el rendimiento web
El rendimiento es importante para cualquier sitio web de venta minorista. Una creencia que comparten los desarrolladores que trabajan en Target.com es que se envía demasiado JavaScript. Si se eliminara el 5% de los paquetes de JavaScript que se envían a los usuarios, sería un gran logro, pero no mejoraría significativamente las Core Web Vitals en Target.com. Sin embargo, si Target lograra esto 10 veces, se obtendría una disminución del 50% en los tamaños de los paquetes, lo que contribuiría significativamente a los objetivos de rendimiento de Target.
En cuanto al enfoque de Baseline de Target, permitió que los ingenieros de Target.com comenzaran a pensar en la cantidad de JavaScript que se utiliza para elementos como modales, necesidades de accesibilidad, ventanas emergentes, carruseles, acordeones y otras preocupaciones comunes de la experiencia del usuario. Cada uno de estos requiere polyfills o soluciones personalizadas de JavaScript que contribuyen al aumento del código JavaScript de una aplicación. Como Target usa Baseline, los objetivos de los navegadores evolucionan con el tiempo y se pueden relajar las políticas para incluir funciones más nuevas. El objetivo es transpilar menos código con el tiempo, incluir menos polyfills y hasta adoptar componentes web cuando surjan las oportunidades. Al prestar atención a los polyfills y a los navegadores segmentados incluidos en las cadenas de herramientas del proyecto, el tamaño del paquete de JavaScript de Target.com ya se redujo en un 10%. Esto es antes de adoptar cualquier función más reciente. Esto debería mejorar año tras año, y se correlaciona directamente con las grandes apuestas que Target está haciendo en mejoras de rendimiento para Target.com.
Conclusiones
Tener un objetivo de referencia y generar informes de referencia muy bien seleccionados sobre las funciones web recién disponibles y ampliamente disponibles ha sido una herramienta poderosa para Target.com. Estos son algunos resultados clave:
- El objetivo del navegador se trasladó de los navegadores compatibles lanzados hace 8 años a los lanzados hace 3 años.
- El objetivo de referencia de Baseline 2022 se alcanzará a fines de 2025.
- El tamaño total de los paquetes de JavaScript de Target.com se redujo en un 10%.
- La cola larga de navegadores antiguos que proporcionan menos del 1% del negocio se reduce a una velocidad de aproximadamente el 300% por año (del 0.94% en septiembre de 2024 al 0.32% en noviembre de 2025).
La constatación de que la Web se mueve más rápido que nunca impulsó a Target a adoptar funciones con la mayor rapidez posible. Organizar estas funciones permite trabajar y planificar con anticipación el momento en que Target desbloquee cada una, y les da confianza a los ingenieros que contribuyen a un gran sitio web de venta minorista para saber qué funciones usar y cuándo pueden usarlas.