A lista é o produto
As telas financeiras vivem ou morrem por listas longas: uma lista de acompanhamento de centenas de ativos, um livro de ordens em atualização contínua, um histórico de trades que cresce sem limite. Os dados do Web Almanac e do Lighthouse tornam o perigo concreto. A página móvel mediana carrega cerca de 594–616 elementos DOM, e os 10% mais pesados chegam a cerca de 1.700–1.900; o Lighthouse começa a alertar acima de 800 nós e marca erro acima de 1.400–1.500. Uma única lista de 1.000 linhas renderizada à moda web pode ultrapassar todos esses limites —e cada rolagem, hover e toque obriga o navegador a recalcular estilo e layout para toda a árvore, que é exatamente como o INP (Interaction to Next Paint) desaba.
WebView renderiza cada linha como um nó
Um WebView constrói uma lista longa à moda do documento: cada linha é um nó DOM, todos vivos na memória de uma vez. Ao rolar, o navegador precisa maquetar e pintar milhares de nós, e o recálculo de estilo toca centenas de elementos por interação. Passadas algumas centenas de linhas, surgem frames perdidos, crescimento de memória e, eventualmente, telas brancas quando a camada de render não acompanha. A web tem mitigações —content-visibility: auto, bibliotecas de lista virtual como react-window— mas são remendos opt-in sobre uma arquitetura que nunca foi desenhada para reciclar nós, e acrescentam peso de framework e armadilhas de acessibilidade.
Um mini-programa recicla apenas o visível
Um runtime governado trata uma lista longa como um widget nativo. O recycle-view do WeChat renderiza apenas as linhas atualmente na viewport e recicla as instâncias de nó conforme o usuário rola —os componentes ficam fixos e só os dados se movem. O scroll-view mais novo com type="list" (sob o renderizador Skyline) elimina o JSBridge lógica↔render por completo: a rolagem e o render rodam no mesmo thread com rasterização síncrona, então não há tela branca ao rolar rápido e a memória fica baixa. O antigo scroll-view estilo WebView pagava um custo de conversão JSBridge e usava rasterização em blocos assíncrona, que branqueava quando não conseguia acompanhar. A reciclagem é o padrão, não uma biblioteca que você acopla depois.
Lado a lado
| Dimensão | H5 / WebView | Mini-Programa (recycle-view / Skyline) |
|---|---|---|
| Nós em lista de 1.000 linhas | Milhares de nós DOM vivos | Apenas linhas na tela (~dezenas) |
| Recálculo de estilo ao rolar | Toda a árvore por interação | Reciclado, trabalho mínimo |
| Ponte lógica↔render | Custo de conversão JSBridge | Nenhum (mesmo thread, raster síncrono) |
| Rasterização | Assíncrona; tela branca ao rolar rápido | Síncrona; sem tela branca |
| Memória | Alta; risco de queda | Baixa |
| Impacto no INP | DOM grande → INP ruim | DOM pequeno → INP bom |
O que isso significa para suas listas
Para superfícies densas em dados e de crescimento contínuo —ativos, livros de ordens, registros de transações— a reciclagem de nós é a diferença entre uma sensação nativa e uma apresentação de slides. Um runtime que recicla por construção mantém o ritmo de frames previsível no Android de entrada, onde vive a base instalada global e onde uma lista de 1.000 linhas é rotineira. O H5 segue sendo a ferramenta correta para documentos e a web aberta; a superfície de dados dentro do host não deveria gaguejar quando recebe mil linhas.
Onde o Cross Mini App se encaixa
Cross Mini App é o runtime e o catálogo aberto para esse modelo. Você constrói um mini-programa sobre uma superfície de API padrão e herda um caminho de lista que recicla as linhas na tela em todo host que o incorpora —não um WebView que instancia milhares de nós e trava. Listas fluidas são projetadas, não esperadas. H5 mostra as linhas; o mini-programa deixa você rolar.
Fontes
- WeChat Mini Program — Listas longas também podem ser fluidas (doc oficial)
- WeChat Mini Program — Otimize listas longas com recycle-view
- HTTP Archive — Web Almanac 2025, Markup (tamanho DOM)
- web.dev — Virtualize listas longas
- web.dev — Interaction to Next Paint (INP)
- Lighthouse — Evite tamanho DOM excessivo
