Web Site Optimization: FrontEnd and BackEnd

I spent Monday and Tuesday this week on Velocity Conference It was
quite interesting event worth attending and it was very good to see
the problems in this are going beyond Apache, PHP, Memcache and MySQL.

A lot of talks on this conference was focusing on what is called
“FrontEnd”. The meaning of Frontend is not the frontend web server
commonly used in many architectures but rather optimization on the
client side – how to make a browser to do less requests, make them
parallel, fetch less data and execute client side code faster.

Steve Souders mentioned in his talk for Alexa 10 web sites he examined
typically 80-90% of page response time comes from other things than
fetching HTML of the main page – fetching CSS, JavaScript, Images
which makes it number one thing to focus your optimization on.

I do not fully agree for number of reasons.

First – a lot of people focus on Backend optimization first, have
monitoring and graphing setup based on the main HTML page response
this means quite frequently we speak about sites which have relatively
well optimized backends but have not spent time on the frontend
optimization. In this case not a big surprise there are more low
hanging fruits on frontend part. We often deal with people with
less than optimized backends with some pages (search,reports etc)
taking minutes to load which makes these few seconds you can shave off
by client side optimization secondary.

Second – The stakes for backend optimization are higher. If you do not
optimize your web site on Frontend you will have worse user experience
– users may not engage so actively, leave your site faster or not
convert. This is very important. However if you do not optimize
backend enough to handle your load your web site can simply get
overloaded and die. Remember all these “slashdotted” or
“techcrunched” sites which went down because their back end just was
not ready.

Third – Even if your backend is reasonably fast say you can have under
100ms response time on main HTML page there are still reasons to optimize
it, especially for large scale systems. If you can come up with idea
to provide same response time just with lower hardware requirements
you can save on hardware, power and operations which are considerable
costs for large projects.

I would say instead the same rule as back end optimization applies
here – if you spend 90% time running PHP code and only 10% fetching
data from MySQL database it does not make sense to focus on MySQL
optimization. If 90% is spent on other tasks than fetching your HTML
page all together you surely should focus on it. But get real numbers
for your application before you decide.

Having said that I will now go and read Steve’s book which he kindly
signed for me to get up to speed with front end optimization.

Share this post

Comments (12)

  • Aleksandr Yampolskiy Reply

    Good advice. In case anyone is interested – I’ve assembled a list of useful online tools, which can be used to analyze bottlenecks in front-end performance of your website: http://bit.ly/k1GJ0h. Any feedback or additions to the list are welcome

    June 26, 2008 at 12:00 am
  • rody Reply

    hello all
    I’m just beginner n web design and have a question need help and willing to pay fees if needed of course .
    my question is :

    i want to build my own website with special features and functions such as allow my web site users to edit pages by adding images , articles on the page , i mean that on my website there will be a template for users so they can use it and filling some data onit so it become their own webpage on my website .
    so what and of technology or programing language that i may need to use .

    June 26, 2008 at 12:00 am
  • Sander Reply

    For my own e-commerce website, I found that optimizing the front-end can be quite rewarding. That it could matter that much was quite an eye-opener to me.

    I found that Yahoo! has a page with good documentation on the subject and they even have a firebug add-on (YSlow) to grade a site on front-end optimization. See: http://developer.yahoo.com/performance/

    June 26, 2008 at 1:25 pm
  • Mark Reply

    Regarding the second point (being slashdotted) one of the Frontend/Backend trade-offs is where you are performing your computations. I.e., your total cost is I/O and processing on the server side, bandwidth for pushing results from the server to the client, and additional processing and rendering on the client. To the extent that processing tasks are feasible on the client (e.g., secrets will not be leaked by sending unprocessed data to the client, server side data/indexes are not required for various processing steps, etc.) and the client can be trusted to have a particular level of processing power and storage (e.g., based on the customer base) you can use the client machines to decrease the load on the server (bandwidth and security permitting, you can even decrease database load by performing cruder queries that are then refined on the client side). In the extreme case of transmitting a compact raw result to the client which then performs the bulk of the calculation, one would expect very good, bandwidth-limited scaling.

    June 26, 2008 at 1:38 pm
  • Brian Moon Reply

    I agree that the backend has to come first. However, it was just nice to see discussion about user experience. We struggle with that at dealnews.com because our front page has always just listed today’s deals. Well, we have over 10 writers now and today’s deals is over 200 items each day. That means we end up with 300KB of HTML and 1MB of images on busy days. That is way, way too much. We have a solid backend, so the initial HTML comes down in less than a second no problem. So, for us, we need to focus on the front end.

    I took as much from those talks as I did any other one.

    June 26, 2008 at 1:51 pm
  • peter Reply


    Oh Absolutely frontend optimization is very important and it can give you significant gains if your backend is in a good shape.

    June 26, 2008 at 2:06 pm
  • peter Reply


    It all looks right in theory, In practice however load which you can put on the client is quite limited. For example you can get text in JSON and do formatting using JavaScript instead of PHP code. But you do not really safe on pulling data from the database which can be most expensive. You can use Ajax to refresh only portions of the page, which need less data, though with good caching architecture the data would be retrieved from caches anyway.

    Typically by having smarter client over smart backend you would be able to save on bandwith and cache lookups but the impact on database load is likely to be limited. If you design things well.

    June 26, 2008 at 2:12 pm
  • peter Reply


    Indeed. I think many sites have front end problems. Many being tested via very fast network on fast computers with caches full so they look like they respond very well, while if you play to add up some network latency or limited connection speed you see what a nightmare it becomes.

    True a lot of people are having fast connections these days but geo-inspired latency is not going away. Plus more people are starting to use cell phones to browse Web, which have increased latency more restricted bandwidth and slower CPUs for JavaScript execution

    June 26, 2008 at 2:17 pm
  • Erik Ljungstrom Reply

    Wish I could have attended Velocity, everyone seems very pleased with it! Bummer!

    One important aspect that us “techies” don’t often think about is the financial one. A well optimised backend can shave off a substantial amount of costs in terms of hardware and hosting – money which can be invested in other things which may improve the user experience.
    That said, the frontend is definitely an important piece of the whole from a performance point of view. But, I reckon I’ll continue to go for the backend first – it’s a bit more fun as well, isn’t it?

    June 26, 2008 at 5:20 pm
  • Alexander Lyamin Reply

    Also traffic visualizers (like wireshark) also help alot to get a clue if its html renderer issue or slow server responces and another point of view on whats up with that slacker.

    You have to realize that TCP stack of highload server should perform notably different from what you’d expect from workstation. Thus some /proc therapy might produce visible ( and i mean it ) improvements.

    June 27, 2008 at 2:38 am
  • Baron Schwartz Reply

    I want to put in a plug for Steve’s book: I found it refreshingly to-the-point and clear, and for people who have not already invested significant effort I think it will give you some “doh, why am I not doing this simple yet valuable thing?” moments right away. I used to work in front-end web myself on an e-commerce site. The day we added Core Metrics JavaScript tracking was a sad, sad day for the user experience. The day I ripped out every table on the site and went pure-CSS was brilliant 🙂

    June 27, 2008 at 8:39 am
  • nick Reply

    You can’t have a truly optimized front-end without starting with the back first. Completely agree, which is why I spend so much more time with the back-end usually, optimization is not only more important, but sometimes, more difficult early on.

    August 21, 2008 at 4:36 am

Leave a Reply