Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

Scully

Full page cache with different devices

Recommended Posts

I just recently switched over to thirtybees after having used PS before for years. I would like to thank to the contributors of TB for their work at first place.

While testing TB with full page cache enabled I noticed that the full page cache delivers the page regardless of the device type requesting it. Hence once mobile devices modules are displayed which are not meant to show on mobile devices. In my opinion the only way to avoid this is to store different full pages, one for each device type - otherwise the device settings for the modules are not respected.

Or to make all these modules dynamic which would lead to a loss of performance. To overcome these issues I implemented some CSS tricks which at the moment set display:none at the beginning the left column but this is rather dirty.

Any feedback is appreciated.

Scully

Share this post


Link to post
Share on other sites

I figured to add some params to the Page Cache Key. I will test this for some time.

        return new PageCacheKey(
            $entityType,
            $entityId,
            $newUrl,
            (int) $currency->id,
            (int) $context->language->id,
            (int) $context->country->id,
            (int) $context->shop->id,
            (int) Group::getCurrent()->id,
            (int) $context->customer->id,					  // added comma
            (int) $context->getMobileDevice(),                // added    
            (int) $context->isTablet()                        // added
        );

 

  • Like 2

Share this post


Link to post
Share on other sites

Petr,

1) Thank you for the feedback. My changes were not quite enough. I am stil testing. However what I would NOT get so far is whye the table page_cache gets popultated with so many entries for the same entity. My start page (entity index) has around 14 or 15 entries. I doubt these are all from customers which are logged in. However I could not determine which factors are causing so many entries.

Maybe somebody can shed some light on this?

2) Using Customer ID as part of the hash makes logged in users almost uncachable. In my opinion it must be a better way.

regards, Scully

Share this post


Link to post
Share on other sites

One more addition: it is clear cache might add pages for each country, currency etc. But the pages in the db table have almost always all the same IDs.

Share this post


Link to post
Share on other sites

PageCacheKey is using following properties as a slicing dimension:

public function getHash()
{
    return Tools::encrypt('pagecache_public_'
        .$this->url
        .$this->idCurrency
        .$this->idLanguage
        .$this->idCountry
        .$this->idShop
        .$this->idGroup
        .$this->idCustomer
    );
}

If any property differs, then the new page cache entry is created.

I guess that the $url or $idCustomer is responsible for these extra entries. Don't forget that https://www.domain.com/en/ is different resource than https://www.domain.com/en/?whatever. Even though `whatever` parameter does not affect page generation in any way, thirtybees core doesn't know this. We don't know if this parameter targets some module behaviour, etc... So it must be considered important for caching purposes.

The reason why id customer is in slicing dimension is to prevent data leakage. Without this, page cache could quite easily cache customer's private data and show them to different visitors. I believe that it's probably good idea to disable the full page cache for logged in customers altogether. 

 

Share this post


Link to post
Share on other sites
On 3/29/2019 at 12:49 PM, Scully said:

While testing TB with full page cache enabled I noticed that the full page cache delivers the page regardless of the device type requesting it.

All devices should receive the same page. The way this page gets rendered is decided by CSS, in the browser.

Distinction between "mobile" devices and other devices is blurring and will blur more in the future. What matters is screen/window width. Somewhere on my TODO list is actually removal of this device type property. Not with high priority, though.

Share this post


Link to post
Share on other sites

Thanks Peter,

I found this part already but since not all hash data are own table columns it was difficult to figure out which values changed. So far I found out that if all query parameters are to ignore, there is still a trailing question mark remaining.

I'll update with my further findings an code.
Thanks again.

Share this post


Link to post
Share on other sites

I added a condition when preparing the new URL string, otherwise the question mark appears also with no remaining parameters:

            ksort($queryStringParams);
            $newQueryString = http_build_query($queryStringParams);
			if ($newQueryString == '' ) {
				$newUrl = $protocol.$_SERVER['HTTP_HOST'].$uri;
			} else {
				$newUrl = $protocol.$_SERVER['HTTP_HOST'].$uri.'?'.$newQueryString;
			}

 

Share this post


Link to post
Share on other sites
2 hours ago, Traumflug said:

All devices should receive the same page. The way this page gets rendered is decided by CSS, in the browser.

Distinction between "mobile" devices and other devices is blurring and will blur more in the future. What matters is screen/window width. Somewhere on my TODO list is actually removal of this device type property. Not with high priority, though.

Distinction is blurring indeed. But TB CSS also does not reflect device width as per default. Hence you get desktop modules shown on mobile devices. Having small screens in minde it doesn't look well with too much information. The other way around if you don't store information on the type of device on cached pages you might get a mobile view on desktop as well.

Share this post


Link to post
Share on other sites
4 hours ago, Scully said:

But TB CSS also does not reflect device width as per default. Hence you get desktop modules shown on mobile devices.

There should be no such thing like a "desktop module" or a "desktop view" or a "mobile view". That's all the same HTML, the same CSS, the same JavaScript.

thirty bees should reflect this, as it uses Bootstrap. Desktop users can even change their window width without reloading the page, pages happily switch between phone-type, tablet-type and desktop-type as the window gets dragged wider or more narrow.

Here's a nice video demonstrating this: https://developers.google.com/web/fundamentals/design-and-ux/responsive/videos/resize.webm

Which leads to the question: what's actually the problem? Some rendering issue?

Share this post


Link to post
Share on other sites

TB allows to choose which modules to display on which type of devices. As long as this setting is possible but full page cache doesn't respect it might be a bug. And yes, I am fully aware of the capabilities of CSS. But default TB does not work as the settings would allow. What I faced with TB default installation 1.0.8 was the following behaviour:

1. Categoriy Pages missing left column module output on desktop because the last cached version was from a mobile device.
2. Category Pages show left column moudule output on mobile devices where it is not set to display in the modules settings.

Share this post


Link to post
Share on other sites

This is by design. The cache would be huge if it generated a stratified cache like that. It would end up being a really deep rabbit hole when you factor in its not only modules for devices, but also user groups can be excluded as well. It would add so much processing in the end that the cache could become useless or huge very easily. 

Share this post


Link to post
Share on other sites

Ok, I am not unteachable. I follow a new way. enable all modules by default, change module CSS (for example for blockbanner) to get rid of displaying on mobile devices or change golbal.css to hide left column entirely. Then get rid of isTablet, isMobile for the cache. Only warm the cache for one type of device - which would then be desktop.

Share this post


Link to post
Share on other sites

I'll give it a try this way all enabled and only filtering on CSS leve. I'll report back my experience.

Share this post


Link to post
Share on other sites

I personally think that @Scully is right, device type should definitely be in page key dimension, because server *can* generate different content for different devices. 

Caching mechanism should not change rendering logic in any way, it should only cache the output. It should be consistent - the server should return the same page with or without cache being enabled. And that's not the case when device type does not take any part in decision process.

We could be smart about this, and consider different device types only when there is *some* module that is not enabled on some device. 

Share this post


Link to post
Share on other sites

Datakick, we are at the same page at this time. Nevertheless I changed my installation to get some experience with only one version of page stored independing of device type.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...