Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Navigation Performance #248

Open
MichaelNussbaumerGOWEST opened this issue Apr 29, 2022 · 3 comments
Open

Navigation Performance #248

MichaelNussbaumerGOWEST opened this issue Apr 29, 2022 · 3 comments
Labels
v1 Version 1.x

Comments

@MichaelNussbaumerGOWEST

I have a pretty huge site, where I have some performance issues with the call for initialData. I reduced the "level" of the typoscript default from headless, which improves that a lot already. But the question which come up, why we not use just the home page for that and determine if the page is active in another way? Like updating the store for navigation on route change.

Explaination: I have a site with overall around 30-40.000 pages, and every page has its own call for navigation. If we could concentrate that to one call the caching would be way more effective. The downside is, that we need to evaluate the active page in the frontend. But I think we would more benefit in larger applications when there is one api endpoint for the navigation per page. (I have 50 pages)

So basically the possibility to hit a non cached navigation link is pretty high.

@MichaelNussbaumerGOWEST
Copy link
Author

*edit: As far as I can see, the application is already able to handle that like I was thinking about.

I also patched the api via nuxt plugin to make it work for me now:

import url from "url";

// eslint-disable-next-line no-unused-vars
export default ({ app, $router }, inject) => {
	app.$typo3.api.getInitialData = function (
		params = {
			path: "",
		}
	) {
		const urlObj = url.parse(params.path);
		const regex = new RegExp("^(/)?([^/]+).*");
		params.path = urlObj.pathname.replace(regex, "$2/");
		const URI = encodeURI(`${params.path}${app.$typo3.options.api.endpoints.initialData}`);
		const logLabel = `TYPO3 Initial Request - ${JSON.stringify(params)} - ${Date.now()}`;
		console.time(logLabel);
		return app.$typo3.api.$http
			.get(URI)
			.then((res) => {
				console.timeEnd(logLabel);
				return res;
			})
			.catch((error) => {
				console.warn(`Can't get the initial config of ${app.$typo3.options.baseURL}`);
				console.error(new Error(error));
				throw error;
			});
	};
};

@mercs600
Copy link
Contributor

@MichaelNussbaumerGOWEST sometimes you may to want to have different navigation and initialData for specific pages, for example for customer page, catalog page etc.
At the moment we get initialData once - during SSR - and after that when route is changing (on client side) we don't wan't to refresh initialData on each route change (unless you refresh it by $typo3.api.getInitialData) . For the current navigation state we use https://nuxtjs.org/examples/routing/active-link-classes/
If I understand you correctly - your issue is about calling initialData during SSR for each page, not for route change on client side ?

@MichaelNussbaumerGOWEST
Copy link
Author

MichaelNussbaumerGOWEST commented May 24, 2022

@mercs600 Exactly, I have a page with around 36k pages, so it has a huge impact on initial load on a lot of pages even though I have the same navigation everywhere.

But you are right, there might be different navigations in other cases, but in my case it is a huge disadvantage. So might be worth to have this behaviour configurable?

@mercs600 mercs600 added the v1 Version 1.x label Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v1 Version 1.x
Projects
None yet
Development

No branches or pull requests

2 participants