Part of my consulting practice is evaluating applications looking for issues in the client architecture and development workflow that impact performance. I like to use the application much like a quality assurance tester would, following some user stories.
The process looks for places where responsiveness and usability poor or can be improved. My goal is to experience the application as much as a normal end user would, thinking how they might think, looking for points of confusion and frustration.
I also evaluate the code, examine network waterfalls, memory profiles, etc. The is much like going to the doctor for a detailed physical. In the end I produce a report of issues and recommended actions. Often the performance fixes are simple to do, low hanging fruit.
Sadly too many web developers don't dig much deeper than the surface, take the time to learn a little about the browser or are exposed to terms I might use. This oversight is often common with many subject matter experts.
After doing my application performance analysis last summer I provided about a 10 page report to the development team and received some interesting feedback. The bundling, minification and external resource references were just part of the report. The lead project's lead developer asked what I meant by moving the resource references to the HEAD and document bottom.
Here is a quote on including the CSS references in the document's HEAD I wrote for Modern.ie:
"CSS Style Sheets should be external files, loaded in the document's HEAD. Referencing CSS files in the document HEAD enables progressive rendering. This is where the browser can confidently apply styles to elements as the browser reads them from the response stream. When styles are placed within the markup or at the document's bottom the browser cannot render content until everything is loaded. Some browsers are forced to repaint and reflow the document, which can cause a flash or at least a janky loading experience.
CSS references should be placed as close to the HEAD's top as possible, typically before the document's TITLE element. This ensure the CSS is loaded before any visible markup is encountered. The browser is able to know the page's style rules and apply them to elements as they are rendered."
The lead developer did not seem to understand how to move the CSS tags referencing external resources to the HEAD and scripts to the end of the BODY tag, even with example code I provided. I am not trying to pick on this developer, but somewhat on myself and my ability to explain concepts. I do want to emphasize how important a little discipline is to software development. Moving the CSS and Script references to the appropriate places in your markup is rather trivial, yet many developers still have not considered the process and how proper markup structure affects page rendering. The impact can be significant. In fact most web performance optimization techniques are low hanging fruit that can be implemented in any web site in less than an hour in most cases.
When I first read Steve Souders High Performance Web Sites book, moving the CSS & Script references was the first thing I did. The exercise took about 30 seconds and had a huge impact on a simple web site I was working on that day.
The home page had roll-over images that took a little extra time to download and like most developers I placed the script in the head. This script loaded the roll over images and blocked the browser from further rendering till all the image requests completed.
Moving the script to the bottom meant the browser was clear to render all the markup then evaluate the script. The home page was usable about 4 seconds faster (this was way back in 2008). My customer was very happy as well.
This made a big impression on me at the time and sold me on the other web performance optimization principles.
Another simple low hanging fruit I use in my presentations is using a small, cacheable favicon file. Every browser requests this file when you request a URL (HTML of course). When the favicon file is not found or is not cacheable by the browser it causes the browser to request the file again every single time a URL is requested. Not having this file in the Instagram site caused them to crash the day they launched.
The cause was several thousand requests per second, all looking for the favicon.ico file forced the server to hit the disk looking for the file, every single request. The disk started thrashing causing the web server to become unresponsive waiting for the disk I/O operation to complete. Adding a small, cacheable favicon takes about 5 minutes assuming you need to resize a logo and save the file as either PNG or ICO format. Then of course you add it to the web site's root folder, etc. The impact can be huge, just ask Instagram.
Too often this file is overlooked or never changed from the IDE’s or CMS’s default placeholder. The icon is overlooked because too many developer’s do not know about the favicon, a defacto web standard for a generation.
These are simple examples, but most performance optimization things are as well. I routinely evaluate public and line of business applications that take 5, 10 seconds to 10 minutes to load and become usable.
Almost all the time I can spot about 10-20 simple things the team can change within a day or less to get their load times under 2 seconds if not less than a second. You can open the browser's development tools (F12) and watch your site load in the networking tab. Hundreds of requests, gaps between requests (remember you can only make 6 requests per domain) mean you need to bundling and minifiy scripts and CSS.
Slow render times, move your scripts to external files and move the bundled reference to the bottom of the markup. Do you see a flash after the page has rendered, them move your CSS reference to the HEAD, in a single bundled and minified file.
Make sure you have a favicon and make it cacheable. An hour today can have a drastic impact on your application's performance and scalability over its lifetime, saving months of wait time. This improves your application's conversion and employee productivity rates.
What about the developer who did not understand how to move CSS and SCRIPT tags? I made the assumption she understood core concepts around web development since she had worked on the application. What did not resonate with me was how ASP.NET WebForms applications are built, by dragging controls on a design surface.
She had probably never looked at the application's markup and may have never seen HTML and knew what tags or elements are. You may wonder how she had her position, but looking back her confusion makes sense. Many of the web developers in this company had no development background.
You may find that odd, but I see this more often than you think in enterprises. Some were fork lift drivers, secretaries, mail room folks, etc, they come from the shadow IT department. They just happened to be an employee that played with the right computer at the right time and were given a simple task to solve a problem and did.
Suddenly they were a developer. We enabled them to easily solve a problem by creating tooling that abstracts the language, separating them from true knowledge of the platform. In the end we create poor applications that may have created a short term solution, but a long term headache.
Not only do they perform slowly, they are impossible to maintain, scale and worse the 'developer' has no real development knowledge.
As an advanced developer I need to be more cognizant of these situations and be willing to bring down the level of instruction to the person's level. This case was extreme. Many developers in this company needed several months of training to bring them up to the skill level needed to help the company. To compensate the company hired thousands of developers to do the work a small team of a few dozen competent developers could have done. As a consultant it is sometime difficult to level with a client and tell them they need to retool and eliminate a team or deeply in extensive training to raise the team's competence.
Poor application performance is not always related to technical, it can also be professional. Poor techniques and habits affect not only the application run-time performance, but maintenance and reliability as well. Take time to train your team, constantly evaluate and find areas of improvement. Invest in them and your applications become invaluable assets, not something your stakeholders dread using.