SEO & Search
Performance & Infrastructure

Two Deadlines Land at Once: The Speed Update and 'Not Secure' Everywhere

July delivered a synchronized graduation ceremony for two of our longest-running arguments.

On July 9, the Speed Update went live. Page speed is now a ranking factor for mobile searches, announced in January with six months’ notice, scoped honestly by Google as affecting the slowest experiences rather than micro-ranking the adequate ones.

On July 24, Chrome 68 shipped, and the ‘Not Secure’ label completed the expansion announced in 2016. Every HTTP page, not just the password-collecting ones, now carries the words beside its address, for the majority of the web’s visitors.

Two separate teams at one company. Two separate mechanisms, the ranking system and the address bar. One identical shape. A best practice we argued for years moved through incentive and label and deadline to arrive, this month, at plain enforcement. Performance since the 2010 speed-signal piece. Encryption since the 2014 ranking announcement. Every stage announced in advance.

The sites that believed the announcements spent July reading about deadlines. The sites that did not are meeting two at once, which is its own argument for the approach this post will end on. In between, the practical layer. The measurement stack for the speed side has matured into something genuinely useful, and it deserves the walkthrough.

The speed side, and the measurement stack that matured

The Speed Update’s mechanics reward precision. Google describes it as demoting the slowest mobile experiences, not as a speed derby among acceptable ones. The sites in genuine exposure are the ones that have deferred performance work for years, and the diagnostic question is simply: are we in the slow tail, and where?

The tooling for answering has consolidated into a stack we now use across many engagements, and its shape matters more than its brand names.

Field data first. The Chrome User Experience Report, CrUX, aggregates real-visitor loading metrics from actual Chrome sessions on your actual pages. That makes it the ground truth for ‘what do users experience,’ network conditions, devices, and all. PageSpeed Insights now surfaces it per URL where volume permits.

Lab data second. Lighthouse, in Chrome’s dev tools and automatable in CI, per the performance budget’s enforcement layer, reproduces loads under controlled throttling and explains why the field numbers are what they are. The render-blocking scripts. The unoptimized images. The third-party tags our governance thread keeps auditing.

The order is the method. Field tells you whether and where you have a problem. Lab tells you what it is. The classic error is optimizing lab scores for pages whose field data was already fine.

Prioritize by template traffic, the highest-traffic templates’ worst field metrics. Fix at the template layer, where the site-scale returns live. Re-measure in the field, where the truth lives. Sites carrying our performance budgets have this loop running already. Sites without it just received, from the ranking system itself, the budget’s business case.

The label side, closure in five hundred words

The encryption half needs less space because the road is fully paved. The 2014 piece made the case. The 2017 label-era piece sequenced the migration. The sites we touch crossed years ago.

What July changes is the default reading of the remaining holdouts, and it deserves stating plainly for whoever still needs the memo upstairs. As of Chrome 68, an HTTP site is labeled ‘Not Secure’ on every page, to most visitors, all the time. The label no longer distinguishes the form page from the brochure page. It marks the site, and with it the institution’s competence, fairly or not, at every moment of every visit.

The remaining migration excuses were audited in the 2017 piece and found aged out. Certificates free and automated. Performance arguments upended by HTTP/2. Mixed-content cleanup a scoped project. Nothing has revived them, and the checklist there stands unamended.

One addition earned by the intervening year. HSTS adoption and the browser preload list have matured, and sites finishing migrations should finish properly. Redirect, harden, preload, per the close-the-downgrade-window advice.

The holdout tier at this point is not making a technical argument. It is deferring a Tuesday-sized project while wearing a warning label during every admissions season, giving campaign, and appointment booking it hosts. July’s version of this paragraph is the last one we intend to write. The label has said the rest.

The July checklist, consolidated

  • Pull field data for your top mobile templates, PageSpeed Insights or CrUX directly. Sort by traffic-weighted worst metrics, and determine honestly whether any template sits in the slow tail the update targets.

  • Run the lab diagnosis on the flagged templates, Lighthouse under mobile throttling. Fix in the classic order: images, render-blocking resources, third-party tags, script weight per the December cost analysis. Verify the fix in next month’s field data.

  • Confirm the site is fully HTTPS, including the microsites and subdomains the census keeps finding, with the mixed-content sweep and HSTS finish. The label now marks every page you missed.

  • Annotate both dates in analytics, so the quarter’s traffic narrative credits what it should and resists what it should not. Two same-month enforcement events is exactly the condition annotations exist for.

The pattern layer, which is the actual story

The close belongs to the eight-year shape, because our job is making it unmissable.

Performance and security each ran the same full course in public. Best practice argued by practitioners, 2010, 2014. Then measurable incentive: the speed signal, the HTTPS boost. Then visible label: the mobile-friendly badge, the address-bar warnings. Then dated enforcement: April 2015, this July. Every transition announced. Every deadline kept.

That is now the documented, repeatable physics of how the web’s baseline rises. It supports the approach we have recommended for years. Treat platform announcements as project calendars, and enforcement days become reading days.

The approach requires no special talent, no insider knowledge, and no budget beyond the work you already owed your users. It requires only the institutional discipline to act on notice, which July has now demonstrated, twice in sixteen days, is the entire difference between the sites reading about deadlines and the sites meeting them.

The next case is already visible in outline. The privacy enforcement we track on two fronts. The credibility signals the quality guidance keeps emphasizing. The announcements are already publishing. Believe the announcements. The graduation ceremonies are scheduled years in advance, and the reading seats are free.