Building Lesti_Fpc2

I did start building Lesti_Fpc2. I always wanted a flexible and most compatible solution for Magento. That was never easy. So in Lesti_Fpc I did use the event controller_action_layout_generate_blocks_before as anchor. Just to explain, as anchor I mean the point were the Full Page Cache stops normal behavior of Magento and sends cached response. Normally you want to have this anchor as early as possible. My anchor was very flexible, but also not that fast as I expected.

Problems of old Lesti_Fpc

I made a test with Apache benchmarking tool on a product page in default Magento

$ ab -n100 -c10

Magento without Lesti_Fpc

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:   733  916  77.4    897    1121
Waiting:      709  891  77.8    874    1101
Total:        733  916  77.5    897    1121

Magento with Lesti_Fpc

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   406  532  61.5    526     903
Waiting:      396  518  60.8    512     892
Total:        406  532  61.5    527     903

Not that good. Just 59 percent of default Magento. We could say 1.7 times faster. Sure, with a bad template the differences would be bigger, but we want absolute performance. I always wanted the event controller_action_layout_generate_blocks_before as anchor cause in this moment Magento has build the hole session and has parsed the hole layout. So I just had to cut all non-dynamic blocks from layout, generate the dynamic blocks and replace them in the response. A second reason for this anchor was the possibility to make a difference between a category page with 30 and with 60 products. This is only possible with the value limit stored in customer session. But I just don’t want to miss this feature in Lesti_Fpc2.

Building dynamic blocks

An other problem was to build the dynamic blocks. I always have to render those blocks before sending response. But the better way would be to build those blocks before sending response of not cached actions. For example on the action checkout_cart_add. So I have build lazy blocks that are stored in session. But also lazy blocks will be rendered before sending cached response.

The idea behind Lesti_Fpc2

I just need an anchor that happens earlier. Many Full Page Caches set this anchor in front of Magento and want you to paste such a code at the top of index.php


This is maybe a few milliseconds faster, but this isn’t the way you should implement it in Magento. You should use the tag request_processors. How it works will be explained in this very good post from Luis Tineo. So I have build the file app/etc/fpc2_enable.xml.

<?xml version="1.0"?>

This is also a very early anchor for a Full Page Cache.

Nothing works at this moment

The big problem with this early anchor in Magento was always for me, that I have no customer session. And like I have explained above, I want to use the session to build a very flexible Full Page Cache. And not only the session is missing, you haven’t anything from Magento. You can’t get a helper, a model, a block or configurations from database on the normal way. At this point you are a little bit outside of Magento. Only a few things work. We could build all these things if needed them, but that would only go the way of Magento and that costs too much time. So the idea is to share the needed parameters from customer session in my own session. And also the dynamic blocks will be stored in my own session. With every request that isn’t cached I will render dynamic blocks if necessary and write them into my session. And I will share parameters in between my session and the customer session. For example the limit I have exaplined above.

The current Implementation of Lesti_Fpc2

At this moment I just had implemented the way Luis Tineo has explained in his post and as expected the time for response is incredible. The same test like above.

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:    25   37  10.9     31      78
Waiting:       24   35  10.3     30      76
Total:         25   37  10.9     31      78

We are 28 times faster.

Known problems will appear

To get a fast response time was never a problem. The real problem was always to let it work like Magento would behave without a Full Page Cache. Just a few things that are in my mind:

  • Parameters in Session
  • Messages Block
  • Recently Viewed Products
  • Form_Key
  • SessionID

These problems and I guess a few more have to be solved. You can find the code on

6 thoughts on “Building Lesti_Fpc2”

  1. Very interesting writeup, thanks!
    Since the session could potentially grow quite large with many rendered blocks stored in it, have you thought about compression maybe?
    Anyway, I’m curious to see how the project evolves.

  2. Hi Gordon,

    Looking forward to version 2 :).
    I think you don’t have to do everything in the request processing. You can also hook into response processing to do post-processing of the content you don’t have information for of at request time. This includes session specific content, because then you have all the information available to you.
    The hard part is now being able to identify at request time what is special dynamic content and put in a placeholder to be processed at response time. You can make a small test case for this using the form_key as it’s lightweight. It’ll be interesting to see the impact on your current benchmark.

  3. Hi Gordon,
    Congrats for your FPC extension! Finally a free extension well coded, following best practices and without any ads.
    Do you have any ETA about your new FPC extension? We recently updated my company magento website from 1.7 to 1.8 and our FPC extension stopped working. The project doesn’t seem to be supported anymore and is failing because of the introduction of formkeys in magento 1.8.
    I’ve tried your first FPC extension and even if it works perfectly fine it is considerably slower than our old extension that used and anchor in index.php (I know, bad practice xD) and AJAX hole punching.
    Reading this post I can see that you are perfectly aware of this issue and working on it. So I would rather wait some time for you to release your new extension than risking to buy one of those 350$ FPC extensions that could be badly coded and wouldn’t be any better than yours.
    So thanks for sharing your time estimation if you have any 😉

Leave a Reply

Your email address will not be published. Required fields are marked *