How fast is Page List block ?
Permalink
Hi. I'm trying to build a pretty dynamic homepage. Essentially it would be based on a Page List block with some customizations. The idea is as follow :
- each user has a profile - essentially a type (private individual / enterprise / ...) and a list of favorite topics (investment / retirement / ...).
- on the homepage, Page List is used to pull pages from the site and present the user with pages that fit his type and favorite topics. I guess the type can be treated as a special case of topic. The pages would be selected with something like type and (topic1 or topic2 or ... topicn).
Now, this means that I can't use Varnish on the homepage and I can't use full page caching either, since the page will be different depending on the topic. Likewise, block caching won't work either, since the Page List block will render a different result depending on each user profile.
So I'm worried about performances. How does Page List behave speed wise ? Is there any kind of internal caching going that would help ? Or am I going to run into speed problems with this approach ?
Alternatively, I'm going to use ElasticSearch for for search feature of the website. I could rely on it to do the filtering rather than C5 and the database by feeding it what I need to build the homepage. Any chance it would be faster ?
If I do have to do some caching on my own, does C5 provide a layer above APCu ? Any documentation on that ?
Also, it seems the Topics developer doc is not ready yet. Any external source where I can find more about how to handle them ?
Thanks for any help !
- each user has a profile - essentially a type (private individual / enterprise / ...) and a list of favorite topics (investment / retirement / ...).
- on the homepage, Page List is used to pull pages from the site and present the user with pages that fit his type and favorite topics. I guess the type can be treated as a special case of topic. The pages would be selected with something like type and (topic1 or topic2 or ... topicn).
Now, this means that I can't use Varnish on the homepage and I can't use full page caching either, since the page will be different depending on the topic. Likewise, block caching won't work either, since the Page List block will render a different result depending on each user profile.
So I'm worried about performances. How does Page List behave speed wise ? Is there any kind of internal caching going that would help ? Or am I going to run into speed problems with this approach ?
Alternatively, I'm going to use ElasticSearch for for search feature of the website. I could rely on it to do the filtering rather than C5 and the database by feeding it what I need to build the homepage. Any chance it would be faster ?
If I do have to do some caching on my own, does C5 provide a layer above APCu ? Any documentation on that ?
Also, it seems the Topics developer doc is not ready yet. Any external source where I can find more about how to handle them ?
Thanks for any help !
Thanks, that's what I suspected - having a dynamic homepage with little caching is not a good idea. Using JS was an option I had considered, but I wanted to check if this could be handled server side.
Actually, I don't think I really need ajax there. The page list is the main content of the page anyway, so the user would have to wait until the ajax is resolved to do anything. So my best option would be to build the page the page with all the content (or the content filtered only by user type - that one is in a cookie and there are only 4 possible values, so this can be cached easily by Varnish). Then, I could use Javascript to keep the non-relevant content hidden.
That's not ideal because the page will be bigger and that will be some work to do in Javascript, but serving the homepage from Varnish would be a huge improvement !
Actually, I don't think I really need ajax there. The page list is the main content of the page anyway, so the user would have to wait until the ajax is resolved to do anything. So my best option would be to build the page the page with all the content (or the content filtered only by user type - that one is in a cookie and there are only 4 possible values, so this can be cached easily by Varnish). Then, I could use Javascript to keep the non-relevant content hidden.
That's not ideal because the page will be bigger and that will be some work to do in Javascript, but serving the homepage from Varnish would be a huge improvement !
Can't you just add some classes as needed and hide stuff with CSS?
SEO-wise that would be a huuuge no-no.
Additionally, your page list will serve X items per page, but your client only sees what he has selected. And if you follow the same logic, going to page 2 or something, might load only 1-2 items if such exist.
For example, let's assume that we are only subscribed to the "investments" category. And let's say Page 1 displays a page list of 20 items of which 3 are related to this category.
Then we see those 3 and go to page 2. There we have 20 more items but just one or two are related to investments.
This is the problem with doing such filtering on the front end.
Additionally, your page list will serve X items per page, but your client only sees what he has selected. And if you follow the same logic, going to page 2 or something, might load only 1-2 items if such exist.
For example, let's assume that we are only subscribed to the "investments" category. And let's say Page 1 displays a page list of 20 items of which 3 are related to this category.
Then we see those 3 and go to page 2. There we have 20 more items but just one or two are related to investments.
This is the problem with doing such filtering on the front end.
In my case, this kind of filtering will only happen on the front page, so there will be no problem with the content pages on the site (there will be some filtering on the side links, but it's minor). Indeed, if the content was that dynamic, I would pick another solution than C5 and PHP.
What would be the problem with Google ? The search engine will see the whole unfiltered content - as would a use on his first visit or if he doesn't want to exclude contents. The search engines have to see the whole content anyway, otherwise they won't be able to follow the links to all the content pages.
I'm not a huge fan of doing that client side, because this means I will have to handle business logic to Javascript. But performance wise, it seems like I don't have a lot of options anyway, the cost of serving a page from Varnish with 20 items will still be lower than the cost of building a page with x different items for each visitors...
What would be the problem with Google ? The search engine will see the whole unfiltered content - as would a use on his first visit or if he doesn't want to exclude contents. The search engines have to see the whole content anyway, otherwise they won't be able to follow the links to all the content pages.
I'm not a huge fan of doing that client side, because this means I will have to handle business logic to Javascript. But performance wise, it seems like I don't have a lot of options anyway, the cost of serving a page from Varnish with 20 items will still be lower than the cost of building a page with x different items for each visitors...
display: none is considered as potentially malicious, and triggers a manual check.
Sadly, I can't provide a decent source so take it with a grain of salt but that's what history says.
But yeah, if that's after logging in or otherwise not a default behaviour, then you should be fine.
Offtopic: please be one of the cool guys who utilize localStorage to save people's filters without registration.
Sadly, I can't provide a decent source so take it with a grain of salt but that's what history says.
But yeah, if that's after logging in or otherwise not a default behaviour, then you should be fine.
Offtopic: please be one of the cool guys who utilize localStorage to save people's filters without registration.
I will double check with my front-end expert about the display none stuff. I know it was indeed banned at some point, but with web applications being very heavy on Javascript now, they might have reversed the logic. It's still possible to reverse the logic and hide stuff before the page is displayed instead of making hidden stuff visible.
We thought about LocalStorage. But we might go with cookies instead, not a lot of stuff to store anyway. The problem with LocalStorage is that it stays on the client, Varnish doesn't see it, your server doesn't see it.
We thought about LocalStorage. But we might go with cookies instead, not a lot of stuff to store anyway. The problem with LocalStorage is that it stays on the client, Varnish doesn't see it, your server doesn't see it.
Cookies are much more limited, and you can pass the localStorage via ajax requests, although I don't imagine why you'd do this if you hide stuff via the front end.
Anyway, that was an offtopic, and I'm not the one to tell you what to do with your website :)
Anyway, that was an offtopic, and I'm not the one to tell you what to do with your website :)
Cookies are much more limited, and you can pass the localStorage via ajax requests, although I don't imagine why you'd do this if you hide stuff via the front end.
Anyway, that was an offtopic, and I'm not the one to tell you what to do with your website :)
Anyway, that was an offtopic, and I'm not the one to tell you what to do with your website :)
Then use some javascript to replace that with your user-specific lists via an ajax call.