As far as I am concerned, front-end optimization is a vast, deadly desert filled with swarming PHP Krakens by day and crawling Angular Hecatonchires(ies ?) by night (or is it the other way around?), all trying to Bootstrap your programmers into submission with their Nodes of death, if you are lucky.
So naturally I wasn’t too happy when a-dear-friend-from-back-in-the-day emailed me for help with his sluggish JS system. But hay , what are friends for?
Doing my regular shtick yielded an unenthusiastic response from his employees. “The back-end is OK” they cried, and they were right. The fully grown product had the (not too big) servers at under 3% load. So why were we waiting so long for the service to load? I had a hard time telling.
- Some difficult calculation is being done by the weakling client machine when it can be done on the under-worked server.
- Some data is downloaded too soon, or too late, or when it’s not needed at all
A more concise way of defining those same problems as I defined them would be:
A true spark of genius!
Our less than surprising results had one upside. we could now focus our efforts on the client-side, namely browser profiling, and what tool is more handy to do so than Chrome Developer Tools (OK, Firefox is also awesome at that, but that’s an easy thing to be awesome at).
Using a coin (or other means of random action resolution) we decided to start with network. Luckily, your typical in browser developer tool will have some type of network profiler built-in.
This is what we got:
Unless you are legally blind you can’t really miss the two long-as-hell loading bars in there – taking a huge chunk (at least 30% of what i can tell) of your load time, and that’s without accounting for all the dependent processes we can load earlier. So you have your delinquents. Inspecting what are those resources (by the very complicated action of clicking on them) exposed the following interesting facts:
- they were not business critical, not in-house developed, and not data
- the first is an analytics tool they don’t use any more
- the second is a communication tool intended for use by a small percentage of the user population. And never by new users, how are of course are most sensitive to long loading times.
- neither of the resources was on a CDN.
Looking closer yielded other insights, but they were all implementation specific, so with your permission I’ll just sum them as “other dependency order mistakes“.
This is where this story ends, my dear friend’s workers left the room amazed by the magical abilities I posses, and went on to do my bidding – removing the unneeded , delaying the unnecessary, and using the services you pay for.