A reformulação do site corporativo da Shandong XYN Information Technology Co., Ltd. costuma dedicar muito tempo à parte visual da tela inicial, enquanto empurra para o cabeçalho ferramentas de estatísticas, atendimento ao cliente, pixels, testes A/B, chat e SDKs de mapas, adotando a abordagem “colocar primeiro e resolver depois”. O web.dev, do Google, afirma em “Third-party JavaScript performance” que scripts de terceiros não apenas tornam as páginas mais lentas, como também comprometem a privacidade, a segurança e o comportamento da página; como não fazem parte do seu ritmo de lançamentos, os problemas tendem a ser ainda mais difíceis de solucionar. Scripts síncronos bloqueiam a análise do documento; e, caso a fonte externa apresente falha, a página pode ficar aguardando até que a solicitação expire. O teste de falha única do WebPageTest, citado pelo web.dev, estima esse período entre 10 e 80 segundos. Para sites B2B que buscam captar leads, isso é mais prejudicial à conversão do que a ausência de duas imagens de produto.
I. Primeiro faça o inventário, depois discuta técnicas de otimização
O primeiro passo recomendado pelo web.dev não é modificar o código, mas sim realizar uma gestão adequada: escolher fornecedores com menor volume de código, definir orçamentos de desempenho para terceiros, evitar a implementação simultânea de dois sistemas de gerenciamento de tags ou duas plataformas de estatísticas, além de realizar auditorias periódicas e remover pixels sem manutenção. Muitos sites corporativos contam com a presença simultânea da antiga ferramenta de estatísticas do Baidu, novas plataformas analíticas, pixels de publicidade adicionados por equipes de vendas e um sistema de atendimento online obsoleto — cada um com sua própria estrutura, conexões e políticas de cache extremamente deficientes. Quanto às estratégias de carregamento, exceto pelos scripts essenciais para a renderização inicial, todos devem utilizar async ou defer; segundo o web.dev, após o The Telegraph alterar para defer os scripts incluindo anúncios e estatísticas, o carregamento dos anúncios ficou, em média, cerca de 4 segundos mais rápido. Para fontes que certamente serão utilizadas, o preconnect é mais eficiente do que simplesmente realizar a pré-resolução do DNS e economizar uma etapa de handshake TLS.
1.1 Páginas de marketing e de formulários não devem compartilhar a mesma política de confiança
A OWASP destaca, na discussão sobre a cadeia de suprimentos front-end, que um mesmo fragmento de análise, quando inserido em uma página de história da marca e em uma página de envio de formulário de contato, apresenta riscos completamente diferentes. O incidente de 2025, no qual pacotes como chalk e debug foram sequestrados — totalizando cerca de 2,6 bilhões de downloads por semana — demonstra que a perda de controle sobre as contas dos mantenedores pode se propagar ao longo da árvore de dependências. Mesmo que o site oficial não faça diretamente o empacotamento dessas bibliotecas via npm, basta utilizar tags automáticas de atualização ou endereços “versão mais recente” em CDNs para que a superfície de ataque permaneça.
II. A CSP deve usar números aleatórios, em vez de ampliar indefinidamente a lista de permissões
O guia de implementação da CSP do MDN coloca as políticas rigorosas baseadas em nonce ou hash antes das políticas baseadas na lista branca de domínios. A lista branca tende a crescer sem limites, acabando por incluir até domínios inseguros, o que equivale a não ter nenhuma política. strict-dynamic serve para resolver o problema de “scripts confiáveis na primeira etapa que carregam sub‑scripts”, evitando que metade da internet seja incluída no script-src. Já o connect-src restringe para onde os scripts podem enviar dados — essa é a chave para impedir que códigos de estatísticas sequestrados levem junto campos de formulário. Scripts embutidos não podem ser protegidos por SRI; só é possível contar com o nonce que muda a cada resposta. Bibliotecas estáticas, com versões fixas, são as mais adequadas para SRI.
| Aspectos de controle | O que resolver | Recomendações para a implantação no site oficial |
|---|---|---|
| Inventário e orçamento | Fornecedores repetidos, pixels sem manutenção | Nomear responsáveis trimestralmente; se ultrapassarem o orçamento, serão retirados do ar |
| Formas de carregamento | Bloqueio da renderização, timeout em ponto único | Por padrão, defer; atendimento ao cliente e pixels postergados para após a interação |
| CSP com nonce + strict-dynamic | XSS e inserção indiscriminada de scripts | Primeiro Report-Only, depois imposição obrigatória nas páginas de formulário |
| connect-src / Permissions-Policy | Envio de dados e uso indevido de capacidades do navegador | Proibição de recursos irrelevantes como área de transferência e câmera nas páginas de formulário |
| SRI e fixação de versões | Troca de arquivos em CDN | Proibição de bibliotecas públicas “latest” sem hash |
III. A reformulação deve começar pelo orçamento de scripts, e não pela maquete visual
Os Core Web Vitals já foram amplamente discutidos, mas, na verdade, os pontos que mais prejudicam o desempenho dos sites corporativos costumam estar relacionados a terceiros, e não ao próprio CSS. O web.dev ainda alerta: estabelecer conexões com fontes externas já é custoso; o HTTPS exige DNS, redirecionamentos e múltiplas viagens de ida e volta; e, ao trazer várias fontes para a mesma página, acaba-se por depender da mais lenta delas para a renderização inicial. Quando a XYN Tech desenvolve um site oficial, trata a lista de tags como um entregável de mesmo nível que a estrutura de colunas: cada script deve especificar claramente sua finalidade, o domínio de saída dos dados, se aparecerá em páginas de formulário e se, em caso de falha, a página ainda permitirá o envio. Nas páginas que hospedam formulários de consulta, por padrão, não são carregados anúncios nem pixels desnecessários; o componente de chat é injetado apenas após o clique, evitando deixar o destino da tela inicial a mercê da disponibilidade do provedor de atendimento ao cliente. A Permissions-Policy pode bloquear o acesso de iframes de terceiros à área de transferência, à câmera e à porta USB, sendo especialmente útil em páginas que permitem upload de arquivos ou apresentações online.
- Utilize as ferramentas de desenvolvedor para listar todas as fontes externas e identificar funções duplicadas.
- Estabeleça orçamentos separados de scripts para a página inicial e para a página de contato (em kilobytes e em tempo de bloqueio do thread principal).
- Coloque em funcionamento o ponto de reporte da CSP, observando primeiro as falsas alarmes durante uma semana antes de impor medidas rigorosas.
- No contrato, exija que qualquer adição de novos pixels por parte da equipe de marketing passe por processo de alteração formal, em vez de mudanças improvisadas nos templates.
O gerenciador de tags costuma ser visto como uma brecha para “adicionar pixels futuramente sem precisar recorrer aos desenvolvedores”. Para a equipe de segurança, isso equivale a entregar o poder de publicação de scripts ao backoffice de marketing. A condição aceitável é: apenas contas controladas podem publicar; cada publicação deve ter quantidades diferenciadas; e os containers de produção devem, por padrão, bloquear tags não aprovadas. Caso contrário, assim que a CSP for endurecida, o gerenciador de tags voltará a liberar scripts arbitrários. A governança de scripts de terceiros não permite espaço para ostentação; trata-se de recuperar o controle sobre quem pode executar código sob nosso domínio. Na próxima reformulação do site oficial, se a avaliação for apenas visual, inclua também capturas do painel de rede nos materiais de revisão: aquelas barras coloridas representando requisições de terceiros são, na verdade, o ruído de fundo comum à conversão e à segurança. Primeiro remova os pixels sem manutenção, depois discuta se vale a pena trocar por uma plataforma de marketing mais robusta.