Full page cache with different devices

[Scully]

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

[Scully]

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
        );

 

[datakick]

Looks like a good start. If it works, please make pull request so everyone can benefit from this improvement.

[Scully]

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

[Scully]

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.

[datakick]

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. 

 

[Traumflug]

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.

[Scully]

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.

[Scully]

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;
			}

 

[Scully]

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.

[Traumflug]

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?

[Scully]

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.

[Traumflug]

I see, thanks.

[lesley]

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. 

[Scully]

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.

[Scully]

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

[datakick]

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. 

[Scully]

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.

[hojoos]

Hello. The world does not stand still and every day more and more amazing Smart Devices appear, they not only save your time but also make life easier. On the Internet, you can find a selection of the most popular and latest gadgets for any user. Feel free to start saving up for these cool tech innovations that you can find at 4Prototypes.com. I wonder which one would you choose? Guys, share your purchases.

Edited November 1, 2020 by hojoos