Just a word about Full Page Cache

[movieseals]

Hey guys!

Just a word to talk about the full page cache in TB.

I have been on Prestashop for about 3 years and a little more than a year now on TB. I much prefer my experience with TB than with Prestashop, especially support wise.  The people here are great.

I have ALWAYS had issues with speed with my site.  I score high grades on various speed tests: image opimization, js and css optimization, etc.  I have a site that sells comic books and graphic novels, so big images and lots of them is basically a must.

As a result, despite using webp wherever I can, I always had issues with speed.

TTFB (Time to First Byte) was always the worst.  I have been struggling with this for years.  It had become my holy grail - and a great source of frustrations.

And tonight I had an epiphany.

I was already using the full page cache in TB, with the redis server cache setup.  It would improve my TTFB intermittently but on webpagetest.org, I would inevitably oscillate between an F (most times) or a C (very infrequently).

I always cached all the hooks, that section is all green.

I had used the controller section sparingly, mainly because I had little understanding of what it exactly cache.  It is not clear I think from a pedestrian point of view.  So I cached what I thought would not be a big deal.  I was mostly afraid of caching something that should remain dynamic.  And still struggled with TTFB.

So tonight, I decided to cache everything in the Controllers section.  And then ran several tests to see if it caused any issues.  So far so good.

And to my surprise, I now get a consistent A in webpagetest.org.  Everything seems to work fine on both backend and front end.  For years, I have bought modules after modules to supposedly help with caching, with worst results than the vanilla TB full page cache I was clearly not even using properly!

On GTmetrix I get a Pagespeed score of B! 85%, which I never ever got close to and on YSlow, I score a 77%.  Still room for improvement but lightyears ahead of what I used to get!

My heavily filled with images site now loads in 2.5 to 3.5 seconds on average.

All that to say, this is so far the best, most efficient cache system I have seen for a Prestashop style operation.  You guys just need to explain better how it works because it really does work like fire!

Thank you so much!!!  Really!

 

Edited April 9, 2020 by movieseals

[datakick]

I remember a joke about intel processor FDIV bug. It was something like

A: Hey Pentium, could you calculate 5.0 / 2.0 for me please?
P: Sure, it's 2.51
A: But that's not correct...
P: Yeah, but look how fast I get the result

With FPC you can pretty easily get to the same state. You should test your site extensively, and check how modifications propagates across different areas of your site. For example, if product becomes unavailable, look if it's marked correctly both on product page, and on category page... 

I'm afraid you will find plenty of inconsistencies soon

[wakabayashi]

@datakick This joke made my day 🙂

[Pedalman]

When I hear that joke I always have to think about another nice aspect of life.

Anyways, Movieseals,

I thank you for sharing your experiences and I want to ask you if you could also find the time to write or to "youtube" a tutorial on how to set up the fullpage cache. I followed the hints in this forum not to activate it. But I wonder if I could cache certain parts of our online shop that are not dynamic and where I can be sure not to run into any problems where old information is shown (cached) where it should never.

 

[movieseals]

9 hours ago, datakick said:

I'm afraid you will find plenty of inconsistencies soon

@datakickSo far everything seems to work as intended but if I understand you correctly, it shouldn't? At least in some instances?  Is there something I should particularly look for? 

I will keep looking, but so far every tests I made work: orders, new customers, blog posts, searches, etc.  The only thing that appears to be funky is guest checkout so far. I have not finished testing everything but so far so good.  I have 65,000 products so hopefully I do not need to check every single one of them!

@pedalman Sure, I will look into doing something like that, once I can confirm that everything works as intended, as some of the devs here seem to think there might still be issues.

Edited April 9, 2020 by movieseals

[rubben1985]

I never activated anymore the FPC but this topic make me wondering if there is at least a "safe" setting. I mean, the options that seems to work well, and ignoring those with "potential" problems. Maybe we can gain some extra points in speed without risking.... or maybe there is not such safe options?

[movieseals]

Well, here is an anomaly.  I get this error on the front page: YOU CANNOT PLACE A NEW ORDER FROM YOUR COUNTRY. SLOVENIA

I am in Canada, not Slovenia.  The country of Slovenia is inactive, both in countries and in the geolocation section.  I am on TB 1.1.x and in the Maxmind module, the database is OK - it is a fresh one downloaded from the Maxmind site.

I disabled the full cache for the cart, to no avail.

[Traumflug]

18 hours ago, movieseals said:

So far everything seems to work as intended but if I understand you correctly, it shouldn't?

It can't. One cannot cache dynamic content.

As people refuse to believe this, Full Page Cache was introduced, which is kind of a simplified template engine in parallel to the already existing one and moves responsibility for correctness from the engine to the user.

[movieseals]

4 hours ago, Traumflug said:

It can't. One cannot cache dynamic content.

As people refuse to believe this, Full Page Cache was introduced, which is kind of a simplified template engine in parallel to the already existing one and moves responsibility for correctness from the engine to the user.

Not sure if it is a matter of believing or not, at least in my case.  It is more of a matter of correctly understanding.  What is obvious for you guys might not be for people who are just selling things and not technicians.  I am agnostic when it comes to caches.  I just want a smooth user experience.  If things do not need to be cached, then they shouldn't.  It would just be nice to know which one.  Some seem obvious, such as the cart, yet even "full page cached" it appears to still work as intended.  Better than with other cache modules I have had.  I assume user login and accounts should not be cached either.  Cache seems to flush when product quantities change.  So perhaps a little more clear guidance could lead to a compromise that would benefit everyone.  Just saying.

[Traumflug]

18 hours ago, movieseals said:

What is obvious for you guys might not be for people who are just selling things and not technicians.

Why don't you just believe technicians, then. Quite a number of merchants search for a silver bullet despite it was said many times such a bullet doesn't exist. The guidance you ask for is very clear: don't use full page cache.

If you want faster page loading times, reduce modules and content. Uninstall modules, don't just disable them. thirty bees is very fast by default and can be customized heavily with keeping this performance. Good example is @wakabayashi's technically brilliant https://www.chesspoint.ch/

 

[Traumflug]

To add a technical datapoint: page caching of any kind can only cache the HTML part of the page, the initial page load. That's where all the PHP voodoo gets executed. All the stuff after that initial page load, CSS, JS, images, whatever, isn't subject to page caching, no matter how it's configured. And one can easily measure how long this initial page load takes.

Instrument #1: use Curl on the command line. Like:

time curl https://librairiezbookstore.com/

Instrument #2: browser's developer console. Open it, click on the 'Networking' tab, then reload the page. This generates a list of all the resources loaded, look at the very first one. It should report loading time.

With both instruments I get between 540 milliseconds and 590 Milliseconds on librairiezbookstore.com. That's what one can gain. Very good setups take like 350 milliseconds, so even the best imaginable page caching could never improve page loading performance by more than 0.2 seconds. If one sees more improvements for the complete page load, it's the result of content no longer displaying.

[Traumflug]

And yes, I hate to have to sound so disappointing here, being well aware this doesn't make me a hero. Hero will be the next guy coming along with a silver bullet promise, even if it breaks shops.

[Pedalman]

Well,

perhaps we should start a sub forum with performance tips.

I bet most of PS and Thirtybees merchants use still shared hosting, at least I do :(, and I believe there are steps to take if a small merchant grows that relate to this topic.

Better host package that suits the online-shop, CDN or not, image quality, number of processes (modules, scripts etc.).... you name it. As said most of the merchants do not understand those performance settings in an online shop.

And there are also those in the 'console' of your hoster. Here you could mess up things easily, too.

Our shops generate at the moment about 500 visitors if I get that right. I am pretty sure that my shared host server (Hetzner) has enough resources to handle that 🙂 However, I like to believe that if my shop initiates faster ...more customers...

In a nutshell, surely I am interested in a guideline for best TB settings hand in hand with my host's one's (APC, OPC...). And which steps make sense to take to perform better.

 

I know that some time Lesley offered his services relating to this topic. And perhaps this is the better idea than a subforum since it makes most probable no sense if we merchants try to discuss about things we do not understand. And a technicians' knowledge is worth gold here and most probably should be service you hire. I do not know. Except it is difficult for a merchant when you see other sites that look the same as yours but load fast.

You want to turn each screw in your shop and host's console despite the fact you do not know what you are doing.

[Briljander]

1 hour ago, Traumflug said:

Good example is @wakabayashi's technically brilliant https://www.chesspoint.ch/

Yeah, always been amazed of how fast @wakabayashi site is. Tell me your secrets 😉 

[Traumflug]

1 hour ago, Briljander said:

Yeah, always been amazed of how fast @wakabayashi site is. Tell me your secrets 😉 

I didn't design this site, nor do I have any insight, but just look at what's there. More importantly: what's not there.

Front page: phone/tablet-type menu only, no menu optimized for desktops. This likely means a lot less HTML, a lot less JavaScript and a lot less CSS. No image slider, no blinky-blinky (which slows down the browser), just one font, no Google Analytics (but G tag manager), no Facebook.

Category page: while many sites have a whole plethora of modules in the left column there, Chesspoint has exactly one: layered navigation.

[wakabayashi]

Thanks for the warm words regarding one of my shops 🙂 Interesting because, since a few weeks I am no more that convinced, that my site is super fast or well designed ^^ But ok maybe I am just too ambitious. I am thinking of completly rewrite "my" theme. I believe, there is still room for improvements 🙂

Actually @Traumflug said everything, that is relevant:

• Get a serious hosting package. We have a dedicated server (unmanaged) and pay 70$/month. If you can't afford this, you have probably more important things to improve, than the loading time.
• Technically I use css/js caching and APC server side caching. Full Page Cache is completly deactived.
• Deactivate css and js caching in Bo. Use browser console and check which files are loaded. How big are they? Are they really needed?
• Check your Content. Do you really need the tags on left column? You really need to promote your local store there? For external modules, check them with profiling in BO, how much they slow down...
• Defer images, if they are below the fold

In general I would say, that the page loading time is one of the strengths of thirty bees.

[toplakd]

I'm running my site from servers in Germany and get pretty satisfying results with worldwide loading times.

No caching, minimum modules, webp, custom fontset with only icons that are used, no Facebook, no analytic. Basically barbone.

Only options that are enabled are the CCC options.

Also no cdn or cloudflare.

No cookie consents due to only session cookie, and no outside loading requests.

Ok, my theme might look weird compared to other web shops, but it's for very specific group of products and customers.

And at the end I'm paying only 70 eur yearly for 2 virtual core, 1gb ram, 60ssd, litespeed server with cPanel.

And I'm serving only 216kb with 10 requests for the landing site 🤠

Thirty bees is really fast, but with to much installed modules and stuff you can also slow it down.

I've been playing with caching for some time, but always had the feeling my site feels snappier without any cache. Tested for some period of time from different worldwide locations.

Edited April 12, 2020 by toplakd

[cienislaw]

https://wiki.mydevil.net/PrestaShop

my hoster recommends:

• turned off smarty cache;
• turned off all CCC functions;
• ciphering set to Rijndael with mcrypt lib;
• caching set to memcache or APC;

explanation: CCC functions mostly compress and optimalization CSS, JS and HTML files, which means more CPU usage and possible delay in page generation. on server side there is already ZFS file system cache and extra task like compression and file optimalization results can be smaller than expected and could extend time of script execution.

I've set up settings like this and didn't bother anymore. it just works.

[Traumflug]

4 hours ago, cienislaw said:

CCC functions mostly compress and optimalization CSS, JS and HTML files, which means more CPU usage and possible delay in page generation

They do this only once and store the combined file, then always serve this. Which means no additional CPU usage when serving pages. Disadvantage is, it always serves all available CSS/JS, even those chunks not needed on a particular page. Advantage is, it's always the same file, so this load happens on the first page visited, only.

Regarding HTML compression: one of the first things Michael Dekker did for thirty bees was to remove it. Because HTML compression indeed takes longer than just serving the longer, uncompressed file.

As always: measure, measure, measure. Developer consoles of Firefox and Chrome both show page loading time at the very bottom. Reload a page five times, take the average. Then change a setting and measure again. Numbers are much more reliable than feelings and guesses.