The first step in improving speed is establishing who is responsible for the effort. Other than responsibility, it’s invaluable to gather a diverse group who can contribute unique ideas to the brainstorming and evaluation session (more on that below). By including people from different business areas, you’ll allow knowledge to spread throughout the organisation more freely too.

I have worked on many sites and projects over the years, and I have found the single best way to ensure that quality is a core area of focus, is to make that work visible and easily understood. We must do more than just make things faster; we must be able to explain what we did and what impact it had.

A couple of years ago, my first few days on a new web performance project were always slow going. […] In a bid to address this, I introduced a new tool into my arsenal so that I could hit the ground running much faster, and get answers to my clients much sooner.

An explanation of how Matt built the UK government's Synthetic Monitoring dashboards.

Sadly, I think the current state of “modern” web development reverses that principle. Developer efficiency is prized above all else. Like I said, that would be absolutely fine if we’re talking about technologies that only developers are exposed to, but as soon as we’re talking about shipping those technologies over the network to end users, it’s negligent to continue to prioritise the developer experience.

In this post, I’ll discuss what I did at ALDO to measure the revenue impact of web performance without having to spend time making performance improvements.
[…]
Back in October, rendering performance was something we had never focused on. Nobody was really talking about it, so there must be nothing there. It was only after we started measuring that we saw the potential.

Performance improvements are a never-ending journey. The key is to strike the right balance. As noted above, we made significant progress on speed in 2019. But that is not the end of the story. Going forward, we have put a few things in place that will always keep us on the edge when it comes to performance.

• A committee of Speed Champions
• Synthetic monitoring to check budgets before each release
• Adaptive speed budgets
• RUM and interactivity metrics (FID, TTI)

Setting performance budgets doesn’t need to be complex or confusing, you simply need some existing data, some monitoring, and to remember that budgets and targets are two different things. Don’t make life difficult by treating performance budgets as aspirations.

The issue of Web Performance adoption is not related to a lack of tools, but to a lack of incentives.

If you do find yourself in a position where your site’s initial rendering depends on a third-party script, refer to your mitigation plan to see what you can do to eliminate or ameliorate your dependence on it. Depending on a third party for core functionality is never a good position to be in, as you’re relinquishing a lot of control to others who might not have your best interests in mind.

The tools to make our websites fast and accessible are here but we’re not using them. And that’s what makes me mad […] it’s not just bad software design and development if a website is slow. Performance and accessibility aren’t features that can linger at the bottom of a Jira board to be considered later when it’s convenient.

Other notes :

• https://www.lukew.com/ff/entry.asp?1988
• https://hookedoncode.com/2018/04/beyond-engagement-the-content-performance-quotient-jeffrey-zeldman/

Look, AMP, you’re either a tool for the open web, or you’re a tool for Google search. I don’t mind if you’re the latter, but please stop pretending you’re something else.

"Third-party scripts are probably the #1 cause of poor performance and bad UX on the web. It's no wonder things like AMP exist. The fact that it disallows third-party scripts is probably the largest contributor to it making sites fast. Controversial as hell, though, in its other choices."

"Publishers should not be compelled by Google’s search dominance to put their content under a Google umbrella. The Web is not Google, and should not be just Google."

TL;DR: We are making changes to how AMP works in platforms such as Google Search that will enable linked pages to appear under publishers’ URLs instead of the google.com/amp URL space while maintaining the performance and privacy benefits of AMP Cache serving.

"We need to get people excited again about owning their data. For our sake and theirs."

Medium is only an edge server of your POSSE CDN, your own blog is the origin

"Google has all the ability in the world to reward and punish sites based on their performance without fracturing the web in the process."