Static Site Canister Too Slow

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

  1. ICP canister. 2.4Mb load time 4.77 seconds
  2. apple.com: 10Mb load time 800ms


1 Like

What’s your canister ID on mainnet?

Canister ID : dlxdc-paaaa-aaaal-ac4gq-cai

Oh, you deployed it with my project Juno (:+1:).

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 :point_right: 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 :point_right: 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 :+1:

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 :smiley:

2 Likes

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!

2 Likes

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.

3 Likes

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.

1 Like

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).

1 Like