3 ms·

My site is not using an CDN and faster than forestry.io. Mostly due to the fact that its 2 statically resources than can be loaded in around 0.3 seconds. Fore

My site is not using an CDN and faster than forestry.io. Mostly due to the fact that its 2 statically resources than can be loaded in around 0.3 seconds. Foresty.io can load the HTML and the CSS in the same amount of time, but then another 8 megabytes of JavaScript and imagery follows. Optimizing for ping time is premature optimization when website obesity is the elephant in the room.

lunixbochs 8y ago
They nail this in the article, but draw the wrong conclusion: > Communicating with the more distant server caused a 500% increase in round-trip latency. 250 milliseconds may sound like a short amount of time, but this time penalty applies to every request the user makes to that server: CSS, JavaScript, images, etc. Even small amounts of latency can negatively impact your site. If there were an easy way to eliminate this latency, wouldn’t you want to do it? (150 assets | 8MB (lol)) may sound like a small amount of data, but bandwidth delay product and sequential asset requests can result in time penalties which are multiplied with latency to significantly increase page load time. You can optimize your TLS handshake (you're using TLS, right?) to fit in fewer TCP fragments (don't include the whole chain), use OCSP stapling so the client doesn't need to make a separate request to your certificate authority before starting to load your site. You can remove the penalty of sequential asset fetches using HTTP/2 to push / prefetch assets. This should almost completely eliminate "asset delay product" parts of your load time from having too many assets that aren't queued as part of the initial request. You can cheat bandwidth delay product by using Google's BBR TCP congestion control on your servers, which provides much higher bandwidth in the face of packet loss (packet loss which will probably be more likely for clients with higher ping). You might not really notice this, but someone loading your site from Australia over janky undersea cables will thank you later. At this point, if you look at the flame graph of your site loading, you may have realized that the steaming garbage heap of JavaScript and fonts is still taking several seconds to literally transfer over the network and parse. You should now meditate on what part of "static site" requires so much dynamic client code, and try to trim your site down to something that could at least fit on an effing floppy disk. Maybe after you've looked at all of these, maybe, if you have globally distributed users and site load time is still a major issue for you, maybe then evaluate what putting a CDN in the middle would do for your load time. But loading your site from a CDN will never make up for the 5 second render time caused by your endless bloated chain of abstractions.
JBReefer 8y ago
0.3 seconds seems really long for that - are you storing the files on disk or in memory? I mean I really agree with you and think more people should do exactly what you're doing, but comon, let's bikeshed this at least a little :)
- blueflow 8y ago
  Both - on disk, but the kernel caches it in memory. Not everyone is blessed with an fast internet connection.

lunixbochs 8y ago

They nail this in the article, but draw the wrong conclusion: > Communicating with the more distant server caused a 500% increase in round-trip latency. 250 milliseconds may sound like a short amount of time, but this time penalty applies to every request the user makes to that server: CSS, JavaScript, images, etc. Even small amounts of latency can negatively impact your site. If there were an easy way to eliminate this latency, wouldn’t you want to do it? (150 assets | 8MB (lol)) may sound like a small amount of data, but bandwidth delay product and sequential asset requests can result in time penalties which are multiplied with latency to significantly increase page load time. You can optimize your TLS handshake (you're using TLS, right?) to fit in fewer TCP fragments (don't include the whole chain), use OCSP stapling so the client doesn't need to make a separate request to your certificate authority before starting to load your site. You can remove the penalty of sequential asset fetches using HTTP/2 to push / prefetch assets. This should almost completely eliminate "asset delay product" parts of your load time from having too many assets that aren't queued as part of the initial request. You can cheat bandwidth delay product by using Google's BBR TCP congestion control on your servers, which provides much higher bandwidth in the face of packet loss (packet loss which will probably be more likely for clients with higher ping). You might not really notice this, but someone loading your site from Australia over janky undersea cables will thank you later. At this point, if you look at the flame graph of your site loading, you may have realized that the steaming garbage heap of JavaScript and fonts is still taking several seconds to literally transfer over the network and parse. You should now meditate on what part of "static site" requires so much dynamic client code, and try to trim your site down to something that could at least fit on an effing floppy disk. Maybe after you've looked at all of these, maybe, if you have globally distributed users and site load time is still a major issue for you, maybe then evaluate what putting a CDN in the middle would do for your load time. But loading your site from a CDN will never make up for the 5 second render time caused by your endless bloated chain of abstractions.

JBReefer 8y ago

0.3 seconds seems really long for that - are you storing the files on disk or in memory? I mean I really agree with you and think more people should do exactly what you're doing, but comon, let's bikeshed this at least a little :)

blueflow 8y ago
Both - on disk, but the kernel caches it in memory. Not everyone is blessed with an fast internet connection.