EmberJS Cut Our Load Times By 60%
EmberJS Cut Our Load Times By 60%
We liked Laravel for its speed of development and ease of testing, so we kept it around. However, we had to do a lot of thinking about whether to use Angular or Ember.
Join the DZone community and get the full member experience.Join For Free
Let’s go back in time to a year ago.
We had just upgraded our app to PHP 7 and we were feeling pretty confident that we had the fastest-loading online accounting software app out there. Turns out we were right — but one calendar year can be a whole lot more in software development years, so we needed to know if we were still on top.
All of our competitors had a lot faster software, so we weren't anymore.
At least, not until we made some changes first. First, Laravel isn't super fast at serving up pages, and we wanted to move away from the monolithic approach and break the app into different services that could talk to any of the integrations that we might add in the future.
We still really liked Laravel for its speed of development and ease of testing, so we kept it around for a fully featured API service (previous to the refactor, we have an API service but it was built separately to just service the iPhone app).
In some ways, it was a headache because often required changes would break functionality in the iPhone app without realizing it because we didn't have a great way to automate the iPhone QA process. We relied on customer support to relay some of that information which isn't ideal but we just kept pressing forward.
Angular vs. Ember
We spent a lot of time evaluating what JS framework we were going to run with. It came down to EmberJS and Angular. We heard a lot of bashing on both sides. Some of our developers were already familiar with EmberJS but we wanted to go with the best tool for the job.
Talking to some Angular developers that had worked on EmberJS in the past (i.e., Linkedin) they warned us that we might not get the kind of performance that we were looking for. However, after digging into the stack, we couldn't find examples of where front-end performance was going to be a limiting factor.
In the end, it really seemed like a wash; and when in doubt, go with what you know, right?
The important thing to know is it’s fast — really fast.
Consistency Is the Key to Good Science
We kept good documentation of the last speed comparison that we did before and after the PHP 7 upgrade because we wanted to make sure we’re comparing apples to apples when it came to the load time improvements. We used the network performance tab in the same browser, Chrome, but this time we used the latest version, 56 (Version 56.0.2924.87 (64-bit)) instead of 48 like we did last year.
We will be comparing not only which invoice page loads fastest this year, but also how those speeds compare to our measurements from last year.
So, after the refactor, we still hold the title of the fastest accounting software around. Not only did we beat out the competing apps for this year but we also trounced our old first-place record by increasing our speed by 60%.
Our invoice page load speed clocked in at 760 milliseconds. It's safe to say there was a whole lot of high-fiving on the engineering team.
We're still hunting down other performance gains to be had. If you have any ideas of things we should look at (non-obvious, please), share your tips in the comments below. Thanks!
Published at DZone with permission of Brad Hanks . See the original article here.
Opinions expressed by DZone contributors are their own.