O que mcmaster-fast faz?
Faça outros sites parecerem com mcmaster.com: primeira pintura em dezenas de milissegundos, próxima página antes mesmo da barra de URL atualizar.
A stack não importa. McMaster faz isso com ASP.NET, YUI e um ScriptCombiner. A ordem e a quantidade de requisições importam. Modismo de framework não importa.
O que eles realmente fazem
Observado no site ao vivo (2026-09-13) mais a análise de Wes Bos (notas do klinke.studio):
| Camada | O que McMaster faz | Por que parece instantâneo |
|---|---|---|
| Primeiro byte | HTML renderizado no servidor. Navegador pinta antes do JS. FCP ~64ms, TTFB ~19ms em um shell aquecido. | O usuário vê uma página, não um spinner esperando por um bundle. |
| Shell | #ShellLayout_Cntnr + #MainContent. Cabeçalho/carrinho permanecem montados. history.pushState. | O clique na categoria manteve o mesmo nó do cabeçalho e trocou o conteúdo em 35ms. |
| Prever | A passagem do mouse/intenção busca o próximo HTML antes do clique. | O clique é um cache hit + troca de DOM. |
| Visita repetida | Service worker cache-first para navegações GET (não PDFs). Cache manteve / após o primeiro carregamento. | HTML de origem é ~200ms (mc-turn); SW serve localmente. |
| Waterfall | dns-prefetch para hosts de imagens. preload para fontes woff2, logotipo, sprites LCP, JS/CSS da página, ShellDynamic.aspx. | O navegador inicia o download de fontes/LCP antes de descobri-los no CSS. |
| CSS | ~32KB de CSS comum inline em <style> no <head>. Restante via um combinador específico da página. | O primeiro layout não precisa de requisição CSS extra. |
| JS | Bundles ScriptCombiner específicos da página (?files=...). Assíncrono. WebParts carregam após a pintura. | A página de catálogo não baixa código de checkout. |
| Assets | URLs versionadas (/mv1789156784/, ?ver=). Cache-Control: public,immutable,max-age=31536000. Host de imagens images1.mcmaster.com. Sprites para grades de tiles. | Cache de um ano, sem dança de invalidação, poucas requisições. |
| Estabilidade | Caixas reservadas / sprites. CLS medido 0. | Sem reflowenquanto as imagens chegam. |
| Peso | Analytics próprio (/trk/). Sem anúncios. CSP restrito a *.mcmaster.com. | A página é o produto. |
Os documentos HTML em si têm Cache-Control: no-cache e x-check-cacheable: NO no Akamai. Não copie "CDN-cache para todo HTML". Eles armazenam em cache o shell no navegador e armazenam em cache arquivos estáticos imutáveis na borda.
Escada de prioridade
Pare no primeiro degrau que deixar a página com LCP abaixo de ~200ms em cache aquecido. Não instale Workbox, um pipeline de sprites e Regras de Especulação em um único PR.
- Envie HTML que o navegador pode pintar. SSR ou HTML estático. Nada de renderização somente cliente para a primeira visualização. Mate o JS que constrói a primeira tela.
- Desbloqueie a primeira pintura. Coloque inline apenas o CSS acima da dobra (ou uma pequena folha bloqueante). Faça
preloadda imagem LCP e das fontes woff2 (crossorigin).width/height(ou CSS aspect-ratio) em toda imagem. - Arquivos estáticos imutáveis. Fingerprint ou query de versão.
Cache-Control: public, immutable, max-age=31536000. - Chrome persistente + troca de conteúdo. Layout compartilhado. A próxima navegação substitui um nó de conteúdo e faz
pushState. Não remonte o cabeçalho. - Pré-busca por intenção. Documento seguinte especulado ao passar o mouse/entrar no viewport. Limite o número. Nunca pré-busque checkout, APIs de busca ou HTML autenticado.
- SW de navegação (opcional). Cache-first para navegações GET no shell/página inicial pública. Limpe ao fazer deploy. Invalide a partir da página, não de um SW esperto. Pule se o site for majoritariamente privado.
- JS específico da página. Divisão por rota. Adie analytics até ocioso. Remova tags de terceiros que não sejam o produto.
- Sprites / host de imagens somente se você tiver dezenas de ícones pequenos em uma única visualização. HTTP/2 + algumas imagens comprimidas é suficiente abaixo disso.
Fluxo de trabalho do agente
Quando solicitado a tornar um site rápido dessa forma:
- Trace o primeiro carregamento real e uma navegação dentro do aplicativo (rede + o que é pintado). Nomeie o elemento LCP atual e o JS que o bloqueia.
- Aplique o degrau mais baixo da escada que está faltando. Uma alteração por passada, a menos que o usuário tenha solicitado uma varredura completa.
- Prefira recursos de plataforma já existentes no repositório (Next
<Link>,next/font, layouts do App Router) em vez de novas bibliotecas. - Após uma passada, deixe uma verificação: números de LCP / FCP, ou uma pequena afirmação de que o nó do shell é reutilizado em uma navegação cliente.
- Leia techniques.md para a receita exata do degrau que você está implementando. Leia recipes.md para mapeamentos com Next.js / vanilla / SPA existente.
Regras rígidas
- HTML é o produto. JS é melhoria opcional.
- Pré-busca é uma dica, não um crawler. Apenas documentos GET de mesma origem.
- HTML personalizado é
no-storeou apenas via SW com um curto TTL. Nunca coloque HTML de carrinho/conta em um cache CDN compartilhado. - Não adicione um service worker que intercepte todos os assets. Apenas documentos de navegação, combinando com o
ServiceWorkerJS.aspxdo McMaster. - Não copie YUI, sprites ou ASP.NET. Copie a ordem de operações.
- Não "modernize" uma página HTML rápida transformando-a em um SPA cliente como solução.
- Scripts de terceiros (anúncios, gerenciadores de tags, chat) são considerados culpados. Mantenha-os fora da primeira pintura ou remova-os.
- Marque atalhos com
ponytail:quando você pular um degrau de menor valor.
Feito quando
- Primeira visita: HTML é pintado antes de qualquer bundle do aplicativo ser executado. LCP é um elemento enviado pelo servidor, não renderizado pelo cliente.
- Próximo clique: o chrome permanece montado; apenas a região de conteúdo é trocada.
- Visita repetida ao shell/página inicial: servido localmente ou do cache de memória.
- Fontes e imagem LCP estão nas primeiras 1–2 viagens de ida e volta, não descobertas após o CSS.
- CLS permanece próximo de 0 nas páginas que você tocou.