We feel very excited to see that there is a growing awareness about site speed measurement and improvement across tech community. While it is an established practice in USA, other regions are quickly catching up the term. However, there are still some excuses you hear for not doing site speed optimization. Let’s talk about five most common excuses you hear from the developers and the product teams.
Site Speed is not a priority for us.
We have often faced this issue that people tend to consider Site Speed not as a priority. Over the years, the awareness has definitely improved, but there are still some folks who are not aware of the Site Speed concept.
It is a proven fact that the site speed degradation negatively impacts the user engagement, the revenue and the online experience. This also causes negative reputation. Often, people are not able to relate the business metrics to site speed. This happens when they have no real user site speed measurement setup or they do not have accurate user engagement measurement system setup. While Google Analytics helps cover this gap, but because the way it samples and measures speed, many times these metrics can not be correlated. You need to measure the Core Web Vitals now as part of the Site Speed Measurement. However, when these tools are accurately integrated, a correlation between Site Speed and User Engagement/ Experience can be seen.
The speed appears good on my machine or in the lab.
This is a very common situation. Lot of companies measure site speed from publicly available tools like Pingdom using handful of samples or measure it in a lab testing environment. While personally we am not against these products, but statistically handful of samples from same location for same page can not stand as the source of truth for site speed. The network conditions are perfect in a lab environment. Naturally, the speed appears good at this stage.
If you want to benchmark Site Speed, more number of samples and randomness on measurement system will always help. I always believe that minimum 2000 samples, per url per location per bandwidth is a good number to baseline site speed. The margin of error in such cases is mostly less than 5%. However, the best way to baseline site speed, is to benchmark using real user measurement (RUM). These systems measure speed for real conditions of users and hence are the most accurate.
We do not have time and resources to fix the performance issues
Most engineering teams will face this dilemma about not having enough time and resources to put on site speed speed optimization. This is where the features and changes will take the priority. The performance problem will never be fixed.
We always wonder what type of company is that, which builds awesome products, but allows the users to bounce off, engagement to drop off and the revenue to go down. Thus on one side, they open water tap to fill the bucket, but allow the bucket to have a big hole
Site Speed should always be the best practices of the engineering teams. the moment some one learns to code, he/she should also learn about writing efficient code. Thus, the Site Speed should not be an afterthought, but it should be part of the daily work of the developers, the QA and all related people. There are bunch of site speed best practices available like Google Pagespeed which needs to be followed while doing development.
We will look into the Site Speed once the product is launched
This is another common excuse we have heard from time to time. Only in a handful number of cases, the site speed issues will be fixed after launch. There are two problems to this approach. It is very costly to fix any issues in the production environment than in the developer environment. Thus you are associating a greater cost to the Site Speed fixes. Another problem is of the online reputation. When the product is launched, most users will come to the product out of curiosity or through some marketing efforts. Remember this, first impression is always a last impression. A proven study states that 57% of the online users will abandon the site if it takes more than 3 seconds to load. 80% of these users will not return. Almost half of it will go on telling others about their negative experience. Thus you lose the advantage of launching first in the market.
Do not treat Site Speed as afterthought. It needs to be given careful consideration right at the time of design and the development.
No matter what we fix, we do not see Speed Improvement
This is a real problem in the performance community. The engineers will try to fix the problems but do not see the impact on the metrics. This happens when developers try to fix something which will not have sizable impact on the Site Speed.
Fixing a back-end issue is most likely to resolve the scalability problem than the Site Speed Issue. Similarly fixing anything post onload or below the fold, is going to have negligible impact on the Site Speed. Once the developers go through such cases, they lose the motivation to fix performance issues further.
The way to fix this problem, is to prioritize performance fixes based on the impact of the task.
Conclusion
No matter what excuses you hear, they are real. They need to be handled carefully and the Site Speed Improvement needs to happen continuously. That will definitely help you improve the user engagement, retain users, increase revenue.
Top Image Courtesy:- https://www.move-it-marketing.co.uk/technical-seo/need-speed-improve-user-experience-on-wordpress.