Uma página moderna de web é montada a partir de dezenas de recursos com diferentes tipos de conteúdo. Os pedidos de tais recursos são iniciados em uma das três formas: o analisador de documento descobre uma tag com uma URL de recursos (por exemplo, img [src]), através de uma solicitação dinâmica iniciada via JavaScript (XHR, elemento injetado no DOM ), ou via uma declaração CSS.

Não existem regras específicas de como ou por que certas buscas de recursos devem ser priorizadas, ou deferidas. Dito isso, todos os fabricantes de navegadores implementaram algum tipo de heurística e priorização preditiva para acelerar o carregamento da página – por exemplo, HTML, CSS e JavaScript são considerados críticos; as imagens e outros tipos de recursos são menos; alguns navegadores limitam o número de downloads de imagens simultâneas; os ativos CSS são carregados lentamente por padrão, e assim por diante. A introdução de analisadores de pré-carregamento codificaram ainda mais essas heurísticas de tipo de conteúdo nas regras de obtenção de fato do conteúdo.

Esses padrões de tipo de conteúdo são razoáveis para a maioria dos casos, mas são insuficientes para a entrega de uma plataforma extensível e com performance amigável. De fato, a falta de controle em nível de aplicativo sobre essas decisões de obtenção de conteúdo é a causa principal da grande maioria dos problemas de desempenho no carregamento de um recurso que os desenvolvedores precisam entrefar hoje – carregamentos atrasados, lentidão indesejada, busca antecipada de recursos não críticos etc.

Obtenção de recursos extensíveis

Para cumprir a promessa de Web extensível, cada obtenção de recurso deve fornecer os seguintes recursos:

1. O navegador pode inicializar obtenção padrão de cada recurso, assim como é feito atualmente.
2. O desenvolvedor deve ser capaz de:
   • Definir a política preloader para qualquer recurso declarado em CSS e HTML (1).
   • Definir a política de envio de obtenção para qualquer recurso declarado em CSS e HTML (2).
   • Modificar definições padrão de obtenção de todos os pedidos iniciados via JS, CSS e HTML (3).

Cada elemento, função (CSS ou JS), ou outros meios de iniciar uma obtenção de recurso deve atender a esses critérios para fornecer uma plataforma consistente, extensível e performance amigável. Se você estiver definindo um novo recurso de plataforma que inicia uma obtenção de recurso, deverá ser obrigado a explicar como o acima é possível; cada grupo de trabalho competente precisa enfrentar a questão de como equipar de forma eficaz os requisitos para os mecanismos existentes.

1 – Deve ser possível estender o scanner de pré-carregamento com lógica personalizada. Por exemplo:

• opt-in de um novo elemento personalizado, ou opt-out de qualquer elemento HTML existente.
• opt-in de um recurso CSS para processamento do preloader, e assim por diante.

2 – Opt-out de carregamento lento do CSS e heurísticas específicas de navegadores que podem atrasar o envio de busca.

3 – Precisamos de uma interface consistente e funcionalidade equivalente em HTML, CSS e JavaScript. Por exemplo, capacidade de definir alocação de recursos da camada de transporte.

Alguns exemplos quebrados…

• Obtenção de imagens

– Não existe maneira de modificar as definições padrão de obtenção de imagem.

– Declarações de fonte CSS não têm uma estratégia de opt-out de carregamento atrasado.

– A obtenção de imagens pode ser adiada em alguns navegadores devido à página de estrutura heurística.

• Obtenção de fonte

– Não existe maneira de modificar as definições padrão de obtenção de fonte.

– Declarações de fonte CSS não têm uma estratégia de opt-out de carregamento atrasado.

– Declarações de fonte CSS não têm opt-in para o processamento do preloader.

• <x> type fetching (por exemplo JSON payload)

– Deve-se usar JavaScript, faltando um mecanismo declarativo de obtenção.

– A exigência de execução do JavaScript impede o processamento do preloader.

– Não é existe uma forma de modificar as configurações padrão de obtenção no XHR.

Alguns recursos de fonte são garantidos para serem utilizados, e o carregamento atrasado é um afunilamento de desempenho. Algumas imagens podem ser tão críticas como os scripts e as folhas de estilo. A execução de JavaScript impede o envio de recursos no início, o que provoca mais problemas de priorização e de desempenho, e assim por diante. Não é uma lista exaustiva. Na verdade, não chega nem perto de ser. Pelo contrário, é uma ilustração dos tipos de problemas que muitos desenvolvedores e aplicativos estão encontrando diariamente.

Na melhor das hipóteses, os padrões inflexíveis e heurísticas limitam a capacidade do desenvolvedor de melhorar e adaptar a estratégia de carregamento de recurso padrão para atender às suas necessidades. Na pior das hipóteses, esses padrões saem pela culatra e prejudica o desempenho de determinadas páginas e aplicativos. Um tamanho não serve para todos.

Observe que a próxima API ServiceWorker não aborda nenhuma das questões acima. Ela pode influenciar a forma como os pedidos são despachados, mas só depois que recebe o pedido no navegador – e aí já é tarde demais.

Planejando o trabalho a ser feito

Uma discussão detalhada sobre como implementar todos os itens acima está fora do âmbito deste artigo e vai exigir muito do pensamento coletivo e da discussão de desenvolvedores do site, especificadores e engenheiros de navegadores. Dito isso, os requisitos de alto nível e as peças-chave da infraestrutura necessários são mais ou menos assim:

• API Fetch tenta unificar e explicar o recurso buscando na plataforma web.

– Ela precisa de um mecanismo para controlar a atribuição de recursos da camada de transporte.

– Configurações de inicialização da Fetch devem ser expostas em JS, CSS e HTML.

– A API Fetch precisa ser implementada e exposta a desenvolvedores.

• A plataforma Web precisa de um mecanismo declarativo (amigável para o preloader) para coincidir com a API Fetch do JavaScript.

– rel=preload tenta resolver esse problema e precisa ser implementado e exposto a desenvolvedores.

• A plataforma Web precisa definir uma API para fazer interface com o scanner de pré-carreagmento.

– O scanner de pré-carregamento deve ser extensível – por exemplo poder lidar com elementos personalizados.

– O scanner de pré-carregamento deve ser inteligente o suficiente para processar HTML e CSS.

– A lógica do scanner de pré-carregamento precisa ser especificada e aplicada de forma coerente.

• A plataforma Web precisa fornecer o controle sobre as políticas de envio de recursos.

– CSS precisa fornecer mecanismos de opt-out de carregamento atrasado – por exemplo, parâmetros url(), ou algo assim.

– Os fabricantes de navegadores precisam fornecer um mecanismo de opt-out de políticas personalizadas de envio impulsionado por heurística.

Com o acima exposto no lugar, nós finalmente teríamos uma base sólida para um modelo de carregamento de recursos extensível. A partir daí, camadas de API de Streams, Service Worker e várias outras – o futuro é brilhante.

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em https://www.igvita.com/2014/10/02/extensible-web-resource-loading-manifesto/