Closed hongc-cc closed 4 years ago
Can you share your template code you're using to render navigation items? I'm pretty sure this is coming down to the few things we're doing to load in additional information into queries (active state for child/parent, site-based url, custom fields)
And comparing with Navigate is a bit of an unfair comparison - our node's are elements, meaning you can have custom fields on them, easy querying and a few more things. It does add overhead, but we're also adding more functionality, so it's to be slightly expected.
They do have caching implemented it seems, which might reflect the speed difference. It might be something we consider adding.
In the meantime, I'd like to try and replicate your example. How many nav items does your nav contain? You mentioned it was only a single level.
Also, advise what template code you're using so I can replicate.
Sure. I understand it is unfair to compare that. Yet navigation is such a nice plugin with custom field and i really want to find out the reason behind.
{% set nodes = craft.navigation.nodes()
.handle('header')
.level(1)
.all()
%}
<ul class="lg:flex-grow">
{% nav node in nodes %}
<li class="lg:inline-block">
<a class="block p-4 text-2xl transition duration-300 lg:text-xl h-min-16 lg:inline-block hover:text-primary-500"
href="{{ node.url }}">{{ node.title }}</a>
</li>
{% endnav %}
</ul>
Nodes in single level, with 5 links only. The average rendering time is ~230ms (from twig profiler by nystudio)
Thanks for that, looks like you're doing everything right, and is about as performant as it can be! In particular, the {% nav %}
tag has performance gains over directly looping over nodes.
I've just tested with your exact template code on a brand new install, on a blank page with 5 navigation nodes (entries) and using Twig Profiler. It's averaging about 35ms - and that's locally on an admittedly slow MAMP server, with devMode
on.
Reproduce the case with 5 categories and 2 singles:
Here's what I'm getting - https://d.pr/i/aLs5h7
Looks like SEOMatic might be skewing the results, as it's already up to 133ms when it gets to render the nav, so your local site is taking 103ms to render. Still, a bit slower than I'd think. What's going local dev environment though? Have you looked as real-world performance on a web server?
I'd also remove Formie from the page in case that's messing things up.
Generally though, testing performance on a local dev environment is a bit unreliable as a benchmark.
Ah, I see you're sorting by duration, so nevermind about SEOmatic. Still, I'd be interested in it and Formie disabled.
I also wonder why i am getting weird result.
So the code now includes only navigation rendering and disable seomatic through {% do seomatic.config.renderEnabled(false) %}
It's still around 200-250ms.
MAMP, Apache, craft cms 3.5.12, latest navigation version
If you have set up a new MAMP setup, can you check if a empty page has similar result like below? This could help me to check whether this issue is happening to me only. If that is very different, then maybe we can close this issue as this would be my setup issue.
Empty page rendering
Sure, seems similar to my output. This is for a completely blank page.
This is after including the nav, including {% profile "nav" %}
wrapping the nav:
The difference being pretty negligible.
I would like to point out in your previous screenshot a large gap where something is being rendered. You'll notice in the above there are a few queries, but they're extremely quick to execute. There's a great deal of something delaying as illustrated in this shot https://d.pr/i/tDjLbx but your screenshot is cutoff, so makes it difficult to isolate the specifics.
Closing for now, let me know if you'd like the reopened.
What are you trying to do? I am looking at the rendering time using twig profiler. The navigation (with single lv, no custom fields) takes 2xx ms to load. Which my whole
<main>
component also only take 2xx ms to load.The rendering time is oddly long. Although cache and eager loading can help, but this seems like some fundamental issue.
P.S. Comparing to another plugin
navigate
, it only takes 2x ms.What's your proposed solution? A description of how you think this could be solved, including any alternatives that you considered.
Additional context Add any other context or screenshots about the feature request here.