Osiedle Norweskie - sitio web para urbanización residencial

Osiedle Norweskie combina viviendas unifamiliares, comunidad privada y un entorno verde cerca del lago en Koszalin. La promoción la levanta Firmus Group en el barrio de Jamno, en la calle Gradowa, al norte de la ciudad. La arquitectura usa una forma tradicional y atemporal, con fachadas cálidas, tejados oscuros y detalles en madera. El sitio tenía que mostrar esa calma, explicar la oferta residencial y facilitar el contacto con personas interesadas en vivir cerca de la naturaleza, aire fresco y espacios familiares.

#Osiedlenorweskie.pl, tecnología para una urbanización residencial en Koszalin

Osiedlenorweskie.pl se preparó como sitio de presentación para una urbanización cerrada. La construcción ocupó unas seis semanas y el encargo llegó con el layout ya resuelto por el cliente, que marcó qué elementos aparecen en cada vista. A partir de ahí trabajé en lo que no se ve en un layout: el modelo de contenido, el comportamiento responsive de cada plantilla y la forma en que el administrador cambia una ficha sin llamar a nadie.

Merece la pena decir qué tipo de encargo es este, porque condiciona todas las decisiones posteriores. No es una tienda ni una aplicación con sesiones de usuario. Es un catálogo pequeño, muy visual, que una misma persona consulta durante meses antes de tomar una decisión de compra que cuesta más que cualquier otra que tome en su vida. Ese perfil de uso ordena las prioridades técnicas de una manera bastante distinta a la habitual.

#Quién vuelve a esta página, y desde qué conexión

Nadie compra una casa en la primera visita. La misma persona entra doce o quince veces a lo largo de varios meses y cada vez busca una cosa distinta: hoy el plano de la planta baja, la semana que viene la distancia al colegio, más adelante las fotos de la obra para comprobar en qué punto están los trabajos. De ahí salen dos requisitos que no aparecen en ningún briefing pero que determinan el resultado.

El primero es que las direcciones de las fichas de vivienda tienen que ser estables. Alguien las guarda en marcadores y se las manda a su familia por mensaje. Una dirección que cambia al reorganizar el menú convierte ese mensaje en un error 404 meses después, justo en el momento en que la conversación familiar estaba avanzando.

El segundo requisito es la frecuencia de publicación. Si el motivo de volver son las fotos de obra, entonces subir fotos de obra tiene que costar dos minutos y no media tarde. Cualquier modelo de contenido que obligue a rellenar ocho campos para publicar cuatro imágenes acaba sin usarse, y la sección muere sola.

A esto se suma el dispositivo. Buena parte del tráfico llega desde el teléfono, a menudo con cobertura irregular, porque Jamno queda en el extremo norte de Koszalin. Una página que en un escritorio carga en un segundo puede tardar bastante más en el borde de la cobertura, y el visitante no distingue la culpa del operador de la culpa del sitio.

#Cuatro proyectos de vivienda, y de ahí sale el modelo de contenido

La decisión más importante se tomó antes de escribir la primera línea de plantilla y consistió en definir qué es aquí una unidad de contenido. La urbanización prevé cuarenta y ocho viviendas sobre parcelas de entre seiscientos cincuenta y mil doscientos metros cuadrados, pero no son cuarenta y ocho proyectos distintos. La promotora ofrece cuatro tipos, con nombres de ciudades noruegas: Alesund de 125,72 metros cuadrados, Bergen de 136,34, Oslo de 152,12 y Trondheim de 178,70.

Si cada casa fuese un registro independiente con su descripción, su plano y su galería, cualquier cambio en el estándar de acabado del tipo Bergen obligaría a corregir una docena de entradas, y tarde o temprano alguien corregiría solo la mitad. Con el tipo de vivienda como registro y la casa concreta como una aparición suya, la descripción se escribe una vez, mientras que el número de parcela, la superficie del terreno y el estado de disponibilidad quedan como campos que edita cualquiera.

El coste de esa decisión también hay que nombrarlo. Cuando aparece una vivienda atípica, por ejemplo un plano reflejado porque la forma de la parcela lo exige, el modelo necesita una excepción, y una excepción dentro de un modelo bien cerrado sale más cara que dentro de uno laxo. Lo di por bueno porque los casos raros son unos pocos y los normales son varias decenas.

#Galerías y planos, la parte más pesada del sitio

La carga real de esta página son las imágenes, y eso no es una opinión sino una consecuencia de lo que la página es. Quien busca casa mira fotos y planos, no lee párrafos. Las galerías se construyeron como tipos de contenido a medida con planos y fotografías, que se añaden sin recargar la vista y cuyos tamaños elige el navegador según el ancho real de la pantalla.

Esos tamaños importan más que el formato del archivo, aunque el formato sea lo que genera más conversación. Una fotografía de dos mil píxeles de ancho mostrada en una tarjeta de cuatrocientos consume lo mismo se use el códec que se use. Solo después de servir la variante correcta tiene sentido discutir compresión, y solo entonces pasar a un formato moderno como AVIF produce una diferencia visible.

Los planos plantearon un problema aparte. Llegan del estudio de arquitectura como archivos pensados para imprimir, con líneas finas y cotas que en la pantalla de un teléfono no se leen. Reducir el archivo no arregla nada, porque junto con el peso desaparece la legibilidad de las medidas. La salida fue separar la vista previa del documento completo: en la ficha se ve un plano simplificado, preparado para pantalla, y el archivo imprimible se descarga de forma deliberada, con un clic, cuando el visitante ya sabe que esa casa le interesa.

#El mapa del entorno, y dónde termina su utilidad

El módulo de mapa está construido sobre Leaflet, con los datos del entorno en GeoJSON y las teselas servidas desde Mapbox. En un sitio de promoción inmobiliaria el mapa responde a una sola pregunta, qué hay cerca, y es una pregunta que un dibujo contesta mejor que cualquier descripción escrita.

Conviene saber dónde está el límite. Una capa vectorial con muchos puntos puede bloquear la interfaz en un teléfono modesto, porque el navegador intenta dibujarlo todo antes de devolver el control. Limitar los datos al entorno real de la promoción y cargar el mapa solo cuando el visitante llega a esa sección cuesta una petición adicional y ahorra varios segundos de bloqueo en la primera apertura. Es el tipo de compromiso que sobre una conexión rápida parece innecesario y que sobre una lenta decide si alguien se queda.

#Tres capas de caché, y qué las invalida

La instalación usa memoria intermedia en varios niveles y cada uno atiende un tipo de petición distinto. Cloudflare, como capa de borde, sirve los archivos estáticos y las páginas anónimas, es decir, casi todo el tráfico que llega del buscador. Varnish, delante de la aplicación, guarda las vistas de listado ya compuestas, que cuestan varias consultas a la base de datos. Redis acorta esas consultas para lo que de todas formas tiene que pasar por PHP. Fastly y Memcached completan el reparto, el primero para imágenes y planos en paralelo, el segundo para respuestas pequeñas de la API.

Tres niveles en un sitio de este tamaño suenan a exceso hasta que se mira qué cambia y con qué frecuencia. La descripción de un tipo de vivienda no se toca en un año. El estado de disponibilidad de una casa concreta cambia el día que se firma el contrato, y el comercial espera verlo reflejado de inmediato. Si todo viviera en el mismo saco, cada cambio de estado expulsaría también el contenido inmutable, y la caché dejaría de existir en la práctica.

Por eso la invalidación es puntual y va enganchada al guardado del registro concreto, no al guardado de cualquier cosa. El error más común que veo en instalaciones así es precisamente una caché que funciona, que se vacía entera cada vez que alguien toca un texto, y que por tanto obliga al servidor a recalcularlo todo varias decenas de veces al día mientras la configuración parece correcta.

#El formulario y el recorrido de una consulta

El formulario recoge preguntas sobre una casa concreta o sobre un tipo de vivienda, con validación en el servidor y protección antispam. La validación en el navegador es comodidad para quien escribe, no una medida de seguridad, así que la misma regla se aplica otra vez del lado del servidor.

Hay algo más importante que eso. La consulta tiene que saber de dónde viene. Un mensaje que dice “les ruego me llamen”, sin la información de que se envió desde la ficha del tipo Oslo, obliga al comercial a devolver la llamada para preguntar algo que la página ya sabía. El contexto de la vivienda se adjunta automáticamente al envío, y una copia se guarda en la base de datos con independencia de que el correo salga o no. Un servidor de correo puede estar caído unos minutos y eso no es motivo para perder un contacto.

#Visibilidad local, y la trampa de un nombre propio

El nombre Osiedle Norweskie es reconocible, y eso ayuda hasta que uno mira qué escribe la gente de verdad en el buscador. Quien ya conoce el nombre llega solo. Quien apenas está considerando mudarse escribe otra cosa: casas en Koszalin, urbanización cerrada Koszalin, casa en venta Jamno. Un sitio construido únicamente alrededor del nombre propio atiende solo a quienes ya han decidido.

Por eso la estructura de direcciones y encabezados tenía que decir también qué es esta promoción, no solo cómo se llama. La ficha habla de viviendas unifamiliares en un recinto cerrado de Koszalin y nombra el barrio de forma explícita, en lugar de darlo por sabido. No es un truco para el algoritmo, es una atención hacia quien no vive en esa ciudad y no tiene por qué saber dónde queda Jamno.

La segunda trampa está en los datos estructurados. Resulta tentador describir cada casa como una oferta con precio, porque los buscadores manejan bien ese formato. El problema es que el precio de una vivienda con parcela cambia durante la fase comercial, y un dato que ya entró en el índice vive por su cuenta durante semanas. Un precio caducado en un resultado de búsqueda inicia la conversación con una rectificación, que es el peor arranque posible. La página describe tipo, superficie y disponibilidad, y deja el precio para una conversación con una persona.

#Lo que se dejó fuera a propósito

Sin esta sección, la descripción de un proyecto es un folleto. No se construyó un configurador de acabados, aunque la idea volvió en cada fase. Un configurador tiene sentido cuando las variantes están contadas y descritas en un único sitio del lado del cliente, y cuando de ahí sale un precio sin telefonear a nadie. Con cuatro tipos de vivienda y acuerdos de acabado negociados caso por caso, la herramienta mostraría cifras que habría que verificar de todos modos.

Tampoco se implementó la reserva en línea. En el mercado inmobiliario una reserva sin pago no es una reserva, es una cola, y una cola visible en público genera más conflictos que ventas. El estado de disponibilidad es aquí una información, no una acción, y lo cambia una persona del lado de la promotora.

La tercera ausencia son las opiniones de los residentes. Con una primera fase de seis viviendas, cualquier opinión publicada es atribuible a una familia concreta por simple aritmética. En su lugar, el sitio muestra el avance de obra y fotografías de casas terminadas, que dicen lo mismo sin pedirle a nadie que se exponga.

#Soporte técnico y mantenimiento

Osiedlenorweskie.pl no es una pieza estática. El sistema y los complementos se actualizan probándolos primero fuera de producción, con copias diarias en S3 gestionadas mediante UpdraftPlus y cifradas. Conviene decir en voz alta algo que se suele callar: una copia de seguridad que nunca se ha restaurado es una hipótesis, no una protección. La presencia de los archivos en la nube no garantiza nada mientras nadie compruebe que el volcado de la base importa y que con él llegaron también los ficheros de medios.

El orden de las actualizaciones es la otra parte aburrida que salva el proyecto. En un sitio con tema a medida y tipos de contenido propios, lo que se rompe al subir una versión casi nunca es el núcleo de WordPress, sino la plantilla, en el punto exacto donde asumía una estructura de datos que un complemento acaba de cambiar. Yoast SEO se encarga de los metadatos y del mapa del sitio, Lighthouse vigila la calidad de carga dentro del proceso de integración, y la configuración de caché se revisa cuando cambia la forma del contenido, porque es el contenido y no el paso del tiempo lo que estropea una estrategia de caché.

El sitio admite ampliaciones, desde un recorrido virtual hasta una integración con el sistema comercial o una sección de viviendas disponibles actualizada desde un único lugar. La pregunta con la que empieza cada una de ellas es siempre la misma: cuánto contenido habrá que mantener después del lanzamiento, porque ese es el coste que aparece en el segundo año y no el del código. Si está preparando el sitio de una promoción residencial, ¿sabe ya quién va a actualizarlo cada semana cuando la obra avance?