If you stay current with our product updates, you know the Sprout Social product team is always adding and improving product features. We constantly release improvements, big and small, often more than once daily. Many changes aren’t included in even our more granular release notes. For example, the other week, we released about 70 commits (units of code change) to the web application app.sproutsocial.com. Moreover, about 20 commits were released to our API, the lifeblood of our web application and mobile apps, and many, many more to those mobile apps, and the myriad backend services that comprise all that is Sprout’s technology.
These unannounced changes include some of what you’d expect: bug fixes, visual cleanup, code cleanup (to allow us to build faster). We also release dark features: things Sprout employees can try and provide feedback on before being released to customers. Another category of product changes, and the subject at hand, is web performance improvements.
Our engineering team uses a number of tools to monitor the health and performance of our systems. We’re always watching to spot issues or to measure performance changes. I thought I’d share some of the charts we stare at, which reveal nice improvements since the start of 2015 to our page load times. These charts represent “real” (i.e., RUM) times, which is a best attempt to measure what the user perceives.
First up, here’s our average load time from January 1, 2015, through April 28. Were you able to zoom in prior to April 16, you would see the average was 2.7 seconds. Since then, it has dropped to 1.7 seconds. Visually, that’s represented by the drop-off on the right-hand side. That means when you visit any of our webpages, you are getting the information you need faster.
Those averages are based on load times from around the globe. Some of the our changes have the largest effect outside of the US. For example, here are page load times from Australia. The improvement there has been of about 1.6 seconds.
So What Contributed to These Improvements?
Here’s a technical summary of the most significant:
- Recently, we made Sprout available in Spanish and Brazilian Portuguese. During this project, we made the change to serve language files, which we had prior for English, via the Amazon CloudFront CDN. These also end up in browser caches due to cache-control headers. In a nutshell, the browser cache obviates needing to re-download something, and the best way to do something quickly is to not need to do it at all! That saved about 20KB per page load, and making our page sizes smaller means they download faster.
- We use a number of font files for typography and icons. We deployed the necessary CORS configuration to serve and cache these via CloudFront rather than serving them directly from AWS S3. Put simply, our font files get to users via a global network, giving faster download times.
- Mustache is our templating library. We compile those templates to Javascript, using Twitter’s Hogan library. Previously, these were served with our DOM, making up about 80% of the bytes. These are now fetched independently, again via CloudFront, enabling them to be cached on the edge and, again, in browsers. In simple terms, we made our page sizes smaller, so naturally they download faster.
- Recently, I shared a simple but impactful tweak to our outbound TCP configuration: increasing the initial congestion window to 10. Check out my previous post for a more thorough explanation.
Shameless Hiring Plug
Are you passionate about Web performance? We’re always looking for engineers like you who want to make any layer in the stack faster, from CSS to Javascript to HTTP/TCP to server-side code, caching, databases, linux kernels and hardware. Please apply to one of our jobs, and call out your specific performance interests. Tweet me with questions.
The post We’re Always Working to Make Sprout Quicker appeared first on Sprout Social.
from Sprout Social http://ift.tt/1KBDaUJ
0 التعليقات:
Post a Comment