http://www.linuxjournal.com/content/client-side-performance
In past articles, I've covered different ways to understand, analyze and improve the performance of your web applications. I've shown that between your network connections, server hardware, database design and HTTP server configuration, you can change and improve the performance of your web application—well, sort of. Web applications, when they first started, were dynamic only on the server side. Sure, they output HTML—and later, CSS and JavaScript—but the overwhelming majority of the processing and computation took place on the server.
This model, of course, has changed dramatically in the last decade, to such a degree that you now accurately can claim to be a web developer and work almost exclusively in HTML, CSS and JavaScript, with little or no server-side component. Entire MVC frameworks, such as Ember.js, Angular.js and React.js, assume that you'll be writing your application in JavaScript and provide you with the objects and infrastructure necessary for doing so.
If you're worried about the performance of your web application, you need to concern yourself not only with what happens on the server, but also with what happens in the browser. Some commercial performance-monitoring solutions already take this into account, allowing you to see how long it takes for elements to render, and then to execute, on your users' browsers. However, there is also no shortage of open-source tools available for you to check and improve the ways in which your client-side programs are executing.
This month, I'm concluding this exploration of web application performance with a survey of things to keep in mind, as well as tools that help ensure that you're actually doing what you should be.
In past articles, I've covered different ways to understand, analyze and improve the performance of your web applications. I've shown that between your network connections, server hardware, database design and HTTP server configuration, you can change and improve the performance of your web application—well, sort of. Web applications, when they first started, were dynamic only on the server side. Sure, they output HTML—and later, CSS and JavaScript—but the overwhelming majority of the processing and computation took place on the server.
This model, of course, has changed dramatically in the last decade, to such a degree that you now accurately can claim to be a web developer and work almost exclusively in HTML, CSS and JavaScript, with little or no server-side component. Entire MVC frameworks, such as Ember.js, Angular.js and React.js, assume that you'll be writing your application in JavaScript and provide you with the objects and infrastructure necessary for doing so.
If you're worried about the performance of your web application, you need to concern yourself not only with what happens on the server, but also with what happens in the browser. Some commercial performance-monitoring solutions already take this into account, allowing you to see how long it takes for elements to render, and then to execute, on your users' browsers. However, there is also no shortage of open-source tools available for you to check and improve the ways in which your client-side programs are executing.
This month, I'm concluding this exploration of web application performance with a survey of things to keep in mind, as well as tools that help ensure that you're actually doing what you should be.
No comments:
Post a Comment