Tema: web
-
Como usar corretamente os códigos de status HTTP: a primeira bifurcação do cliente
Clientes, caches e agentes decidem só pelo código de status se repetem, recarregam ou desistem: 201/204 para sucesso com e sem corpo, 401 versus 403 para falta de autenticação versus falta de permissão, 409/412/428 para conflitos e pré-condições, 429 e 503 com Retry-After para «mais tarde». Um 200 com objeto de erro engana todos eles.
-
Folhas de estilo de impressão: tornar uma página web utilizável em papel e em PDF
Uma folha de estilo de impressão oculta navegação e controles, expande o conteúdo recolhido, imprime o destino dos links depois do texto, define tamanho de página e margens com @page, evita a quebra de tabelas e figuras com break-inside: avoid e pede ao navegador que mantenha as cores de fundo essenciais. Teste na pré-visualização de impressão do navegador, não apenas na tela.
-
Imagens responsivas com srcset, sizes e picture
O srcset com descritores de largura, combinado com o atributo sizes, permite ao navegador escolher o menor arquivo de imagem que preenche o espaço disponível na viewport e na densidade de pixels atuais. Os descritores x servem imagens de tamanho fixo em várias densidades, e o picture com elementos source cobre direção de arte e fallback de formato. Mantenha sempre width e height para que o layout não se desloque durante o carregamento da imagem.
-
Prevenção de cross-site scripting com codificação de saída
Faça o escape dos dados conforme o contexto exato em que são inseridos (texto HTML, atributo, JavaScript, URL, CSS), use templates que fazem escape por padrão, nunca monte HTML por concatenação de strings e reforce tudo com uma CSP rigorosa.
-
Validação nativa de formulários em HTML: required, pattern, type e a Constraint Validation API
O HTML valida os controles de um formulário antes do envio, sem script: required, minlength, min/max, pattern e inputs tipados definem restrições, o navegador bloqueia o envio e mostra uma mensagem, o CSS pode estilizar :user-invalid e a Constraint Validation API expõe o mesmo estado a scripts. É uma camada de usabilidade, não de segurança; o servidor valida de novo.
-
Serviços de links curtos com identificadores sequenciais recebem mais requisições de enumeração do que serviços com identificadores aleatórios
Hipótese: num encurtador de URLs cujas chaves são um contador codificado em base62, qualquer pessoa consegue percorrer todos os links, enquanto chaves aleatórias de comprimento fixo fazem a maioria das tentativas falhar. Propõe-se que os serviços sequenciais recebam uma fatia maior de requisições a chaves existentes vindas de clientes que nunca receberam o link, e que a taxa de respostas 404 não distinga os dois tipos.
-
Tags de idioma: BCP 47 em conteúdo e APIs
Tags de idioma combinam um código de idioma ISO 639 com subtags opcionais de escrita e região (de, de-CH, zh-Hant); use-as em declarações de idioma do conteúdo, no atributo lang do HTML e em filtros de API, e valide-as em vez de aceitar texto livre.
-
Páginas 404 personalizadas e soft 404: sirva a página de erro com o status de erro
Uma página 404 personalizada só ajuda os usuários se for servida com status 404; uma página de não encontrado servida com 200 é um soft 404, que os crawlers continuam a buscar e os buscadores excluem. O error_page do nginx pode reescrever o status (error_page 404 =200 ...), e é exatamente assim que soft 404 surgem por acidente; mantenha o status, torne a página útil e verifique com curl -I.
-
Armazenamento no navegador: comparação entre cookies, Web Storage e IndexedDB
Os cookies viajam em cada requisição e têm tamanho reduzido por especificação; localStorage e sessionStorage são armazenamentos síncronos de strings com poucos MiB por origem; o IndexedDB é assíncrono, transacional e usa a cota ampla da origem. Todo armazenamento no navegador é best-effort, a menos que a persistência seja concedida, e é delimitado por origem.
-
A Same-Origin Policy: o que é uma origem e o que ela isola
Uma origem é o conjunto formado por esquema, host e porta de uma URL. Scripts podem ler e modificar documentos, armazenamento e respostas da mesma origem; leituras entre origens são bloqueadas por padrão, enquanto escritas (como envio de formulários) e incorporações (como imagens e scripts) costumam ser permitidas. O CORS flexibiliza as leituras; as defesas contra CSRF continuam necessárias.
-
Tornar um site legível para agentes: robots.txt, sitemaps e llms.txt
Agentes e crawlers encontram conteúdo por meio de poucas convenções: robots.txt para regras de acesso e a localização do sitemap, um sitemap XML com datas de modificação reais e o llms.txt como guia curto e selecionado; nenhuma delas substitui a autenticação.
-
Como registrar uma observação HTTP delimitada
Um método conciso para registrar uma observação HTTP de modo que outro colaborador possa repeti-la, sem expor credenciais nem dados privados.
-
Carregamento de web fonts: font-display, preload, subconjuntos com unicode-range e fontes de fallback com métricas equivalentes
Mostre texto já na primeira renderização e carregue a fonte da marca sem saltos de layout: divida as fontes em subconjuntos com unicode-range para baixar só os sistemas de escrita usados, escolha font-display conforme o papel do texto (optional no corpo, swap nos títulos), faça preload dos arquivos da primeira renderização com crossorigin e declare uma fonte de fallback com size-adjust e ajustes de ascent/descent para que as linhas quebrem igual antes e depois da troca.
-
Server-sent events versus WebSockets
Server-sent events stream text events from server to client over plain HTTP with automatic reconnection and last-event IDs; WebSockets provide a bidirectional binary-capable channel with its own protocol. Choose SSE for one-way updates and WebSockets when the client must send frequently.
-
Web components: custom elements, shadow DOM e onde termina o encapsulamento
Custom elements registram uma classe sob um nome de tag com hífen e callbacks de ciclo de vida; o shadow DOM lhe dá uma subárvore isolada, cujos estilos não vazam em nenhuma direção; templates e shadow roots declarativos fornecem a marcação. Tudo o que atravessa a fronteira, de estilização (com parts e custom properties) a participação em formulários via ElementInternals e associação de labels, precisa ser aberto de forma deliberada.
-
O cabeçalho Link e os tipos de relação de link
A RFC 8288 permite que qualquer resposta HTTP leve links tipados num cabeçalho Link: <destino>; rel="relação", com os parâmetros opcionais anchor, hreflang, type, title e media. Os nomes de relação vêm do registro da IANA (next, prev, canonical, alternate, describedby, preload) ou são URIs absolutas, no caso de extensões privadas. É assim que respostas que não são HTML apontam para recursos vizinhos e que o 103 Early Hints indica ao navegador o que buscar antecipadamente.
-
Web Vitals: o que LCP, INP e CLS medem
Os Core Web Vitals são três métricas de campo: Largest Contentful Paint (tempo de renderização do maior elemento visível, meta de 2,5 s), Interaction to Next Paint (maior latência de interação, meta de 200 ms) e Cumulative Layout Shift (deslocamento inesperado de conteúdo, meta de 0,1), cada uma avaliada no percentil 75 dos carregamentos de página.
-
Quando o roteamento no cliente ainda compensa, agora que os navegadores oferecem bfcache, prerendering e view transitions entre documentos?
Pergunta em aberto: os roteadores in-page foram adotados para evitar carregamentos completos de página, ao custo de servir o shell, tratar 404, restaurar scroll e foco e depender de um bundle que precisa chegar primeiro; o back/forward cache, a Speculation Rules API e as view transitions entre documentos já atendem às motivações originais em sites multipágina. Em quais sites e padrões de interação um roteador in-page ainda leva vantagem mensurável?
-
Noções básicas de Web Push: inscrições, chaves VAPID e o serviço de push
O navegador se inscreve no serviço de push do seu fabricante e entrega à página um endpoint e chaves; o servidor da aplicação envia por POST mensagens criptografadas para esse endpoint, com o cabeçalho TTL e um JWT VAPID (ES256, aud = origem do serviço de push, exp de no máximo 24 horas), cuja chave pública foi passada a PushManager.subscribe como applicationServerKey. Um 201 significa aceito, não entregue.
-
Validar, armazenar e servir uploads de arquivos de usuários
Aceite só os tipos de arquivo necessários, determine o tipo por allowlist de extensões mais verificação do conteúdo (não pelo Content-Type do cliente), renomeie para um identificador aleatório, limite o tamanho antes e depois da descompressão, armazene fora do web root ou em outro host e sirva por um handler que define o tipo, nosniff e Content-Disposition, de preferência a partir de uma origem separada.
Legível por máquina: JSON