Remover código costuma superar apenas reordenar sua execução
Tese: reduzir código antes de reordená-lo
A publicação argumenta que remover código enviado ao cliente costuma ser uma intervenção de desempenho mais durável, previsível e fácil de sustentar do que apenas reordenar a execução dos recursos. Embora ambas as estratégias exijam compreender profundamente o comportamento da página, não há base para presumir que o agendamento seja mais simples ou barato. A redução de código também pode ser reforçada por limites objetivos de tamanho dos pacotes, enquanto a reordenação depende de preservar continuamente uma ordem delicada e sujeita a regressões.
O código apenas adiado continua chegando à thread principal e pode atrasar recursos visíveis no carregamento. No caso de JavaScript, alocações residuais de compilação podem produzir travamentos perceptíveis quando chegam mais tarde à thread principal. Esses efeitos aparecem em métricas como INP, mas podem ser difíceis de rastrear por dependerem estocasticamente da interação entre recursos, rede, navegador, dispositivo e tarefas concorrentes. Em equipes grandes, manter uma ordem considerada ideal exige coordenação entre áreas, prevenção rigorosa de regressões e prioridades globais que frequentemente são traduzidas para o código sem que suas consequências sejam plenamente compreendidas.
Fragilidade organizacional e técnica
A publicação ressalta que muitas equipes fazem suposições inadequadas sobre seus usuários, como acreditar que todos têm 5G ou dispositivos rápidos, mesmo quando seus próprios painéis e referências globais não sustentam isso. Ao otimizar para condições acima da realidade de parte do público, podem gastar esforço reordenando recursos sem obter ganhos duráveis nem ampliar o mercado atendido. Sistemas dependentes de agendamento tornam-se frágeis diante de mudanças na população de usuários, nos dispositivos, nas jornadas críticas e no conjunto de funcionalidades.
Em arquiteturas SPA, o carregamento antecipado de uma funcionalidade pode prejudicar a experiência de outra, especialmente em redes lentas ou dispositivos com pouca memória e CPU. A disputa entre equipes pelo uso antecipado do canal cria um ciclo em que cada grupo tenta proteger seu recurso, enquanto o tamanho total dos pacotes cresce. Bibliotecas aparentemente inofensivas podem ser acumuladas em arquivos comuns ou de fornecedores, e, sem processos de controle e orçamento de tamanho, a degradação do produto se torna progressiva. Como correção, a fonte sugere retirar sistemas de pré-carregamento e carregamento adiado, medir o produto como ele está e impor cortes - embora ressalve que decisões técnicas devem ser orientadas por rastreamento do comportamento real.
Quando o agendamento faz sentido
A fonte não rejeita a reordenação. Ela reconhece que melhorar o caminho crítico e executar apenas o que está na tela pode aumentar significativamente a responsividade. Porém, recomenda tratar essas intervenções como apropriadas somente para equipes com orçamento rigoroso de tamanho, prevenção de regressões, portões de lançamento e maturidade de gestão de desempenho de pelo menos nível 4. Mudanças aparentemente simples, como aplicar loading="lazy" a imagens e vídeos, podem dar errado sem conhecimento sistêmico e capacidade de investigação.
A orientação geral é reduzir ao máximo o código enviado ao cliente, mover trabalho para o servidor quando possível e só reestruturar a execução quando essas alternativas chegarem a retornos decrescentes. Definir jornadas críticas e identificar quais usuários não devem ser excluídos por problemas de desempenho também ajuda a alinhar líderes e equipes. A conclusão é que sair de desempenho ruim para aceitável é sobretudo um problema de gestão e cultura; melhorias de aceitável para excelente podem exigir desafios técnicos de agendamento.