Website Speed Optimizations in CMSs Part 2
Now that we know the basics behind each of the three main optimizations, there are certain negative effects that each one can produce. Some of them can only hamper parts of a page, while others can prevent a feature of a website from launching, while others if implemented incorrectly will actually slow down a website.
Module Caching Issues
Module caching is mostly harmless. This version of caching takes a snapshot of a section of your site ( the module itself ) and calls that snap shot state. The time that the "snapshot" is valid can be set in your back end parameters for each individual module in your Geoffresh site. If the module snapshot ever expired, it goes back and gets a new snapshot. But what if your users need to see an updated version of the module now and not wait for the module to update? This is where module caching fails as it will require the user to wait until the cache expires. A low time could be entered, but if the module needs to refresh instantly based on the user's state that is an issue.
As an example, let's say that the main menu of your geoffresh website has sections that only registered users can see. If the user arrives at your site and then logs in, they will not be able to see the updated menu items that only registered users can see. That is true until the module cache expires and the module refreshes and gives the user the snapshot of all of the items that they should be able to see.
Page Caching Issues
Caching and entire page can really speed up the speed of a website. Similar to module caching, it takes a snapshot not only of the modules of a website, but the entire page. This allows only 1 request for the page to be sent over and delivered to the user instead of the server reassembling the entire page every time.
The downside to this is when the page needs to change. For example, if you page has video animations on it, page caching may break that. Also, if a user requests the page from a mobile device and the cached page is for a desktop or tablet viewing device, the page will appear corrupt or incorrect on the device.
Compression Issues
Compression can be very difficult but yields amazing results if used correctly. Compression will reduce all of the JS and CSS files into one large file and then compress that file to send to the visitor. Some resources can have issues with being compressed such as not allowing values to be passed. Also different CSS files can be called based on the what state the visitor is in ( logged in or out), what device they are viewing your website on, or even what browser they are using.
Different JS and CSS files can be excluded from compression to avoid this, however, excluding too many files defeats the purpose of compressing as more files will have to be sent over VS just the 2. Also, the compressor needs the user to request a page before it can compress everything. This would cause a longer wait time for the first visitor to a page. The subsequent visitors would experience the full speed after the first fulfilled request though.
In the next page, we will discuss what are the best use cases for each of these.