0

I am looking for a method to measure the time difference between:

  1. the time it takes to load and completely reach TTI for example.com/page-B given that example.com/page-A is loaded.

  2. the time it takes to fetch the "main content" of example.com/page-B and replace it in example.com/page-A via Javascript and reach "TTI status" again.

Why?

Well, the thing is I am thinking about an idea to mix server side rendering and client side rendering, but I want to collect data to know if this is a good idea or a bad idea.

Please note that I am not looking for opinions (which are off-topic here). I am looking for a specific method to do a specific task.

The following text is an explanation of what I am doing and why I want to do it, so that it may help to understand the situation and what method can fit the case.

Overview

I am going to refer to common elements in a common HTML page with the following labels:

  • html-head: Everything between <head> and </head>
  • page-header: Well, what is commonly understood as a page header. Probably a <header> element with a <nav> inside, some logo, and so on. The first piece of HTML that is usually found in every webpage.
  • main-content: The content that makes each page in a web different. The content itself, be it the contact form and its surroundings, a gallery, a post, the main content of the current page that makes sense on its own.
  • footer: The page footer and also the closing </body> and </html> tags.

The idea (simplified)

A. First request to server

Server spits out a plain HTML page including everything.

B. Following requests (done via JS)

B.1. Server spits out only the main-content in plain HTML. Not JSON encoded, no properties, just the plain HTML.

B.2. The main-content in the original already loaded page gets replaced with the new main-content.

The idea (explained)

The first request to the webpage will contain the server side rendered content in a traditional way, using PHP as the backend.

The following requests will fetch server side rendered HTML for main-content only. No html-head, no page-header, no footer.

So, once the page is loaded with the common <head> with my webpage general style.css and the navigation is set up, I can just remove the <div id="main-content"> child elements and replace it with the new fetched main-content.

But I am unaware of the practical benefits of doing so, and I don't want to get lost into random ideas that may lead to a waste of time and a useless result.

  • Intuition 1: Not having to redownload the style.css (and probably bootstrap.css, fontawesome.css...) for each page request will save time. But browsers cache it anyways. So, is this a benefit or does it not make a difference?
  • Intuition 2: Not having to render the page starting from scratch (read the meta tags, setup a new HTML document, render the header, the footer...) will save time. But since the "big part" is actually the main-content, and I plan to replace that, is there any real benefit in doing so? I mean, it would be very clear that replacing only a small piece of content will make a difference, but does the same apply if I replace the whole main-content? Could it happen that this makes it even worse (to tear apart the DOM and throw new stuff into it a few times)?

Why?

Well, this seems like re-inventing the wheel. Angular, React, Vue... all those already offer ways to achieve a similar or even better effect.

This idea comes because I am "breaking" WordPress for myself (actually opensource). I realized there is a lot of code that I never use. A lot. There are many alternatives to WP, sure. But I like the way it works, the "event driven" architecture (actions and filters), te concept of post types... it's just good an easy to work with, and I built several things that I want to reuse because they are solid and took time to build.

I could use a headless version of WP and build a frontend entirely with some API and so on, but I came up with this idea and I like it and I want to take it to a further point and see if it fits my expectations, before deciding to use something else than the currently "bloated" (not hating!) WP CMS.

Note:

I would also be thankful if you provide some points about this being a good idea or a bad idea. I know this falls into opinion territory, and this is not the scope of the question. But I would appreciate it if you share some side-thought(s) you may probably have while trying to interpret the question.

Improve this question
2
  • Are you looking for an answer about how to measure TTI? Or an answer about whether your idea is likely to produce shorter time?
    – joshp
    Commented Jun 5, 2021 at 23:22
  • @joshp Actually the goal is to get an answer to the second. And I could get there or by knowing how to measure it or by getting a direct answer. I've probably read too much about SPA, MPA, SSR, CSR so far... and yeah, in the end there isn't solid line between them. Sticking to SSR for MPA with some JS interactions and CSR for SPA is probably better than overthinking this much more. But it would be interesting anyway to know whether this idea is likely to produce a considerable shorter time or not.
    – Álvaro Franz
    Commented Jun 6, 2021 at 11:12

2 Answers 2

Reset to default
0
+100

IMHO The approach you are describing sounds similar to the SPA applications made with any frontend tech (svelte, vue, react) with a SSR implementation. If we can learn anything that is dom manipulation if done in correct way is certainly faster than loading a web page. What you are trying to achieve here is combination of lazy loading of components and routes.

There are few benefits of this approach that I see.

  • Assets(images, js, css) are not downloaded again which minimizes the downloading and parsing time for those assets (Network latency is obviously minimized).
  • Dom tree construction is obviously faster and will seem more interactive to user
  • Minimization of render blocking resources (js/css/img/font) and add lazy loading to different resource to minimize the overhead in dom

However I see many potentials cons of this approach

  • Js dom will be bloated with unwanted states(objects/variables)
  • Js running with on a single page might affect another page if you are not careful all it takes is a single promise/setTimeout/setInterval those types of code to mess with your dom of another page
  • This implementation adds overhead to the code as you will return two types of data
  • Changes to have conflicts with js/css codes. This might cause issue with your website responsiveness. This means it is hard for new devs and existing to perform any changes on a single page. This will potentially cause more time on development
  • Debugging and caching are both really hard for these types of archietecture. Due to which many spa use component based css/js manipulation

What is inherently better in frontend frameworks than your approach?

  • Documentation and clean well thought archietecture to combat many of the problems above. This means code splitting/lazy loading are implemented in well thought way.
  • Tested and more reliable caching/memoization support. Chances to conflict with other routes are essentially zero as they never mostly give power to other library like jquery to change dom and you are discouraged to change dom by yourself

This approach from what I can see will add more overhead and development time to the code for a few benifits that are better handled and well implemented already by other external frameworks.

Improve this answer
1
  • Thanks for sharing your wisdom. Good points!
    – Álvaro Franz
    Commented Jun 11, 2021 at 16:00
0

You're assuming that sites replace parts of the DOM because it is faster. It is not really. Instead:

  • replacing the DOM is often perceived as faster
  • replacing the DOM allows us to maintain state across pages

By maintaining the old layout, maybe showing a loading animation, and then replacing the page contents in one go, the website can avoid the displaying a half-loaded page. The actual content update should only take a single animation frame.

In some cases, this can also lead to a real speed-up, e.g. when the frontend only has to patch a small part of the DOM, so that the browser doesn't have to re-layout the entire page. Another potential speed-up can be achieved by pre-fetching the next page's content before the user performs the navigation. However, most browsers have some level of support for prefetch/preload, independently of front-end JavaScript.

A more useful reason for replacing page contents on the frontend is to maintain state. When replacing the DOM, JavaScript objects will stay alive. For SPAs this is very important. Without DOM replacement, we'd either have to use the REST approach (state transfer) or have to persist the state using cookies/LocalStorage/IndexedDB/…

Improve this answer
2
  • 3
    This answer is misleading, IMO, particularly the first statement. It is almost intrinsically faster, and the remainder of the answer almost begrudgingly of acknowledges that fact. The browser doesn't have to reparse, rebuild the DOM, reload all the linked assets, re-execute scripts, etc.. The content request itself is often faster too, because the server-side only needs to fetch and serialize a subset of the page content. The question of how to measure the reduced latency from mouse-click to render is completely legitimate. I think it warrants a serious answer.
    – svidgen
    Commented Jun 3, 2021 at 14:24
  • 2
    ^^ There are other potential pros/cons that could be relevant to the OP. Code and request lifecycle complexity, the necessity and complexity of caching inherent to each approach, overall application design, stability, debuggability, the things that are simply not really possible outside of an SPA, etc. ... Oh, and the OP's future marketability if they do or don't get comfortable building SPA's is also relevant, IMO .. :D ...
    – svidgen
    Commented Jun 3, 2021 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.