Hi
I built a static site that is optimized to 1.3Mb total download. I can go down to 800Kb. This includes images, CSS and JS all optimized. To my surprise when you deploy on the ICP canister it adds another couple of MB bringing the total to 2.3MB. Even then The load time is 4.77s, and the ideal scenario is under 800ms to 1second response time. What could be the reason for this ? I have attached two screenshots
Whatās your canister ID on mainnet?
Canister ID : dlxdc-paaaa-aaaal-ac4gq-cai
Oh, you deployed it with my project Juno (
).
Most likely, the extra bytes in your websiteās download size are due to the āservice worker.ā This piece of code is downloaded first when you access your website and is injected into the page. Once in place, it begins downloading the actual resources of your website and double-checking that everything is certified and free from corruption. In other words, it verifies that there are no malicious nodes in the network.
This has been the standard pattern, but itās worth noting that just last week, it was announced that the foundation is working on removing this service worker pattern to improve speed and user experience, among other things. You can find more details here 
Proposal to deprecate the Service Worker | Internet Computer
To confirm that only 1.3 MB are indeed downloaded, I used a so-called .raw. domain where no service worker is fetched. While itās not recommended to use such a domain as itās less secure, it can be useful in this specific situation https://dlxdc-paaaa-aaaal-ac4gq-cai.raw.icp0.io/
Finally, I ran a Lighthouse test on your website using this domain, and it indeed showed good performance. So, it could either be an issue with the dapp, although your chunking and assets seem fine, or it might be that the IC was a bit slower at the time of the test. Alternatively, itās possible that the code of the canister is not optimized enough. However, I should mention that when I ran a Lighthouse test against the juno.build website (built with Docusaurus hosted on Juno too), it yielded good results. While itās possible that the canister code could be improved, it appears to perform well I think.
Does that make sense? Sounds good?
Btw. your website looks really great
Thatās really good news. You are getting better results. I think it might be a node issue. From what I understand the boundary node will route the closest node ? Mine should be Singapore since the the subnet has it. Iām usually a optimize freak so will try out different things on how I can optimize on IC. Anyway thanks for all the info
Thank you 
I guess so too that the BN route to closest node but, only my understanding might be inaccurate. Let me know if you find any cool optimization scheme!
You will be routed to the closest boundary node, but the boundary node will route to any replica on the subnet, not the closest one.
Anyway to debug which node it connects to ?
The responses are signed by the replicas now so you could check that signature, Iām not sure if it helps though. The boundary nodes will do a round-robin approach for all replicas on the subnet. So you should be getting a response from a different replica every time you make a call.
Boundary nodes will route every request to a randomly picked replica. This is by design, as in the case of a dishonest replica you donāt want to be forced (by the boundary node) to talk to it.
This definitely adds latency, but it is a necessary tradeoff (unless someone implements a mechanism to detect dishonest replicas and use that information to route around them).
