Poor performance leads to exclusion. When we create heavy sites we limit what users can access our content. Those with more powerful devices and better network will get sites loaded faster. Those with older devices and slower network will need to wait more.
Web Performance is not only about understanding what makes a site fast. It’s about creating awareness amongst both developers and non-developers. Performance is a feature and needs to be prioritized as such.
Componentization has marked a before and after in web development. The main advantages that are usually mentioned is reusability and modularization. Well defined pieces that we can use to build our sites, like bricks of Legos. It turns out this component structure provides a great foundation to improve the performance of our sites.
We are explicit about our dependencies, so we know what code we need to run to run a specific component. Lazy-loading and bundle splitting can have a huge impact on page performance: less code requested, parsed, and executed. And this not only applies to JavaScript, but every type of asset.
I see many sites that could take advantage of this, and I wanted to show how some basic techniques to load content as needed.
I was browsing Tim Kadlec’s website and I noticed he had added page load time metrics in the footer.
Tim Kadlec’s site shows how long the page took to load in the footer.
Stoyan Stefanov also realized and wrote “This page loaded in X seconds”, a blog post describing the code used for this. Stoyan also created a bookmark that shows an alert with the load time of the current page. The data is obtained from window.performance.
I liked the idea and added a similar snippet that shows the page load time in the footer (you should see it if you scroll to the bottom). If your browser supports the Paint Timing API you will see a couple of extra metrics: First Paint and First Contentful Paint.
In a recent post about Chrome 60 Beta, Google announced the support of the Paint Timing API to get metrics on when your page starts rendering and when the user gets content that can be consumed (more info on the definition of the events below). Here I’m going to describe this new API a bit and show you how to use it.
Hace unos días hacía un análisis del rediseño de la web del Senado, justo tras su lanzamiento, desde el punto de vista de rendimiento web y mejores prácticas a la hora de desarrollar sitios web. La nueva web del Senado sufría múltiples problemas poco más que inaceptables para un proyecto tan reciente y con tal presupuesto.
Echa un vistazo al análisis más reciente que he hecho de la web del Senado, donde hablo sobre algunos cambios que han llevado a cabo desde que publicó el nuevo sitio. 
Yesterday I was reading Zakas’ Performance on the Yahoo! Homepage slideshare presentation, and I got very surprised when I saw that Yahoo had realised that two of the wide accepted tips for improving website performance had not work so well for them. 
It’s been several weeks since I wrote a tutorial to implement BigPipe using C# and ASP.Net MVC. And I have just read a PDF from a presentation at Velocity China in which Changhao Jiang, from Facebook, explains some details about Bigpipe, as well as other techniques they use to improve Time to interact (both real and perceived), as well as data savings. These techniques (named Quickling and PageCache) are based on hijax and an intelligent update of specific content of the page instead of the whole page when data changes.