Front End – Planning and Building “a performance driven and SEO friendly website” – Part III

This is the last post in the series of planning and building a performance driven and SEO friendly website. Despite this series focused on website development, this series can be referred and practiced for an understanding of main aspects of any front end and back end development. In this post, we will look at the following topics:

“Limiting the number of database records from the backend”, “Significance of headers”, “Using Content Delivery Network”, “Caching”, “Compression”. Fetch only the required attributes/fields/columns and always limit the number of database records from the backend During my college days, most of us (I and my friends) realized the importance of limit operator at the backend. This was required to fetch only the limited number of rows and to avoid burden on the whole system including database server and front end application etc.. We also learnt to avoid using fetching all the columns from a table or number of tables in case a join operation is being performed. Over last couple of years of my experience of interacting with various teams, I’ve seen some developers still following this bad practice of not using limit and fetching all the columns.

Please note that by following only this basic however really important technique, one can achieve wonderful results. The second most significant technique related to database is to apply indexes on the fields being referred in where clause of your RDBMS/NoSQL DB queries.

Significance of headers

The headers sent while making a request can also play a significant role. Some of the key headers a front end developer should include are like “Cache-Control”, “If-Modified-Since” and “Accept-Encoding”. The back end developer should return the corresponding headers for headers sent from front end. “Cache-Control” and “Last-Modified” can be used. These two headers can help in handling caching at the code level. There have been other caching mechanism which can be deployed at different layers based on the need. I’ll briefly touch upon those later in this article.

Using Content Delivery Network

The Content Delivery Network (also referred as CDN) is a great way to serve a website to globally spread users from the nearest possible edge location form the user. For example, If a user sitting in India tries to browse a service or website, it would be better if the same request can be catered from a facility/server located in India. This would reduce network latency.

Caching & Compression

Caching is a great way to reduce latency and load at the server side (both at the database server and application web server). Having implementing a caching layer before the server, the requested data will be checked with the cache system. If data is present in the cache, it would be returned from the cache rather than hitting the web server. This will result in quick response to user. The caching can be implemented in many ways. One of the way is to use request cache headers while sending an API request from the front end and sending appropriate response headers telling the caching layer about the duration of the content to be maintained in the cache. Another way is to have some popular tools like redis or memcache deployed as an intermediate layer between client and servers. Another possible and easy way to have caching implemented is to enable caching at the API Gateway layer ( in case APIs are being served from some API Gateway).

Compression is another technique. I haven’t seen developers using this technique so frequently or as a standard development practice. I would strongly recommend to use compression of the response data sent to the client. This can be achieved by implementing appropriate request and response headers to take care of compression. The request header will let the server know that what kind of compression it can accept. The client also has to implement the code in case the client required compression is not supported by the back end code. In the same way, server can also send response header back to the client to let the client know about the compression technique it has used. Another way to enable compression is to enable it at the API Gateway layer.

Conclusion

All the strategies mentioned above can help achieve a performing front end and back end.In the end, I seek your feedback about this article. Upcoming topics include – Serverless framework and AWS services.

Neeraj Garg

Solution Architect with more than 14 years of experience in the IT industry. Expertise in architecting end-to-end solutions which are web based as well as big data based. Passionate about helping customers solve their business problems and thereby grow their business.

Leave a comment

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

Share Post
Share on twitter
Share on linkedin
Share on facebook