We run an online store and are looking for a FPC solution. There are a lot of players in the field and it is hard to choose one. We were using the Tinybrick Opencommerce Lightspeed Warp FPC but we are running into a lot of issues with it.
Make your Magento store 10x faster with this module that allows full page caching. Speed up Magento! Full Page Cache Magento extension reduces server load, optimizes magento speed and thus enhances SERP positions and sales conversion. Jul 17, 2017. Full Page Cache extension is the best bet for improving the page load time of Magento stores. Check out this excellent introduction to the extension. Full Page Cache extension is the best solution for a Magento store that significantly speeds up page load time, reduces the load on the server, improves website.
I would prefer a company that has live support but I know this is likely not possible. Our hosting company stated that Varnish would require four times more hosting power than what we currently have. We tried Lesti FPC but the speed improvement was very small.
Store owners only, can you please recommend a FPC solution that you work with that has significant speed improvement and offers good support and does not cause problems with the site? If you would include a link to your site for testing that would be amazing! We have already done a lot of speed optimization for the site on the hosting end and on the site itself. We were loading the page at 2.5 seconds but after we decided to make the whole site EV SSL based on the new Google recommendation, our load time is not sitting at around 4.20 seconds load. We are hoping that the FPC solution will be able to help out with the load times. My company develops which is a FPC solution so I'm not a store owner but I will make a few comments on your question.
Firstly only you can really make a decision on which FPC solution is best for your store - I'm not going to say our solution is the 'best' as it means very little, everyone who develops FPC solution is probably going to say that. I would however recommend you trial all the options you can for free before committing to one, that way you can test the extension and the support before you buy (you can trial ours if you are interested). In my opinion if a company is confident in their product they have no reason to not offer a free trial. Secondly Magento has such wide possibility for development it's completely impossible for any solution to work flawlessly on all stores.
If any FPC developer says their solution will work without fail on every install - just don't believe them as it won't be true. The key here is the versatility in the way the extension has been developed and the willingness of the developers to help you make the extension work correctly on your particular install. If they are unwilling to help, then you probably want to think about whether you want to go with them or not. Essentially if the extension has been developed well, and the store has been developed well, it shouldn't be too hard to get caching working correctly even if there are a few initial issues. Thirdly if adding SSL has increased page load times by nearly 2 seconds - you definitely have a problem there. The only overhead SSL adds is the handshake and this shouldn't take anything like 2 seconds to complete - it should be adding milliseconds not seconds onto load times. It sounds like you have pretty decent page load times already assuming you can get SSL sorted out and the 2.5 seconds is uncached load times so you are in a good position to consider a FPC solution, but as I said above, look at what available, test what you can and make your own mind up.
Obviously I hope you choose ours, but if you don't that's ok;). No cache is the best cache. Whilst your question is 'What is the best cache', your problem is 'How can I make my store fast'. Sadly your question will do nothing other than solicit opinion, rather than fact, so contrary to site etiquette, I'm going to solve your problem, not answer your question - because you are asking the wrong question. Caching!= Performance If changing your store from HTTP to HTTPS has penalised page load times by 1.7s, then you have a number of issues.
• Out of date CPU with no support for SSL hardware acceleration (check with grep aes /proc/cpuinfo) • Old OpenSSL library without support for hardware acceleration (ie. Less than 1.0.1) • Poor cipher selection leading to inefficient use of client/server hardware Any competant hosting company could identify and fix this within seconds.
2.5 seconds to load a page in Magento is exceptionally slow, even with EVERY Magento cache OFF, pages should load in less than 0.7 seconds. Hello Sonassi! Thank you for your useful feedback. Our current hosting company is pretty well optimized to run Magento. I already had our developer work extensively on the site to get the 2 second load time.
While your feedback is useful and I will ask our hosting company about it, the sites built by your company do not load that fast. Checking your portfolio, I checked 5 random site.
One loaded super fast, less than a second, the rest were 2.5-4 seconds load time using GTmetrix. – Nov 3 '14 at 22:26 1. Shopping questions aren't permitted, they will merely drive opinion based responses.
Given the underlying tone of the OPs post was how to make his store faster, I answered both his questions about SSL performance and how to address underlying store performance - which will always boil down to two things, hosting and code. The only way to isolate the former is to try another host, it's quick, free, painless and definitive. The only way to solve the latter is to profile the code. The OP doesn't need a cache, he/she needs guidance. – Nov 4 '14 at 0:03 1. HHVM is still under heavy development and should not yet be used in production installs.
Performance gains are also actually not great and nothing like the improvement you see from implementing FPC/Varnish - rewrite Magento in hack and could then be worthwhile. Using it also currently introduces a bug when applying coupon codes where the total is wrong (there is a fix) and from my testing the HHVM process quits for no reason from time to time so if you don't have an upstart (or similar) job to start the process again your site will go down. Wait a few more versions and then think about HHVM. – Nov 5 '14 at 10:56.
The ‘View’ of Magento’s MVC pattern implementation is divided in two parts: Layout and Template. The template represents a HTML block while layout defines the location of the block on a web page. Magento provides ultimate flexibility and re-usability of design by layouts defined in XML. Layout XML Layout XML files can be found in app/design/frontend/[package]/[theme]/layout. Each Magento module may define its own layout XML file in the config.xml file.
Mymodule.xml Each layout XML file represents its own design update. For example, catalog navigation is part of the Mage_Catalog module and Mage_Catalog module defines a layout update file: catalog.xml. So the block for the catalog navigation and its location on the page is defined in catalog.xml. Before the page is rendered, Magento loads all configured layout update files and its design updates to determine which block is to be rendered at which location. Here is an example layout XML file contacts.xml for the Mage_Contacts module. The root element of any layout XML file is. Contact UscontactsContact Ustrue Contact Us Form page/2columns-right.phtml Contact Us Layout Handles First level child elements of the node are called layout handles.
Each layout handle represents an update to the page layout. It may define new blocks to be included in a page at a specific location or remove a specific block from the page. It may also define the modifications in existing blocks already included in the page by other layout XML files. After Magento loads all layout XML files, it determines which layout handles need to be processed. Normally, the layout handle is selected based on the controller action being executed.
In most cases, Magento loads the layout handle with name: [module_front_name]_[controller_name]_[action_name]. For example, when the contact us page is requested, then index action of index controller of Mage_Contacts is executed. Module front name of Mage_Contacts is contacts. So the layout handle to be processed for the contact us page is contacts_index_index. For any page, Magento always processes the default layout handle.
So the updates defined in default handle are processed for every page regardless of which part of the site we are browsing. As the example above illustrates, the Mage_Contacts module requires a link to the “Contact Us” page in the footer on every page so the specific elements for it is defined in the default handle. These elements are discussed further in the next section.
Layout Elements A layout handle may contain the following elements: • label: This element is introduced since Magento 1.4. It defines the label of the handle which is shown as a descriptive reference in some areas of the admin panel. • reference: This element is used to link an already defined block in any layout XML. To add any child block to an existing block, to modify attributes of an existing block or to perform any action on an existing block, the reference element is used to link to the existing block. The reference element must have a name attribute which refers to the existing block’s name. • block: This element is used to define a new block. This element is usually defined inside a reference element when we want to create a new block.
The block element must have a name attribute, which is a unique identifier of the block in the layout and a type attribute, which defines the block class name. If the block is of type or subtype of core/template, it can also have the template attribute which defines the actual phtml template file to be used for rendering the block • remove: This element is used to remove an existing block from the layout. The block to be removed is specified with the name attribute.
• action: This element defines an action to be performed on the referenced or newly defined block. An action is simply a method of the block instance on which it is to be executed.
The method attribute defines the method name in the block instance and all child elements of the action element are treated as parameters to the method. This element can be placed inside reference or block elements. • update: This element loads an existing layout handle into the current layout handle. It provides a kind of inheritance of layout handles. It must have the handle attribute, which defines the handle of the block to be included. For example, all customer account pages have a similar layout and apply some common layout updates.
So instead of defining all updates for the individual pages, a common layout handle: customer_account is defined in customer.xml as: Customer My Account (All Pages) page/2columns-left.phtml my-account accountcustomer/account/Account Dashboard account_editcustomer/account/edit/Account Information address_bookcustomer/address/Address Book This handle is then loaded on all account page handles. Here is an example of the customer address page handle in the same customer.xml file: Customer My Account Address Book So when, the customer address page is rendered, the layout blocks defined in customer_account are also applied to the page.
Rendering Process Before rendering the page, all block elements defined in the layout are instantiated. Nested block elements define child blocks. If any block element defines an output attribute, then it is considered as an output block. Only the output blocks are rendered and added to the response. All other child blocks are rendered only if they are called by the parent block. Let’s see how this works.
In Magento’s default theme, the block root is defined as an output block. This block is defined in the page.xml file.
With the particular value of the template attribute, this block defines the page template to be used when rendering it, i.e. 1 column, 2 columns with left sidebar, 2 columns with right sidebar, 3 columns etc. By default, the 3 columns template is assigned to the page.
There are also other child blocks defined under root like head, header, breadcrumbs, left, right, content, footer etc. These child blocks are rendered in the root template file ( 3columns.phtml) by calling something like this: echo $this->getChildHtml('header'); In any template, the child blocks can be rendered by calling the getChildHtml() method as above and passing the child block name as the first argument. If the method is called without arguments, it will render all child blocks of the current block that are defined in the layout XML for that block. Hence, Magento processes layout using a recursive rendering process.
First the root block then its child blocks and then the child’s child blocks and so on. Putting it all together Let’s look at the example of contacts.xml file.
The goal of this layout update file is to add a footer link to the contact us page if contact us is enabled in the system configuration and define the page structure of the “Contact Us” page. There is already a block footer_links defined in page.xml file to display links in page footer. The footer_links block has an addLink method to add new links within the block.
So here, the existing footer_links block can be referenced and the addLink action can be called on it with certain parameters to add a “Contact Us” page link to it. As the “Contact Us” page link needs to be added in the footer for every page this should be defined in the default handle.
Contact UscontactsContact Ustrue Here, default handle contains a reference to the footer_links block and performs an action addLink on it by passing the parameters label, url, title, etc. Also, in this case, the attribute translate is used to define which parameters need to be translated before passing them to the method.
In the above example, label and title are translated using the current locale. The translation will be searched with the module scope defined in the attribute module. The attribute ifconfig defines the system configuration key to be checked before performing the method action. The system configuration key used as value of ifconfig, are normally defined as Yes/No type configuration values and return a Boolean value. If configuration returns false, the action will not be performed. In our case, if value of contacts/contacts/enabled is false, i.e.
Contact Us is disabled from system configuration, the action to add the link will not be performed and the Contact Us link will not appear in the footer. Ifconfig can only be used within an action element and only when the action needs to be performed if a particular configuration value is set to ‘Yes’. Contact Us Form page/2columns-right.phtml Contact Us As mentioned before, Magento automatically determines the handle to be loaded on the basis of a current action being executed. In case of the contact us page, it would call the Mage_Contacts module, IndexController and indexAction. The front name of Mage_Contacts is contacts. So the layout handle would be contacts_index_index. The label is given as Contact Us Form to identify the page in some areas of admin panel, for example the widget instance creation form: Next, the Contact Us page should have two columns with right sidebar.
As explained in the previous section, the page template is defined by the root node and by default uses the 3 column template. So, to modify this for the Contact Us page, the root node is referenced here using the reference element. To assign a different template to the page, the setTemplate method should be called. So, an action element is defined to call the setTemplate method with the desired template path as a parameter: page/2columns-right.phtml Finally, in the main content area, a contact form should be displayed. To add the contact form block, the content block is referenced and a new block element is defined to include the contact form: Block Types Magento defines some built-in block types which are widely used in layout.
• core/template: This block renders a template defined by its template attribute. The majority of blocks defined in the layout are of type or subtype of core/template. • page/html: This is a subtype of core/template and defines the root block. All other blocks are child blocks of this block. • page/html_head: Defines the HTML head section of the page which contains elements for including JavaScript, CSS etc.
• page/html_header: Defines the header part of the page which contains the site logo, top links, etc. • page/template_links: This block is used to create a list of links. Links visible in the footer and header area use this block type. • core/text_list: Some blocks like content, left, right etc. Are of type core/text_list.
When these blocks are rendered, all their child blocks are rendered automatically without the need to call the getChildHtml() method. • page/html_wrapper: This block is used to create a wrapper block which renders its child blocks inside an HTML tag set by the action setHtmlTagName. The default tag is if no element is set. • page/html_breadcrumbs: This block defines breadcrumbs on the page. • page/html_footer: Defines footer area of page which contains footer links, copyright message etc.
• core/messages: This block renders error/success/notice messages. • page/switch: This block can be used for the language or store switcher. This is a list of only commonly used block types.
There are many other block types which are used in advanced theme implementations. Good to know! Some things I’ve been struggling with local.xml were/are: firstly simply just finding the reference names for the parts of the layout I want to alter!
Then finding the handle name for the specific parts I want to work with eg ‘tags_popular’. I’ve been looking for a definitive reference for action names and their uses. Loads of tutorials cover just removing stuf but not seemingly simple stuff like moving and reordering the page components.
I could go on and on! I look forward to future posts. Really useful resource, thanks again. We want to be able to re-order the attributes displayed when we compare products. Currently the attributes are displayed in the order they were created. For example when comparing attributes they display as:: Name Manufacturer Item Number Brightness Weight Color Size If we want to add a new attribute such as “LUMENS”, it will display at the bottom of the list, but we would like to have it display between Brightness and Weight. We cannot find a way to reorder the display to order the attributes as we would like them to display.
Do you have a suggestion or would you be able to assist us with this project? Magento’s layout xml is for controlling the content that appears on the pages in the various areas of the site. This doesn’t affect the implementation of the responsive design frameworks since those mainly affect the skin CSS using @media queries which are independent from the layout. Look at is this way: The layout xml governs the generation of the HTML and content on the pages. Your skin CSS and JS govern what happens with the HTML and content on the browser front-end which is where the responsive design is active. Hi, Thank you so much Robert for replying, Yes I see clearly now, the changes could affect the templates too, I ve noticed that there’s no header or nav tag of HTML5 in there, which using media queries does require. I ve spent 2 days just trying to make the categories responsive, but it seems to be very hard work!!
My question if you allow me is: could magento existing themes turn reponsive? Or they have to be created that way from zero? In the two cases it seems to me that it would be the hardest choice for a cross media strategy, am I right?