A virada da abertura para a segunda sala arrastava: 48,5 ms por quadro. Um estudo apontava cinco causas;
a medição refutou quatro (re-render, layout, coleta de lixo, densidade de pixel). O trace fechou o caso:
0,5 s de JavaScript contra ~9 s de rasterização e composição na mesma janela de 13,8 s.
Quadro longo sem tarefa longa de JS é composição.
A causa: cinco camadas de fundo, cada uma com 1,85 tela de área e transparência, somavam ~9 telas de mistura
por quadro, o teto de uma GPU integrada. Virou caixas do tamanho da tela, com a mesma geometria reescrita. Para
provar que o desenho não mudou, comparei o fundo pixel a pixel em sete posições: diferença média de 0,37 em 255.
antes48,5 ms
depois16,8 ms
Ficou um teste que reprova acima de 30 ms por quadro, e ele foi visto reprovando com o defeito de volta.
2. A passagem para a segunda sala: de 1.251 ms a 183 ms
Pior quadro na primeira visita, em 1920×1080, com a pessoa rolando desde o primeiro segundo. Três causas:
Uma fila "fatiada" que não fatiava. Os passos eram encadeados com setTimeout(0), e o
navegador os executava em sequência sem pintar entre eles: tarefa nova não é quadro novo. Quem cede a pintura
é requestAnimationFrame.
Um cálculo que era constante. O mapa de ambiente do 3D custava ~700 ms e dava o mesmo resultado em
toda máquina. Virou um arquivo de 166 KB, gravado uma vez, pré-carregado e aberto num worker: 681 ms → 1 ms.
Fatiar por tempo, não por contagem. Cada volta da fila paga peças até gastar 30 ms, porque o preço de
cada peça varia de 2 a 447 ms.
ideia reprovada2.401 ms
14/09, antes1.251 ms
20/09, antes717 ms
20/09, no ar183 ms
Duas ideias reprovadas pela medição: criar os programas do 3D mais cedo não mudou nada
(961 / 817 / 1.039 ms contra 864 / 936 / 865 ms), e só trabalhar com a página parada piorou muito: quem rola
sem parar nunca dá a folga, e o pior quadro foi a 2.401 ms.
3. A página que pulava: CLS 0,60 → 0
O canvas do 3D era reposicionado por propriedades de layout a cada ajuste, e o navegador contava cada
reposicionamento como a página pulando: CLS de 0,60 em 1366, 0,14 em 1920 e 0,10 no tablet. Agora ele anda
por transform, ancorado no canto. Medido hoje no ar: 0,000 no notebook, no monitor grande e no celular.
antes0,60
depois0,000
O método
Medir no aparelho e no tamanho de tela de quem reclamou: em 1366 a passagem já era lisa, só travava em 1920.
Procurar a contradição no sinal: quadro longo com a thread livre não é JavaScript.
Provar que a correção não mudou o que a pessoa vê.
Deixar um teste que fica vermelho se o defeito voltar.
Case study · Performance of this site
Measure before you touch it.
Three performance problems in Machinova itself, each with a cause found by measuring, and two
ideas that looked good until measurement rejected them.
Role
Everything: it is my site
When
August to October 2026
Tools
Chrome DevTools Protocol · traces · Long Animation Frames · tests that fail on regression
The turn from the opening to the second room dragged: 48.5 ms per frame. A study pointed at five causes;
measurement refuted four (re-renders, layout, garbage collection, pixel density). The trace settled it: 0.5 s of
JavaScript against ~9 s of raster and compositing in the same 13.8 s window.
A long frame with no long JS task is compositing.
The cause: five background layers, each 1.85 screens in area with transparency, added up to ~9 screens of
blending per frame, the ceiling of an integrated GPU. They became screen-sized boxes with the same geometry
rewritten. To prove the picture did not change, I compared the background pixel by pixel at seven scroll
positions: mean difference 0.37 out of 255.
before48.5 ms
after16.8 ms
A test now fails above 30 ms per frame, and it was seen failing with the defect put back.
2. The pass to the second room: from 1,251 ms to 183 ms
Worst frame on a first visit, at 1920×1080, with the visitor scrolling from the first second. Three causes:
A "sliced" queue that did not slice. Steps were chained with setTimeout(0), and the
browser ran them back to back without painting in between: a new task is not a new frame. What yields to paint
is requestAnimationFrame.
A computation that was a constant. The 3D environment map cost ~700 ms and gave the same result on
every machine. It became a 166 KB file, recorded once, preloaded and unpacked in a worker: 681 ms → 1 ms.
Slice by time, not by count. Each turn of the queue pays for pieces until it spends 30 ms, because a
piece costs anywhere from 2 to 447 ms.
rejected idea2,401 ms
Sep 14, before1,251 ms
Sep 20, before717 ms
Sep 20, live183 ms
Two ideas rejected by measurement: creating the 3D programs earlier changed nothing
(961 / 817 / 1,039 ms vs 864 / 936 / 865 ms), and only working while the page is still made it much worse:
someone who keeps scrolling never gives the gap, and the worst frame went to 2,401 ms.
3. The page that jumped: CLS 0.60 → 0
The 3D canvas was repositioned through layout properties on every adjustment, and the browser counted each one
as the page jumping: CLS of 0.60 at 1366, 0.14 at 1920 and 0.10 on tablet. Now it moves with
transform, anchored to the corner. Measured live today: 0.000 on laptop, large monitor and phone.
before0.60
after0.000
The method
Measure on the device and screen size of whoever complained: at 1366 the pass was already smooth, it only froze at 1920.
Look for the contradiction in the signal: a long frame with an idle main thread is not JavaScript.
Prove the fix did not change what the visitor sees.
Leave a test that turns red if the defect comes back.
Case · Rendimiento de este sitio
Medir antes de tocar.
Tres problemas de rendimiento del propio Machinova, cada uno con la causa encontrada midiendo, y dos
ideas que parecían buenas hasta que la medición las reprobó.
Rol
Todo: es mi sitio
Cuándo
Agosto a octubre de 2026
Herramientas
Chrome DevTools Protocol · traces · Long Animation Frames · pruebas que reprueban la regresión
El paso de la apertura a la segunda sala se arrastraba: 48,5 ms por cuadro. Un estudio señalaba cinco causas;
la medición refutó cuatro (re-render, layout, recolección de basura, densidad de píxel). El trace cerró el caso:
0,5 s de JavaScript contra ~9 s de rasterización y composición en la misma ventana de 13,8 s.
Cuadro largo sin tarea larga de JS es composición.
La causa: cinco capas de fondo, cada una con 1,85 pantallas de área y transparencia, sumaban ~9 pantallas de mezcla
por cuadro, el techo de una GPU integrada. Pasaron a ser cajas del tamaño de la pantalla, con la misma geometría
reescrita. Para probar que el dibujo no cambió, comparé el fondo píxel a píxel en siete posiciones: diferencia
media de 0,37 sobre 255.
antes48,5 ms
después16,8 ms
Quedó una prueba que reprueba por encima de 30 ms por cuadro, y se la vio reprobar con el defecto de vuelta.
2. El paso a la segunda sala: de 1.251 ms a 183 ms
Peor cuadro en la primera visita, en 1920×1080, con la persona desplazándose desde el primer segundo. Tres causas:
Una cola "rebanada" que no rebanaba. Los pasos se encadenaban con setTimeout(0), y el
navegador los ejecutaba seguidos sin pintar entre ellos: tarea nueva no es cuadro nuevo. Quien cede la pintura es
requestAnimationFrame.
Un cálculo que era constante. El mapa de entorno del 3D costaba ~700 ms y daba el mismo resultado en toda
máquina. Pasó a ser un archivo de 166 KB, grabado una vez, precargado y abierto en un worker: 681 ms → 1 ms.
Rebanar por tiempo, no por cantidad. Cada vuelta de la cola paga piezas hasta gastar 30 ms, porque el
precio de cada pieza va de 2 a 447 ms.
idea reprobada2.401 ms
14/09, antes1.251 ms
20/09, antes717 ms
20/09, en línea183 ms
Dos ideas reprobadas por la medición: crear antes los programas del 3D no cambió nada
(961 / 817 / 1.039 ms contra 864 / 936 / 865 ms), y trabajar solo con la página quieta empeoró mucho: quien se
desplaza sin parar nunca da el respiro, y el peor cuadro llegó a 2.401 ms.
3. La página que saltaba: CLS 0,60 → 0
El canvas del 3D se reposicionaba con propiedades de layout en cada ajuste, y el navegador contaba cada uno como un
salto de la página: CLS de 0,60 en 1366, 0,14 en 1920 y 0,10 en tablet. Ahora se mueve con transform,
anclado a la esquina. Medido hoy en línea: 0,000 en notebook, monitor grande y celular.
antes0,60
después0,000
El método
Medir en el equipo y el tamaño de pantalla de quien se quejó: en 1366 el paso ya era fluido, solo se trababa en 1920.
Buscar la contradicción en la señal: cuadro largo con el hilo libre no es JavaScript.
Probar que la corrección no cambió lo que la persona ve.
Dejar una prueba que se pone roja si el defecto vuelve.