[Gelöst] Loading time optimization

[Author]

Artikel

[Matthias Reichl]

Hi,

I´ve created four views on my home page to display a category tree for different custom post types. The loading time without any caching plugin lasts nearly 20 seconds. I´ve investigated the issue and found with query monitor a really long query, which comes from toolset:

[code]
SELECT n0w18p_posts.*
FROM n0w18p_posts
LEFT JOIN n0w18p_term_relationships
ON (n0w18p_posts.ID = n0w18p_term_relationships.object_id)
INNER JOIN n0w18p_postmeta
ON ( n0w18p_posts.ID = n0w18p_postmeta.post_id )
LEFT JOIN n0w18p_icl_translations t
ON n0w18p_posts.ID = t.element_id
AND t.element_type = CONCAT('post_', n0w18p_posts.post_type)
WHERE 1=1
AND n0w18p_posts.ID NOT IN (467)
AND ( n0w18p_term_relationships.term_taxonomy_id IN (2523) )
AND ( ( n0w18p_postmeta.meta_key = 'wpcf-g-level'
AND CAST(n0w18p_postmeta.meta_value AS SIGNED) = '1' ) )
AND n0w18p_posts.post_type = 'product-group-page'
AND ((n0w18p_posts.post_status = 'publish'
OR n0w18p_posts.post_status = 'private'))
AND ( ( ( t.language_code = 'en'
OR ( t.language_code = 'en'
AND n0w18p_posts.post_type IN ( 'post' )
AND ( ( (
SELECT COUNT(element_id)
FROM n0w18p_icl_translations
WHERE trid = t.trid
AND language_code = 'en' ) = 0 )
OR ( (
SELECT COUNT(element_id)
FROM n0w18p_icl_translations t2 JOIN n0w18p_posts p
ON p.id = t2.element_id
WHERE t2.trid = t.trid
AND t2.language_code = 'en'
AND p.post_status IN ( 'publish' ) ) = 0 ) ) ) )
AND n0w18p_posts.post_type IN ('post','page','attachment','avada_portfolio','avada_faq','product','specialist','product-group-page','product-image','product-link','suppliers' ) )
OR n0w18p_posts.post_type NOT IN ('post','page','attachment','avada_portfolio','avada_faq','product','specialist','product-group-page','product-image','product-link','suppliers' ) )
GROUP BY n0w18p_posts.ID
ORDER BY n0w18p_posts.post_date DESC
+ Toggle button
WP_Query->get_posts()
Plugin: wp-views 1 0.0372
2557 SELECT n0w18p_posts.*
FROM n0w18p_posts
LEFT JOIN n0w18p_term_relationships
ON (n0w18p_posts.ID = n0w18p_term_relationships.object_id)
INNER JOIN n0w18p_postmeta
ON ( n0w18p_posts.ID = n0w18p_postmeta.post_id )
LEFT JOIN n0w18p_icl_translations t
ON n0w18p_posts.ID = t.element_id
AND t.element_type = CONCAT('post_', n0w18p_posts.post_type)
WHERE 1=1
AND n0w18p_posts.ID NOT IN (467)
AND ( n0w18p_term_relationships.term_taxonomy_id IN (2523) )
AND ( ( n0w18p_postmeta.meta_key = 'wpcf-g-level'
AND CAST(n0w18p_postmeta.meta_value AS SIGNED) = '2' ) )
AND n0w18p_posts.post_type = 'product-group-page'
AND ((n0w18p_posts.post_status = 'publish'
OR n0w18p_posts.post_status = 'private'))
AND ( ( ( t.language_code = 'en'
OR ( t.language_code = 'en'
AND n0w18p_posts.post_type IN ( 'post' )
AND ( ( (
SELECT COUNT(element_id)
FROM n0w18p_icl_translations
WHERE trid = t.trid
AND language_code = 'en' ) = 0 )
OR ( (
SELECT COUNT(element_id)
FROM n0w18p_icl_translations t2 JOIN n0w18p_posts p
ON p.id = t2.element_id
WHERE t2.trid = t.trid
AND t2.language_code = 'en'
AND p.post_status IN ( 'publish' ) ) = 0 ) ) ) )
AND n0w18p_posts.post_type IN ('post','page','attachment','avada_portfolio','avada_faq','product','specialist','product-group-page','product-image','product-link','suppliers' ) )
OR n0w18p_posts.post_type NOT IN ('post','page','attachment','avada_portfolio','avada_faq','product','specialist','product-group-page','product-image','product-link','suppliers' ) )
GROUP BY n0w18p_posts.ID
ORDER BY n0w18p_posts.post_title ASC
[/code]

Can you please help me to understand, how I can improve the loading time of my home page without having to use any caching plugin. 90% of the whole loading time is the http call itself. Is there any index I can build?

In order to access my site you need to have http auth credentials - please send me private ticket.

Thanks and regards,

[Christian Cox]

Hi, private reply fields are active here. Usually I see this type of bottleneck with deeply nested View structures or with a fairly large amount of content displayed. I'll be glad to take a quick look and see what we can accomplish. Our testing standard here is .5ms for any single query.

[Christian Cox]

Can you also share the basic HTTP authentication information?

[Christian Cox]

Thank you, I just ran several tests and I cannot replicate the issue where the initial HTTP request takes 20 seconds. I have deactivated the caching plugin, and refreshed the page several times. I see initial HTTP request load times consistently around 5-6 seconds. Am I misunderstanding the problem? Are you testing while logged-in to wp-admin, or while logged-out as a guest? I have left the caching plugin disabled for now.

I can run some tests on webpagetest.org if you approve - but since basic HTTP auth is required, that means the credentials will be visible on the test results and I didn't want to do that without consulting you first. If you can enable temporary HTTP auth credentials, that would be best. Let me know how you would like to proceed.

[Matthias Reichl]

Hi,

thanks for testing. Yes, you´re right. The loading time is about 6 seconds, but this is also too long. How can I improve the loading speed, which seems to be mainly related to toolset?

I think we don´t need any external test, since the issue is related to your database queries.

Regards,

[Christian Cox]

A caching plugin is usually the most effective way to speed up the initial HTML load time, especially when you have a site that runs a number of plugins like Toolset, WPML, Contact Forms, Relevanssi, Yoast, Heartbeat Control, and so on. With the WP Fastest Cache plugin active I see that initial load time is <2 seconds. Since you're using Avada, I would also consider deactivating Layouts and rebuilding any existing Layouts in Content Templates. One less plugin in the mix will help speed things up some.

You can also consider limiting any Views on the homepage to show fewer results, and limiting the number of nested Views and complex queries. For example, a View of taxonomy terms nested inside a View of posts nested inside another View of posts is going to slow things down considerably - not because of a problem with Views efficiency but because of the number of queries required to render each result. This is where caching can help significantly.

Use Query Monitor to check the query times, any individual query that takes longer than .5 ms should be investigated further. Check any custom code added that modifies queries, and make sure it's optimized for performance.

Beyond that, I can see you have some large images (1.7 and 2.7 MB images on the homepage) that should be optimized further, and a lot of resources that might be consolidated to make the time to first interaction faster.