What makes webpages slow & why is it more so in case of Magento?
A webpage carries a bundle of data in a variety of forms and when it comes to eCommerce the size of data is all the more high. Right from the color it takes to the action is allows a user to perform, a webpage has different technical avatars off-stage which need to be carefully tailored for achieving a racy loading time.
Though Magento is the most sought after eCommerce platform, it is often accused of resulting in a heavyweight website as it uses EAV and several other concepts to best suit the eCommerce business. Optimizing a Magento website is certainly a daunting task and especially when a website is getting popularized the necessity for a flawlessly performing website becomes all the more important.
In this case we’d like to share our magento speed optimization acquaintance gathered while experimenting various cloud hosting and coding technicalities to optimize Apptha.com, an ecommerce store that holds thousands of free and premium extensions and themes on open source ecommerce and content management platforms.
Research on how loading time can affect your customers
eCommerce giant Amazon’s research has that reducing page loading time by 100 milliseconds will increase customer conversion by 1%.
Forrester Research has that online shoppers love pages that load within 2 seconds. At times were loading process extends to 3 seconds or more a majority of them abandon the site and hardly revisit.
Another interpretation of user expectation on page loading speed is that 47% of shoppers expect a webpage to load below 2 seconds and 40% of users will abandon a website being loaded longer than 3 seconds. Internet giant Google says that keeping a shopper to wait for 400 milliseconds costs a potential customer.
These results from top research firms, ecommerce and internet giants clearly suggest that these metrics are mandatory loading speed values for a business website. In other words it’s the bench mark which has to be put to serious consideration before getting into Magento website performance optimization. Now, how good is your site in terms of loading speed? If we are way behind, continue reading on.
How do we speed up magento websites using the apt optimization methods?
Load balance
Among the key server side technical changes we underwent, Load balancing was the first technique to be implemented to improve the performance of the Magento powered ecommerce website.
Distribution of the load was our next step towards making our application a nimble one and for this we made use of load balancing concept. In general, load balancing distributes the traffic (requests) across various servers which host an application.
The load balancer does the duty of balancing the requests by distributing them in equal measures to several servers. This accounts for the web application’s responsiveness, availability and quick loading time.
When requests are balanced between multiple servers the chances of a server becoming a point of failure is less. When a server becomes fully loaded or unavailable, the requests are directed to the other servers in the pool thus making the application available for every user. As per the demands of the application, more servers can be added to host the application’s data and the load balancer will start sending the request to the new server as well.
If your site speed is lagging, interact with our experts to get a solution
Auto Scaling
Auto Scaling, as the name suggests lets your web applications to scale up and down on the go without friction. It improves your website’s availability, makes it more fault-tolerant and saves money as you pay only for what you use. Auto scaling can be done using Amazon EC2 (Elastic Cloud Computing). In order to auto-scale using EC2 proper instances have to be picked.
There is no EC2 instance that goes well for all applications or in other words choosing the EC2 instance completely “depends” on the nature of an application. Amazon provides a wide range of EC2 which differ by the capacity of CPU, memory, storage and networking. These capacities mixed in varied proportion gives the liberty to choose the appropriate EC2 for any given application.
Launch configurations are generally the launch pads used by an ‘Auto Scaling Group’ for launching the EC2 instances. While creating a launch configuration, certain key information for the instances like instance type, AMI (Amazon Machine Image) ID, key pair and others necessaries will have to be provided.
Launch Configuration has to be specified while creating an Auto Scaling Group. A same Launch Configuration can be specified with different groups but only one Launch Configuration can be set for a group at a time.
Auto Scaling Groups
A group of EC2 instances of similar type is collectively called Auto Scaling group. There might be situations where you need to increase the number of instances in a group for improving efficiency or decrease it for saving expenditure in case of low requirement. Here is where Auto Scaling group comes into play.
Auto Scaling Groups can be used to automatically scale the number of instances based on condition or maintain a fixed number of instances no matter how high the level of requirement goes up. The key idea behind Auto Scaling service is to automatically scale and manage the number of instances in a group.
Scaling plans
Scaling plans offer opportunity to scale the auto scaling group. Scaling can be done manually or set based on a schedule or a demand. Manual scaling lets us you to specify the maximum, minimum or fixed capacity of your auto scaling group.
Schedule based scaling is an apt choice for applications whose requirement are predictable or in other words, for the application which require scaling in certain fixed periods. In this case, the scaling time and date settings will get the work done.
Scaling on demand is something which requests the Auto Scaling group to wait until a condition is reached. For example, one can create an action that orders more flow of EC2 instances when the load capacity is constantly staying above 90 percent for 10 minutes.
Auto Scaling Lifecycle
The EC2 instances launched in an Auto Scaling group using launch configurations has a lifecycle. When a new Auto Scaling group is created or whenever a ‘scale out’ occurs, the lifecycle of an instance starts. A new instance will then be injected by the Auto Scaling group.
The life of an instance ends whenever a scale in event occurs and during this time an instance will be terminated and detached by an Auto Scaling group.
Is Poor Loading speed hindering your progress?
InService state
Once an instance is launched into an Auto Scaling Group it is put to serve the application and this stage is called the Inservice state.
Scale Out
As discussed earlier the Scale Out action can be performed using the scaling plans.
- Manually set low, high or desired capacity of an auto scaling group.
- Trigger instances based on a condition.
- Create time schedules to increase or decrease instances.
- Check for the health status of an existing instance either manually or automatically.
Scale In
The creation of Scale In is similar to that of Scale Out and it is mandatory that each scale out event should have a Scale in condition set so that the instances get detached and terminated properly.
As the level of Apptha’s user request varies from time to time, the need for auto scaling was a must to improve its performance. Since Apptha is completely being hosted on Amazon Web Service, we made use of Amazon EC2 instances through the Auto Scaling concept.
Auto scaling on Amazon Elastic Compute Cloud environment helped us in scaling up and down, based on the requirement, which ensured an optimum performance level. Moreover the availability of tools from Amazon EC2 to build failure resistant applications proved handy in eradicating common failures.
Relational database service
Relational Database Management is a web service from Amazon which aims at simplifying the difficulties related to setting up, operating and scaling a relational database in the cloud. RDS relieves database administration tasks by taking care of it and so your focus can completely be on your business application.
Scaling up the compute and storage resources of a database can be easily done using API call. RDS is also beneficial considering the facts that they can help in automated backups, database snapshots, and automatic host replacement.
Amazon RDS environment is highly secured. The instances of an application can be run in Amazon Virtual Private Cloud (Amazon VPC) which enables the isolation of the database instances of that particular application thus making it connectable to another IT environment through an encrypted IPsec VPN.
How Apptha’s database was stabilized with Amazon’s RDS
Apptha’s growing customer base posed a challenge on the server as user database kept on expanding forever and and also to improve our loading speed we were expected to come out with a solution for handling it. With the help of Amazon’s RDS (Relational Database Service) we automated our database management tasks.
RDS provided a scalable platform through which setting up, operating and managing the expansion of databases were made easy. RDS automatically backed up our database by patching up with the database software. We were able to define a time period for the retention of backed up database and enable point-in-time recovery which helped us in retrieving database files for references and other needs.
Apart from this speed optimization techniques mentioned below, there are other techniques we deploy.
Memcached
Page requests often take longer time to respond as the server takes time to locate and retrieve it. We made use of Memcached concept which is briefly known as high performance distributed memory object caching. This concept lets technicians to store data in a local web page or in other words, a temporary cache/static webpage, so that every time a request for a page is initiated there is no need to run a database query. Instead, data will be delivered from the memcache resulting in a better loading speed of a dynamic web application.
In parallel with the server side changes, we also carried out a few practices which helped us in equipping our website to handle stress and unexpected fluctuations.
Content Delivery Network (CDN)
Amazon’s CloudFront is the key for establishing a content delivery network. Servers in a content delivery network will have various edge locations in which the data will be replicated. The role of edge locations is to reduce the traveling distance of an http request. When a request is sent, data is fetched from the nearest edge location thus saving time hugely.
As CloudFront is optimized to work with AWS services like Amazon EC2 (Elastic Cloud Computing) Amazon S3 (Simple Storage Service), elastic load balancing etc, it can be used to route a server in a CDN to data stored in EC2, S3 etc.
Amazon CloudFront can be managed using the AWS Management Console which allows you to monitor spending and manage security credentials. Dynamic contents that keep changing from time to time and streaming contents can also be delivered using CloudFront. Detailed report insights on cache, highly accessed contents, origin of content requests and user action can help finding the performance of your application and demand of contents. CloudFront improves security of your data significantly. Contents can be restricted from being accessed for users and geographical locations. Advanced SSL features like Session Tickets ensure maximum safety.
CloudFront is completely elastic and hence it alters dynamically based on the requirement in case of traffic highs and lows. Its caching technique uses multiple layers of caching at every edge location. Whenever a repeat request is encountered Amazon CloudFront instantly collapses it before taking it to the origin server. Using a network of edge locations spread across the globe, CloudFront makes sure that each and every single request to your web application is processed and rendered faster.
For Apptha.com, we used the CDN concept to improve the speed of the content delivery based on the location from which the requests are originating and for this Amazon’s CloudFront came in handy.
For Apptha.com, using Amazon CloudFront, we managed to replicate the contents of our ecommerce website, including dynamic, static, streaming, and interactive contents, in three different edge locations. This helped us in improving the speed of data delivery as the CDN retrieves information from the nearest Edge location possible.
Minimizing http requests
The rapid increase in the number of users triggered the http requests to a new high which took the speed off Apptha’s loading time. We looked upon all possible channels to minimize these requests and also deployed sprite concept in the phase of achieving it.
The next step was to compress the heavy duty style sheets and JavaScript. To minimize the loading speed of static CSS and JS files, we bonded multiple style sheets and JavaScripts into single file and got rid of the unwanted files which kept eating up the space and time.
Sub-domains for increasing request limits
The next in line was the step towards improving the number of parallel connections. As browsers have certain limits in establishing simultaneous requests, we included sub-domains and split a few CSS, images and JavaScript files in order to parallelize ‘requests’ load.
Render blocking
Another major concern which ate up a long time for the page load was the JavaScript and Style Sheets. These files prevented other contents from loading and hence the overall time for the page to load was prolonged. In order to rectify this we had our JavaScript and CSS files appropriately optimized to help the page load in the minimum time possible.
Leverage cache
For improving the cache of our website we worked on the http requests caching. This method, which holds the copy of the recently visited pages of a user, helps in fetching data at a faster rate by reducing the time for a new connection establishment.
In order to achieve this, we shifted our focus towards clearly defining the HTTP caching headers which are sent by a web server to specify the last modified time. We declared the caching headers using the Expires header which declares a particular date after which the resource will be invalid.
Varnish cache
The constant bombardment of the multiple user requests had a toll on the backend as well. In order to reduce the backend stress we adopted the Varnish cache idea. Varnish cache helps in caching dynamic content that changes occasionally. Varnish cache can be invalidated by the changes made to your pages such as new post, content update and comment. Except these scenarios the Varnish Cache caches the dynamic pages and exhibits them wherever requested. So none of your updates on the dynamic pages goes missing and your website’s backend enjoys a significant reduction in stress as well.
Need our technical expertise to optimize your website.
The major thing which need to be considered while optimizing magento store is combining images with the CSS & JS Files also moving the static content to a CDN speed up magento store better one.
Hi Matt,
Good to see your inputs here. As there are some other techniques available check our other posts too for optimizing your magento store.
Thanks!
Thanks for sharing your valuable information which you have worked on speed optimization for your site. Let’s follow the above techniques but hope it takes time to complete over all optimization mentioned above. Once again great knowledge sharing with your practical guide. Keep sharing
Dear Himanshu,
Hope this post reached in you a good spirit to optimize your store. If you have any clarification while implementing, contact our experts here. We will assist you on this.
Thanks!
Hello Apptha,
I’m very much obliged for the considerable information to optimize magento ecommerce store. Even I have been attempting to streamline the frontend & backend optimization quite a while now. And one more method you can add, REDIS it would be great while optimizing any magento store.
I can utilize this for my magento ecommerce store. Thanks for the Awesome tips.
Hello Kati,
Thanks, you added one more valuable point here, we would consider to add this in our next article after experimenting with this.
Hi Ram,
I agree with the http requests & cache instances which increases loading time because of its unwanted space and time. If we avoid certain things almost we can decrease the loading time and performance wise the site will be better.
Hello Mohit,
As you said, if we avoid the unnecessary space then the site will automatically perform better. Glad this article helped for you.
Thanks!
After going through this post I have got a good understanding about the importance of website loading speed and techniques to improve them. I also feel eCommerce sites which are heavy in data should definitely optimize their speed on a regular basis. Very exhaustive and an informative post.