Comments on: Web Site Optimization: FrontEnd and BackEnd

By: nick

nick — Thu, 21 Aug 2008 11:36:00 +0000

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.

By: Baron Schwartz

Baron Schwartz — Fri, 27 Jun 2008 15:39:58 +0000

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

By: Alexander Lyamin

Alexander Lyamin — Fri, 27 Jun 2008 09:38:27 +0000

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.

By: Erik Ljungstrom

Erik Ljungstrom — Fri, 27 Jun 2008 00:20:33 +0000

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?

By: peter

peter — Thu, 26 Jun 2008 21:17:11 +0000

Brian,

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

By: peter

peter — Thu, 26 Jun 2008 21:12:22 +0000

Mark,

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.

By: peter

peter — Thu, 26 Jun 2008 21:06:53 +0000

Sander,

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

By: Brian Moon

Brian Moon — Thu, 26 Jun 2008 20:51:44 +0000

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.

By: Mark

Mark — Thu, 26 Jun 2008 20:38:54 +0000

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.

By: Sander

Sander — Thu, 26 Jun 2008 20:25:28 +0000

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/