Compatibilidad con navegadores según Baseline, bien hecha

Puntos clave

• Navegadores principales: Chrome, Edge, Firefox y Safari en escritorio y móvil
• Disponible recientemente: la funcionalidad funciona en las últimas versiones de todos los navegadores principales
• La medida más útil: adopte el nivel «ampliamente disponible» de Baseline como política de compatibilidad predeterminada.
• Error más común: dar soporte a navegadores que, según sus analíticas, no utiliza nadie.
• Recurra a ayuda cuando alguna de las situaciones descritas en «Cuándo recurrir a ayuda», más abajo, corresponda a su proyecto.

Por qué es importante

Sustituye las conjeturas sobre la compatibilidad con navegadores por una señal clara y fechada que los equipos pueden adoptar como política.

Las cifras, en un solo lugar

Las cifras siguientes son las publicadas, no las que circulan en las presentaciones comerciales.

Cómo es un buen resultado

Lo que sigue es la parte práctica: lo que el trabajo realmente le exige.

• Adopte el nivel «ampliamente disponible» de Baseline como política de compatibilidad predeterminada
• Use las funcionalidades disponibles recientemente con alternativas de respaldo
• Documente las excepciones para los navegadores de su propio público
• Compruebe el estado de Baseline en MDN antes de adoptar funcionalidades
• Revise su política cada año

Qué evitar

Los errores de rumbo habituales. Algunos son más tentadores que otros.

• Dar soporte a navegadores que, según sus analíticas, no utiliza nadie
• Usar funcionalidades totalmente nuevas sin alternativa de respaldo
• Bloquear funcionalidades útiles por suposiciones obsoletas
• Usar polyfills para funcionalidades que ya están ampliamente disponibles

Dónde se sitúa esto en el diseño y desarrollo web

La compatibilidad con navegadores según Baseline es una parte de cómo abordamos el trabajo de diseño y desarrollo web. Rara vez llega de forma aislada: las decisiones anteriores interactúan con todo lo demás del proyecto, por lo que conviene resolverlas pronto y no en la fase de revisión.

Para quién es realmente

Esta página da por hecho que tiene que tomar una decisión real sobre la compatibilidad con navegadores según Baseline, no que le interesa en el plano académico. Eso condiciona todo lo que sigue.

Cualquiera de esos es un buen motivo para estar aquí. Lo que sigue lo cubre todo: en qué consiste el trabajo, cuánto cuesta en EE. UU., cuánto tiempo lleva, qué necesitamos de usted y cómo saber si lo que recibe es bueno. Vaya directamente a la parte que necesite.

Cuando lo ocasional se vuelve continuo

Suele llegar un momento en que el diseño y desarrollo web deja de ser algo que se gestiona entre otras tareas y pasa a ser un trabajo en sí mismo. Normalmente se parece a esto:

• El trabajo recae en alguien que en realidad se dedica a otra cosa, y su verdadero trabajo está quedando desatendido.
• El volumen ha dejado de ser ocasional y se ha vuelto semanal.
• La calidad varía según quién estuviera libre ese día.
• Está rechazando oportunidades porque la producción no da abasto.
• Se repite una y otra vez la misma corrección porque nadie dejó por escrito cómo hacerla bien.
• Está pagando licencias de software que se usan unos pocos días al mes.

Si dos o tres de estas situaciones se cumplen, la pregunta en realidad no es si buscar ayuda. Es si contratar a alguien, recurrir a un freelance o trabajar con un estudio, y más abajo hay una sección que expone las ventajas y desventajas con honestidad, incluidos los casos en los que contratarnos no es la respuesta correcta.

Cómo se desarrolla realmente el trabajo

Así es un proyecto de diseño y desarrollo web visto desde dentro. Conocer el orden importa, porque casi todos los calendarios que se retrasan lo hacen en los mismos dos o tres puntos.

1. Descubrimiento

Averiguamos para qué sirve el sitio, a quién va dirigido y qué tiene que cumplirse para considerar que funciona. Normalmente basta con un par de llamadas y un vistazo a la analítica que ya exista. El objetivo es un documento de una página que describa el encargo y en el que ambas partes se reconozcan.

2. Contenido y estructura

Qué va en el sitio y cómo lo encuentra la gente. Esto va antes del diseño a propósito: maquetar cajas antes de que nadie sepa qué las llenará es la manera de acabar con una página preciosa que no puede albergar su contenido real.

3. Diseño

Wireframes y después diseño visual, normalmente empezando por el ancho de un teléfono. La mayoría de sus visitantes usan el móvil, y una maquetación que funciona en pequeño casi siempre se amplía con más soltura que una que hay que comprimir.

4. Desarrollo

Código front-end, plantillas y la configuración de la gestión de contenidos. Todo construido de forma semántica para que el marcado signifique algo para un lector de pantalla y un motor de búsqueda, no solo para un navegador.

5. Carga de contenido

Textos reales e imágenes reales, no texto de relleno. Aquí es donde se retrasan la mayoría de los calendarios, y casi siempre por parte del cliente, así que conviene empezar durante el desarrollo y no después.

6. Pruebas

Dispositivos reales, navegación con teclado, lector de pantalla, conexión lenta. Y lo aburrido: que los formularios se envíen de verdad, que las redirecciones redirijan de verdad y que la analítica registre de verdad.

7. Lanzamiento

DNS, certificados, redirecciones desde cada URL antigua, verificación en Search Console. El mapa de redirecciones es la parte que se olvida, y es la que cuesta tráfico.

8. Seguimiento posterior

Observar las primeras semanas de tráfico real, corregir lo que solo el uso real revela y entregar suficiente documentación para que no dependa de nosotros para cambiar un número de teléfono.

¿Dónde encaja la compatibilidad con navegadores según Baseline? Normalmente, en algún punto intermedio de esa secuencia, y hereda todas las decisiones tomadas antes. Por eso conviene definir el alcance pronto: un cambio en la etapa dos es una conversación; el mismo cambio en la etapa siete es una reconstrucción.

Las cifras y de dónde provienen

Son umbrales publicados, no opiniones nuestras. Cuando un organismo de normalización o una plataforma ha establecido una cifra, esa cifra figura aquí y el organismo se cita al pie de la página. Cuando nadie ha publicado ninguna, no encontrará una cifra inventada para rellenar el hueco.

Cuánto cuesta en EE. UU.

Primero los precios, porque es lo que ha venido a buscar. Estos son los rangos del mercado estadounidense para diseño y desarrollo web. Su cifra quedará en algún punto dentro de ellos según los factores que se indican a continuación.

Son rangos amplios, y lo son por una razón. Esto es lo que lleva un trabajo de un extremo al otro.

Qué determina realmente el precio

Número de plantillas únicas

Un sitio de cincuenta páginas con seis plantillas es un trabajo mucho menor que uno de doce páginas con once. Cuente maquetaciones, no páginas.

Disponibilidad del contenido

Un sitio con los textos y las imágenes listos avanza aproximadamente al doble de velocidad que uno cuyo contenido se redacta durante el desarrollo.

Integraciones

Un CRM, un sistema de reservas, una pasarela de pago, un feed de inventario heredado. Cada uno es un contrato aparte con la API de otro y con las caídas de otro.

Objetivo de accesibilidad

Cumplir WCAG 2.1 AA desde el principio encarece moderadamente el diseño y el desarrollo. Adaptarlo más adelante cuesta varias veces más.

Migración

Trasladar mil páginas existentes conservando sus URL y su formato es un proyecto en sí mismo, con sus propios riesgos.

Quién lo mantiene

Crear algo que usted pueda editar con seguridad cuesta más al principio que crear algo que solo nosotros podamos cambiar. Casi siempre es la opción más barata de las dos a tres años vista.

Cómo se suele estructurar el pago

Aparte de cuánto, está la cuestión de cómo. Cinco modelos cubren casi todo en este sector, y el adecuado depende de lo bien que se pueda describir el trabajo antes de empezar.

Por unidad

Un precio fijo por imagen, por minuto, por página, por recurso. Es la mejor opción cuando el trabajo es realmente repetible y usted puede describir una unidad con precisión. Es el modelo más fácil de presupuestar y el que más se presta a discusión, porque todo depende de si su idea de una unidad coincide con la nuestra. Resuélvalo con una muestra antes de resolverlo en una factura.

Tarifa por hora o por día

Usted compra tiempo, y el resultado es lo que ese tiempo produzca. Es honesto cuando todavía nadie puede definir el alcance: un rescate, un archivo desconocido, una fase exploratoria. Pida de todos modos un tope máximo. Un acuerdo por horas abierto y sin techo es un presupuesto sin fondo.

Tarifa fija por proyecto

Una sola cifra para un alcance definido, normalmente con un número determinado de rondas de revisión. Es el modelo que prefieren la mayoría de los clientes y el que más castiga un brief vago. La tarifa solo es fija si el alcance lo es, así que espere que el documento de alcance sea más específico de lo que resulta cómodo. Esa especificidad es lo que le protege.

Iguala mensual

Una cantidad fija de capacidad reservada para usted cada mes. Vale la pena cuando el trabajo es continuo y no ocasional: un catálogo que se renueva, un canal que publica cada semana, un sitio que no deja de cambiar. Por debajo de unas diez a quince horas al mes, normalmente cuesta más que comprar el trabajo a medida que surge.

Basado en valor o resultados

Precios vinculados a un resultado de negocio y no al esfuerzo. Es poco común, y rara vez tan limpio como parece. Funciona cuando el resultado es inequívoco y atribuible, y se desmorona cuando no es ninguna de las dos cosas. Trate una propuesta basada en resultados con el mismo escrutinio que aplicaría a cualquier otra afirmación sobre atribución.

Si quiere una cifra real en lugar de un rango, la vía más rápida es enviarnos el briefing real: alcance, volumen, fecha límite y un par de archivos de muestra si los tiene. Normalmente eso basta para darle un precio fijo en lugar de una estimación.

Cuánto tiempo lleva

La versión honesta de un calendario. Las fases se solapan, y la que se retrasa rara vez es aquella para la que se presupuesta un margen extra.

Algo que conviene decir claramente: la causa más común de un proyecto retrasado no es la producción. Es la espera: de contenidos, de una decisión, de que una persona revise algo. Si quiere que un proyecto avance rápido, lo más eficaz que puede hacer es designar a una persona que pueda dar el visto bueno y asegurarse de que esté disponible. Ese único cambio vale más que cualquier cantidad de seguimiento.

Los trabajos urgentes son posibles y de verdad son más caros, porque implican personas reales haciendo horas extra reales o un trabajo que se salta una cola en la que hay otra persona. Siempre le diremos lo que cuesta realmente una urgencia antes de que se comprometa.

Qué enviarnos

Todo lo que sigue son cosas que solo usted sabe. Reunirlas en un solo lugar al principio ahorra más tiempo que cualquier cosa que cualquiera de nosotros pueda hacer después.

Qué debe incluir el brief

Para quién es

El público, en una frase, con sus propias palabras. No un documento de buyer persona: una frase.

Qué tiene que lograr

La acción que quiere que alguien realice, o la decisión que quiere que pueda tomar.

Dónde se va a usar

Cada ubicación, en cada tamaño. Es la omisión más común, y la que provoca repetir sesiones de fotos y recortes.

Qué existe ya

Guías de marca, trabajos anteriores, los archivos que no le gustan a nadie. Sobre todo los archivos que no le gustan a nadie, y por qué.

Qué es fijo

Colores, tipografías, textos legales, requisitos de plataforma, cualquier cosa que no esté sujeta a discusión.

Cómo es un buen resultado

Dos o tres referencias, más un ejemplo de algo que le desagrade de verdad. Lo que no le gusta es más útil que lo que le gusta.

La fecha límite real

La fecha en que algo tiene que estar publicado, no la fecha en que le gustaría ver un borrador. Indique cuál de las dos nos está dando.

Quién da la aprobación final

Un nombre. Un brief con cuatro aprobadores y nadie que decida es un brief que le costará dos rondas de revisión adicionales.

Dos de ellos merecen especial atención, porque son los que cuestan dinero cuando faltan. Dónde se va a usar (cada ubicación, en cada tamaño) es la omisión que provoca repetir sesiones de fotos y recortes. Y quién da la aprobación final es lo que añade rondas de revisión sin que nadie lo note: un proyecto con cuatro aprobadores y nadie que decida siempre costará más que uno con un solo nombre.

Específico de la compatibilidad con navegadores según Baseline

Además del brief general, este trabajo en particular sale ganando si usted ha decidido lo siguiente antes de que nadie empiece:

• Adopte el nivel «ampliamente disponible» de Baseline como política de compatibilidad predeterminada
• Use las funcionalidades disponibles recientemente con alternativas de respaldo
• Documente las excepciones para los navegadores de su propio público
• Compruebe el estado de Baseline en MDN antes de adoptar funcionalidades

Si ya tiene archivos listos, puede enviárnoslos directamente: van a un almacenamiento privado y no a una bandeja de entrada, y nada es público. Si prefiere ver el nivel antes de comprometerse a nada, pruébenos primero con un par de archivos. Sin tarjeta, sin compromiso, y si no es lo que necesita, no habrá perdido más que una tarde.

Cómo revisar lo que recibe

Merece la pena leer esta sección aunque nunca contrate a nadie. Revisar mal sale caro, haga quien haga el trabajo.

Revíselo donde se va a usar

Apruebe un recurso web en un navegador, un recurso impreso en papel, una mezcla de audio en el altavoz de un teléfono. Aprobar un entregable en la herramienta con la que se creó es la forma en que los problemas llegan al público.

Revise los bordes, no el centro

El centro casi siempre está bien. Fíjese en las esquinas, el tamaño más pequeño, la cadena de texto más larga, la zona más oscura, los últimos diez segundos.

Revise una cosa cada vez

Color, luego tipografía, luego espaciado, luego contenido. Una revisión que intenta verlo todo a la vez ve lo más llamativo y pasa por alto el resto.

Reúna los comentarios antes de enviarlos

Una sola lista consolidada es mejor que seis correos. Las contradicciones dentro de su propia organización se resuelven más barato de su lado que del nuestro.

Sea específico sobre lo que está mal

“Que resalte más” cuesta una ronda de revisión. “El titular se lee mal sobre el cielo, ¿podemos oscurecer la zona que tiene detrás?” cuesta diez minutos.

Diga también lo que está bien

No por cortesía. Si solo señala problemas, en la siguiente ronda puede perderse lo que le gustaba sin que nadie supiera que era importante.

El nivel de exigencia que nos imponemos

Para que sepa con qué está comparando, esto es lo que se revisa de nuestro lado antes de que nada le llegue. Nada de ello es opcional, y nada se cobra como extra.

• Core Web Vitals medidas en dispositivos reales: LCP inferior a 2,5 segundos, INP inferior a 200 milisegundos, CLS inferior a 0,1
• Todos los elementos interactivos accesibles y utilizables solo con el teclado, en un orden lógico
• Contraste del texto de 4,5:1 para el cuerpo y de 3:1 para el texto grande, comprobado y no supuesto
• Probado en un teléfono Android de gama media real, no solo en una ventana de navegador de escritorio estrechada
• Formularios probados de principio a fin, incluido lo que ocurre cuando fallan
• Cada URL antigua sigue funcionando o redirige una sola vez, sin cadenas

Señales de alerta específicas de la compatibilidad con navegadores según Baseline

Si ve alguna de estas en lo que le entreguen, dígalo. Todas tienen solución, y todas son más baratas de corregir ahora que después de publicar.

• Dar soporte a navegadores que, según sus analíticas, no utiliza nadie
• Usar funcionalidades totalmente nuevas sin alternativa de respaldo
• Bloquear funcionalidades útiles por suposiciones obsoletas
• Usar polyfills para funcionalidades que ya están ampliamente disponibles

Puede ver cómo presentamos el trabajo terminado, incluido el antes y el después, en el portafolio. Todo lo marcado como muestra es una pieza de demostración propia y no un proyecto de cliente, y así se indica en el elemento.

Tres situaciones que quizá le resulten familiares

Los consejos abstractos son fáciles de aceptar y difíciles de aplicar. Estas son las formas en que este tipo de problema llega realmente, y lo que haríamos en cada caso.

Un rediseño que perdió la mitad de su tráfico

El nuevo sitio se lanzó con URL nuevas y sin mapa de redirecciones. Reconstruimos el mapa a partir del antiguo sitemap y de los registros del servidor, redirigimos cada dirección antigua a su equivalente más cercano y volvimos a enviarlo. La mayor parte del tráfico volvió en un plazo de seis a diez semanas. Ninguna parte de ese tráfico tenía por qué haberse perdido.

Un sitio que nadie podía actualizar

Cada cambio de texto era un ticket para desarrollo, así que el sitio fue quedándose desfasado sin que nadie lo notara. Rehicimos las plantillas en torno a zonas editables con salvaguardas, de modo que el equipo de marketing puede cambiar textos e imágenes sin poder romper la maquetación.

Rápido en un portátil, inutilizable en un teléfono

El sitio se había probado en la estación de trabajo en la que se desarrolló. En un Android de gama media con una conexión normal tardaba once segundos en ser utilizable. Comprimir imágenes, aplazar los scripts de terceros y eliminar dos pesos de fuente sin usar lo dejaron por debajo de tres.

Ninguno de esos casos requirió heroicidades. Requirieron que alguien mirara lo correcto a tiempo, que es en gran parte lo que aporta la experiencia en este campo.

¿Equipo interno, freelance, estudio o un modelo?

Esta es la decisión que subyace a «cuánto cuesta», y merece una respuesta directa en lugar de un discurso comercial. Hay cuatro formas de sacar adelante un trabajo de diseño y desarrollo web, y solo somos la opción adecuada para algunas de ellas.

Hacerlo internamente

Lo hace alguien de su plantilla.

Lo bueno: el ciclo de retroalimentación más rápido que existe, el conocimiento más profundo del producto y nada de tiempo de briefing para cambios pequeños.

Lo no tan bueno: está comprando una persona, no un trabajo: sus vacaciones, sus días de baja, su techo y el software. Deja de tener sentido en cuanto la demanda es irregular, porque paga el pico todo el año.

Contratar a un freelance

Un especialista, contratado directamente.

Lo bueno: la forma más barata de comprar experiencia real, y trabaja con la persona que de verdad hace el trabajo.

Lo no tan bueno: una persona es un único punto de fallo. Sin suplencias, con capacidad limitada, y si se marcha a mitad del proyecto, usted hereda sus archivos y sus convenciones.

Recurrir a un estudio

Un equipo con un proceso, una capa de revisión y suplencias.

Lo bueno: gestiona volumen y variedad, se encarga del control de calidad y no desaparece cuando una persona se enferma.

Lo no tan bueno: más caro por hora que un freelance, y usted es un cliente entre varios. Vale la pena cuando la coherencia en un gran volumen de trabajo importa más que la tarifa más baja.

Usar un modelo

Herramientas generativas o automatizadas, con o sin una persona que revise.

Lo bueno: realmente rápido y realmente barato en lo que hace bien, y no se cansa en la página cuatrocientos.

Lo no tan bueno: se equivoca con total seguridad de formas difíciles de detectar a simple vista, y falla justo en lo que un cliente nota: manos, texto, cantidades, bordes, continuidad. Nada debería entregarse sin que una persona lo haya revisado, y por eso nuestro trabajo con IA se cotiza con la revisión incluida y no como un descuento.

En resumen: si el trabajo es constante y central en lo que hace, contrate a alguien. Si es irregular, o requiere una variedad de habilidades que no puede justificar tener en plantilla, recurra a un estudio. Si es una tarea especializada concreta y ha encontrado al especialista adecuado, trabaje con esa persona. Preferimos decírselo de entrada antes que aceptar un trabajo para el que no somos los adecuados.

Las normas de EE. UU. que conviene conocer

Esto no es asesoramiento legal y no somos abogados. Es una lista de las normas estadounidenses que aparecen con suficiente frecuencia en este tipo de trabajo como para que desconocerlas salga caro. Si alguna le afecta, vale la pena dedicar veinte minutos a hablar con alguien que sí sea abogado.

ADA y Section 508

Los tribunales de EE. UU. han interpretado que el Título III de la Americans with Disabilities Act abarca muchos sitios web comerciales, y las agencias federales y sus contratistas están sujetos a la Section 508, que adopta las WCAG como estándar técnico. En la práctica, eso significa diseñar conforme a WCAG 2.1 AA y poder demostrarlo.

Legislación estatal de privacidad

California, Colorado, Virginia, Connecticut y una lista creciente de otros estados tienen leyes de privacidad del consumidor con sus propios requisitos de aviso y de exclusión voluntaria. Si su sitio recopila cualquier dato, el aviso de privacidad y el comportamiento de las cookies son decisiones de ingeniería tanto como jurídicas.

Divulgación según la FTC

La Federal Trade Commission exige que las relaciones relevantes y las recomendaciones pagadas se divulguen de forma clara y junto a la afirmación. Es un problema de diseño: una divulgación que nadie ve es una divulgación que no cuenta.

Y las cuestiones comerciales generales

Sea cual sea la disciplina, contratar servicios profesionales en Estados Unidos plantea siempre las mismas preguntas. Estas son las que más nos hacen los clientes.

Contratos y declaraciones de trabajo

Una declaración de trabajo (SOW) que especifique los entregables, el número de rondas de revisión, las condiciones de propiedad y el calendario de pagos bien vale la hora que lleva leerla. La mayoría de las disputas en este sector no tienen que ver con la calidad, sino con dos personas que entendieron “terminado” de forma distinta.

Propiedad y obra por encargo

Según la ley de derechos de autor de EE. UU., la obra creada por un contratista independiente pertenece en general al contratista, salvo que exista una cesión por escrito o que encaje en una de las limitadas categorías legales de obra por encargo (work made for hire). Eso sorprende a muchos compradores. Consiga la cesión por escrito; cualquier estudio que dude le está diciendo algo útil.

Pagar a un proveedor externo

Una empresa estadounidense que paga a un contratista estadounidense normalmente solicita un formulario W-9 y puede tener que presentar un 1099-NEC; pagar a un proveedor de fuera de EE. UU. suele implicar, en cambio, un W-8BEN o W-8BEN-E. Su contador querrá tenerlos antes de la primera factura, no después de la última.

Impuesto sobre las ventas en servicios

Que un servicio creativo o digital esté sujeto a impuestos varía según el estado, y varios estados gravan algunos entregables digitales y otros no. Vale la pena hacerle una pregunta a su contador antes de un encargo grande, en lugar de recibir una carta del departamento de hacienda estatal después.

Afirmaciones publicitarias

La Federal Trade Commission considera a los anunciantes responsables de las afirmaciones de su marketing, incluidas las que se hacen mediante imágenes. Una foto de producto retocada que ya no representa el producto es un problema publicitario antes que de diseño, y la responsabilidad recae en el anunciante, no en el retocador.

Accesibilidad

Los tribunales de EE. UU. han interpretado que el Título III de la Americans with Disabilities Act abarca los sitios web en muchos casos, y las agencias federales y sus contratistas están sujetos a la Section 508, que remite a las WCAG. Es más barato incorporar la accesibilidad desde el diseño que resolverla en los tribunales.

Nuestras propias condiciones están publicadas, no se envían a petición: puede leer los términos y condiciones, las condiciones de pago, la política de reembolso y nuestra posición sobre confidencialidad y NDA antes de hablar con nadie. Si algo en ellas no le funciona, dígalo pronto: la mayor parte es negociable y todo se resuelve mejor antes del trabajo que después.

Preguntas para quien le presente un presupuesto

Incluidos nosotros. Si un proveedor se pone evasivo con alguna de ellas, esa es la respuesta a la pregunta que en realidad estaba haciendo.

¿Quién hace realmente el trabajo?

Pregunte si se queda en manos de la persona con la que está hablando, pasa a un equipo o se subcontrata. Ninguna de esas opciones está mal. No saberlo, sí.

¿Qué es exactamente una revisión?

Pregunte qué cuenta como revisión frente a un nuevo brief, y cuántas están incluidas. Es la causa más común de una factura inesperada.

¿De quién es el resultado?

Consígalo por escrito, incluidos los archivos de trabajo. “El archivo final es suyo” y “todo es suyo” son posiciones muy distintas, y la segunda cuesta más por una razón.

¿Qué pasa si está mal?

Pregunte cuánto cuesta rehacerlo y con qué rapidez se hace. Un estudio con una respuesta clara ya ha tenido esa conversación antes.

¿Puedo ver trabajos como el mío?

No un showreel: trabajos de su categoría, con su volumen y con las restricciones que usted tiene. Un portafolio precioso en otra categoría demuestra buen gusto, no que sea adecuado para usted.

¿Cómo gestionan mis archivos?

Dónde se almacenan, quién puede acceder a ellos, cuánto tiempo se conservan y qué ocurre al final. Si va a enviar algo que aún no se ha publicado, asegúrese de que esto quede recogido en el contrato.

¿Qué necesitan de mí?

Un proveedor que no sabe responder a esto no ha pensado en su parte del trabajo, y usted lo descubrirá cuando llegue la fecha límite.

Una más, y es la que a la gente más le da vergüenza preguntar: ¿qué le haría rechazar este trabajo? Un estudio que nunca ha rechazado un trabajo es un estudio que lo acepta todo, y eso le dice algo sobre el cuidado con que se va a tratar el suyo.

Los términos que le van a soltar

Cada campo tiene un vocabulario que se usa como atajo y acaba siendo una barrera. Esto es lo que significan realmente los términos habituales del diseño y desarrollo web, en lenguaje llano. No debería necesitarlo para contratar el trabajo, pero acorta la conversación.

Core Web Vitals

Las tres mediciones de experiencia de página que publica Google: la rapidez con que aparece el contenido principal, la rapidez con que la página responde a la interacción y cuánto salta la maquetación.

LCP

Largest Contentful Paint. Cuánto tarda en cargarse el elemento más grande de la pantalla. Por debajo de 2,5 segundos es el umbral «bueno» publicado.

INP

Interaction to Next Paint. Cuánto tarda la página en responder visiblemente cuando alguien toca o hace clic. Por debajo de 200 milisegundos es bueno.

CLS

Cumulative Layout Shift. Cuánto se mueve la página mientras carga. Por debajo de 0,1 es bueno, y la causa habitual de una mala puntuación es una imagen sin dimensiones.

HTML semántico

Usar el elemento que corresponde a cada cosa: un botón para un botón, un encabezado para un encabezado. Es lo que hace que una página sea navegable con lector de pantalla y legible para un rastreador.

Diseño responsive

Una sola maquetación que se adapta a la pantalla en la que se muestra, en lugar de un sitio móvil aparte.

CMS

Sistema de gestión de contenidos. El área de administración donde alguien que no escribe código cambia los textos.

Headless

Una configuración en la que el contenido reside en un sistema y el front-end se construye por separado. Más flexible, con más piezas móviles y más caro de mantener en marcha.

Mejora progresiva

Construir de modo que lo esencial funcione sin JavaScript y añadir mejoras encima. Es la razón por la que un formulario bien hecho se sigue enviando cuando un script no se carga.

Mapa de redirecciones

La lista que indica adónde apunta ahora cada URL antigua. Lo que decide si un rediseño conserva su tráfico de búsqueda o lo tira por la borda.

Hay una biblioteca de referencia más completa si quiere profundizar en cualquiera de estos términos, y todo en ella está escrito de la misma manera: con claridad y con fuentes.

Preguntas frecuentes antes de contratar

Estas son las preguntas que surgen en casi todas las consultas sobre la compatibilidad con navegadores según Baseline, con respuestas directas. Si la suya no está aquí, hágala: nadie le añadirá a una lista de correo por ello.

¿Cuánto cuesta?

Las tarifas del mercado estadounidense para diseñar y crear sitios web que cargan rápido, funcionan en un teléfono y pueden actualizar las personas que los gestionan empiezan en torno a 6.000 $ – 20.000 $ para los trabajos más sencillos y aumentan a partir de ahí según la complejidad, el volumen y el plazo de entrega. Presupuestamos por proyecto una vez que hemos visto el briefing, porque una cifra dada sin mirar los archivos es una cifra que cambia después.

¿Pueden darme un precio cerrado?

Normalmente sí, una vez que el alcance esté por escrito. Un precio cerrado requiere un alcance cerrado, así que cuente con que el documento de alcance sea más específico de lo que parece necesario. Esa especificidad es lo que le protege de una factura por modificaciones.

¿Con qué rapidez pueden empezar?

La fase de descubrimiento suele durar 1–2 semanas. Cuándo empieza depende de la cola de trabajo, y le daremos la fecha real, no la que quiere oír.

¿Qué necesitan de mí para empezar?

Un brief, los archivos y el nombre de la única persona que puede aprobar. Lo tercero importa más de lo que se suele pensar: los proyectos con una sola persona que decide terminan de forma mensurablemente más rápida que los que dependen de un comité.

¿De quién es el trabajo terminado?

Suyo, incluidos los archivos de trabajo, y así consta en las condiciones en lugar de darse por supuesto. Según la ley de derechos de autor de EE. UU., la obra de un contratista externo no se transfiere automáticamente sin una cesión por escrito, por lo que conviene comprobarlo con cualquier proveedor.

¿Y si no me gusta?

Díganos concretamente qué está mal y lo corregiremos. Las rondas de revisión se indican en el presupuesto, para que nadie tenga que adivinar. Si el estándar realmente no es lo que necesita, la política de reembolso establece por escrito qué ocurre, antes de que usted gaste nada.

¿Trabajan con clientes de EE. UU.?

Sí, y nuestro horario coincide con la jornada laboral estadounidense. Los precios se expresan en dólares estadounidenses y las entregas se especifican conforme a las normas estadounidenses aplicables (ATSC, la ADA y la Section 508, las normas publicitarias de la FTC y los requisitos de los marketplaces de EE. UU.), en lugar de los equivalentes europeos que muchos estudios aplican por defecto.

¿Puedo probar antes de comprometerme?

Sí. Envíenos un par de archivos reales y haremos el trabajo según su brief, gratis, sin tarjeta y sin compromiso. Es una prueba mejor que cualquier portafolio, porque se trata de su material y su estándar.

¿Se mantiene la confidencialidad de mi material?

Sí. Los archivos se guardan en un almacenamiento privado y no en una bandeja de entrada, no se publica nada sin su autorización y firmaremos su NDA o usaremos el nuestro, lo que usted prefiera.

¿Cuál es el motivo más habitual por el que un proyecto así se retrasa?

La espera de una decisión. No la producción, no las revisiones: la espera. Si se queda con una sola idea de esta página, que sea esa.

Adónde ir a continuación

• Líneas de versiones de Node.js y LTS: lo que realmente funciona
• Guía práctica del soporte de versiones de PHP

Cuándo recurrir a ayuda

Busque ayuda al definir una política de compatibilidad con navegadores o cuando los requisitos de navegadores antiguos frenen un proyecto.

De dónde procede esta información

• web.dev — Baseline
• MDN Web Docs — Browser compatibility

Cómo se elaboró esta página

Todas las cifras, prácticas y advertencias anteriores proceden de las normas, la documentación de plataformas y las investigaciones publicadas que se citan en De dónde procede esta información. Nada de lo aquí expuesto se deduce ni se generaliza más allá de lo que publican esas entidades: cuando dan una cifra, es su cifra, y cuando guardan silencio, nosotros también. Las páginas se actualizan cada vez que cambia la información de origen. Nuestras propias opiniones, cuando las tenemos, figuran en los casos de estudio y van firmadas.

¿Trabaja en algo similar?

Aceptamos trabajos de diseño y desarrollo web para equipos que quieren que se hagan una sola vez y bien. Cuéntenos qué está creando y le diremos con honestidad si somos el estudio adecuado. Inicie un proyecto.

Más recursos útiles

Siga estas rutas para continuar con el tema, el servicio o la guía de decisión práctica más cercanos.

• Biblioteca de artículos de Diseño y desarrollo web
• Cómo acertar con las pruebas entre navegadores
• La caché del navegador explicada para propietarios de sitios web
• Las mejores herramientas de IA para diseñadores web
• Las mejores herramientas de IA para desarrolladores web
• Consultoría de pipelines de IA frente a soporte para el ajuste fino de modelos personalizados