3 ms·

I measured the speed of this blog and it's finished in 5 to 8 seconds after a soft-reload. Even more telling is the use of http 1.1 on partials of this blog whe

I measured the speed of this blog and it's finished in 5 to 8 seconds after a soft-reload. Even more telling is the use of http 1.1 on partials of this blog when all remote includes do h2 or h3... This is a blog btw, so a static should do! I do domain management, animations and implement stats from logs on the fly. And i even have a markdown blog! ;) My page loads in under 1 second with a hard refresh. Backend for a combined full page controller or partials does 1ms rendering with logged in user. ofc stuff is cached, but the user should never notice. All system related calls are fast as f... and intended this way. DB with PDO takes most of this millisecond. I do vanilla TS with fetch on the frontend which is responsive as a GUI and that's great, i can modify the DOM and do frontend stuff - and not more. Why would i? One call to the ldap-client in nodejs, even with bun, is already slower than my whole page. One tool for one job! If you can beat this wake me up for js on the backend.

LegionMammal978 2y ago
Are you sure you aren't just counting the GA collect call around the 5.5s mark? Prior to that, for me, everything always finishes within 1.58s on a hard refresh. The "load" event fires in under 400ms, and if I enable Firefox's tracking protection (which blocks the Disqus widget from loading), the page always finishes within 300ms on a hard refresh, 160ms on a soft refresh. I doubt that your observation of 5 to 8 seconds has anything to do with this blog's backend or frontend, unless you take fault with the Disqus widget it uses.
- Krei-se 2y ago
  https://gomakethings.com/react-is-slow-at-its-very-core/ https://gomakethings.com/react-is-slow-at-its-very-core/ What's your point? If you disable all remote and interactive stuff you get a fast page render? That's exactly what i criticize here. The page should be considered loaded when all is fetched and usable. And not "loaded" when the main parts from his server are transferred. But yes, the Disqus takes the longest loading time starting at 4s. Scripts start at around 1 second to load. So yeah, you COULD argue the page is loaded after 1 second, but the point is, that it is not _RENDERED_ and functional and not all parts have been fetched yet. Ofc your mileage may vary, i don't block disqus but use uBlock and the page is most likely hosted on another continent which makes latency another issue. To make things fair i took to https://tools.pingdom.com/ https://tools.pingdom.com/ and selected american and german servers respectively, which show 140ms for my page (Frankfurt) and still 800ms for his (from NA) which i think is mostly due to the use of http1.1. and ignores all remotely added scripts and tracking.
  - LegionMammal978 2y ago
    > Ofc your mileage may vary, i don't block disqus but use uBlock and the page is most likely hosted on another continent which makes latency another issue. The page is indeed slower if I route it through a German VPN, but all content including the widget still stops visibly changing in under 5s on a hard reload, 1.5s on a soft reload: everything past that is various tracking nonsense which presumably has no impact on functionality. My bigger point is, no one but a bot is going to be using the Disqus widget to check the comments within 5 seconds of visiting a page on a blog they've never seen before. All substantial content above it stops moving within a second, from Germany or from the U.S. (Unless your RTT is especially bad where you live?) I just don't see what your prescription would be here, except to tear out the widget entirely, just for the sake of improving a metric with no direct importance. Unless you advise that the author implement his own commenting system, which is a huge can of worms filled with spam, legally-sensitive user data, and so on. I certainly wouldn't take it as an indictment on his choice of frontend or backend.

LegionMammal978 2y ago

Are you sure you aren't just counting the GA collect call around the 5.5s mark? Prior to that, for me, everything always finishes within 1.58s on a hard refresh. The "load" event fires in under 400ms, and if I enable Firefox's tracking protection (which blocks the Disqus widget from loading), the page always finishes within 300ms on a hard refresh, 160ms on a soft refresh. I doubt that your observation of 5 to 8 seconds has anything to do with this blog's backend or frontend, unless you take fault with the Disqus widget it uses.

Krei-se 2y ago
https://gomakethings.com/react-is-slow-at-its-very-core/ https://gomakethings.com/react-is-slow-at-its-very-core/ What's your point? If you disable all remote and interactive stuff you get a fast page render? That's exactly what i criticize here. The page should be considered loaded when all is fetched and usable. And not "loaded" when the main parts from his server are transferred. But yes, the Disqus takes the longest loading time starting at 4s. Scripts start at around 1 second to load. So yeah, you COULD argue the page is loaded after 1 second, but the point is, that it is not _RENDERED_ and functional and not all parts have been fetched yet. Ofc your mileage may vary, i don't block disqus but use uBlock and the page is most likely hosted on another continent which makes latency another issue. To make things fair i took to https://tools.pingdom.com/ https://tools.pingdom.com/ and selected american and german servers respectively, which show 140ms for my page (Frankfurt) and still 800ms for his (from NA) which i think is mostly due to the use of http1.1. and ignores all remotely added scripts and tracking.
- LegionMammal978 2y ago
  > Ofc your mileage may vary, i don't block disqus but use uBlock and the page is most likely hosted on another continent which makes latency another issue. The page is indeed slower if I route it through a German VPN, but all content including the widget still stops visibly changing in under 5s on a hard reload, 1.5s on a soft reload: everything past that is various tracking nonsense which presumably has no impact on functionality. My bigger point is, no one but a bot is going to be using the Disqus widget to check the comments within 5 seconds of visiting a page on a blog they've never seen before. All substantial content above it stops moving within a second, from Germany or from the U.S. (Unless your RTT is especially bad where you live?) I just don't see what your prescription would be here, except to tear out the widget entirely, just for the sake of improving a metric with no direct importance. Unless you advise that the author implement his own commenting system, which is a huge can of worms filled with spam, legally-sensitive user data, and so on. I certainly wouldn't take it as an indictment on his choice of frontend or backend.