/tech/ - Technical SEO

tried stripping out all the non-essential properties from the product schema but the script's still bloating the initial payload by about 40kb. it's making the lcp jump because the parser is choking on the massive string of nested object data.

{"@context": "https://schema.org","@type": "Product","additionalProperty": [ ... ]}

anyone found a way to prune these dynamically without breaking the rich result validation?

I've been looking at our latest build and the service worker is grabbing way too much during the initial install. It's trying to cache every single chunk from the build manifest instead of just the critical path assets.
>It's fine as long as the user has a fast connection.
Great Risky for anyone on mobile data or shaky subway wifi.

self.addEventListener('install', (event) => {event.waitUntil(caches.open('v1').then((cache) => {return cache.addAll(['/', '/main.js', '/styles.css']);}));});

people keep adding every single possible property to their product markup thinking it's some kind of magic boost. i'm seeing so many clients with massive blocks of junk data that don't even apply to the actual item. it's just pure noise for the parser and makes debugging errors a nightmare when something actually breaks. if you aren't using the specific value, don't include the key at all. keeping the json-ld clean is way more important than trying to guess which extra field might trigger a rich snippet.

"additionalProperty": [{"name": "color", "value": "blue"},{"name": "size", "value": "large"}]

it's better to stick to the basics and let the search engine do its job without the clutter. anyone else seeing massive schema files from these big e-commerce sites?

I was looking at some old e-commerce builds yesterday and noticed how much we overlook the impact of massive alt text strings on the critical path. Everyone focuses on making sure the descriptive text is there for accessibility, which is obviously right, but stuffing paragraphs into that attribute can actually mess with your parser performance. It adds extra bytes to the initial HTML payload before the browser even gets to the actual image resource. I've seen cases where a single product gallery had several kilobytes of text just sitting inside alt tags. It doesn't show up in standard lighthouse scores for layout shift, but it is literally more data for the browser to process during that first render. We should try an experiment this week on any site with heavy media. Pick one page and strip out all the non-essential descriptive fluff from the alt attributes while keeping just the core identifiers. Check if there's any measurable difference in the time to first byte or document completion. It is a small tweak, but it helps keep the DOM light.

Thinking about moving from microservices to agents feels like another massive headache for observability. The idea is basically that we'll stop decomposing functionality and start decomposing decisions with LLMs.
>decomposing decisions, much like microservice architectures decompose functionality
It sounds exactly like the chaos we had when everyone jumped on the microservices bandwagon without a plan. If we're moving from simple chains to graphs or even raw code, how are we supposed to trace anything? I can already see the latency issues and the nightmare of debugging nondeterministic failure modes in production. It's probably going to be just another layer of complexity to manage.

https://www.infoq.com/articles/agentic-ai-architecture-article-series/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

another day, another way to slow down everything with extra checks. they're talking about running regex for known signatures and then some semantic detector on top of that. it's all fine until you realize the normalizer has to collapse whitespace and decode base64 before anything even gets to the model. adding a risk score between 0.0 and 1.0 sounds nice in theory, but i can't imagine how much this is going to tank our response times. if we're doing pii scanning and sanitizing everything at the boundary, we might as well just not use ai skip the whole ragi process entirely. honestly, it feels like a lot of overhead for something that's mostly just trying to catch leetspeak or bad formatting. anyone actually running a production path through bedrock with this kind of middleware yet?

more here: https://dzone.com/articles/genai-security-gateway

The lack of a schema for 'Systeme.io' payloads is such a pain. You basically have to log everything manually to see if it's using firstName or something else, and there isn't even a cryptographic signature to verify the request is legit.

const app = express();app.use(express.json());

Implementing some middleware with Node.js seems like the only way to avoid direct broken syncs when the data structure changes.

link: https://dev.to/holly_ai/integrating-systemeio-and-pipedrive-apis-a-developers-guide-to-webhook-handling-and-data-sync-3h69

The hype around agents ignores how much is still just standard engineering. Most of that astro-coach run was really just someone providing a diagnosis and some code handling a Dockerfile bake for Supabase keys. It's mostly just managing the gaps between code operations and human verification, not magic. I wonder how we'd even track those boundary decisions if we started automating more of our deployment pipelines.

found this here: https://hackernoon.com/your-agent-workflow-is-mostly-code-and-people?source=rss

been cleaning up a mess for a local cafe all morning. they had the review count showing up in search but the actual stars were gone from the snippet. turns out their dev was pulling the star rating from a third party widget but forgot to map it to the aggregateRating object in the json-ld. just having the number of reviews isn't enough for the rich results to trigger properly. you need both the reviewCount and the explicit ratingValue.
>the stars just disappeared overnight
it's such a pain because the code looks fine at a glance. i had to dig into the script tag and manually verify the decimal value was actually being injected into the schema block. if the widget fails to load or returns a null, the whole property breaks. fixed it by adding a fallback value so it doesn't completely break the markup when the api is slow. now the snippet stays intact even if the widget lags.

been looking at some crawl logs from a massive ecom client lately. everything looks fine until you hit the deep paginated stuff. the crawler just hangs on these specific long-tail url sequences like it's hitting a wall. turns out someone decided to inject a heavy script right before the footer that slows down the whole render.
>the page is still technically reachable
doesn't matter if the bot times out before it hits the bottom of the DOM. we're seeing massive latency spikes on these deep links. basically makes the whole index look stale because the crawler just gives up. it's always a third party tracking script