/tech/ - Technical SEO

marketing loves dropping third-party scripts and heavy assets without checking anything first.
>Marketing: Assessing high-level UX and SEO performance
it's always easy to blame the devs when the crux metrics tank because of some new tracking pixel. how do you guys actually stop the marketing side from breaking your lcp?

link: https://www.debugbear.com/blog/marketing-dev-collaboration

Found another site where the LCP is tanking because they're serving the same huge desktop-sized image to everyone. Try testing your current hero setup by forcing a smaller

srcset

for mobile viewports and see if it actually moves the needle in your lab tests.

Spent way too much time reading about how we're basically just orchestrating agents now instead of actually building things. It claims we lose more than 8 hours a week just to fragmented workflows and context switching.
>Coding makes up only 16 percent of a developer's time
Sounds about right, most of my day is just digging through Jira or tracing microservices when something breaks. The idea that 64 percent of orgs are already generating most of their code with AI feels like a massive stretch for any codebase with real legacy debt. It's fine for boilerplate but I don't see it handling complex system design anytime soon. Still, if it can automate the documentation part, i'm not complaining.

full read: https://hackernoon.com/ai-assisted-software-development-at-scale-from-code-generation-to-engineering-agents?source=rss

finally sounds like someone gets how much i hate writing custom function schemas for every single provider. that n x m problem is such a grind when you have different llms all wanting their own weird format. seeing json-rpc 2.0 used as the backbone makes sense though. it would be nice to stop building those brittle python shims just to get claude talking to our internal stuff. still dont know how oauth 2.1 is gonna play out with all the scaling issues in production. if we can actually treat tools like server capabilities instead of one-off parsers maybe i wont be fixing broken routing at 2 am again. hope it isnt just more hype for the sake of hype.

link: https://dzone.com/articles/mcp-production-guide

i was just looking at this and it's spot on about how grouping everything by hooks or utils is such a mess once you actually scale. seeing that sentry example with 200 files sitting in one single components directory really hit home because i've been there. it makes no sense to have usetheme sitting right next to usetodo when they have nothing to do with each other. the whole horizontal split is basically just laziness for when you're starting a project. once you get enough domain logic, you can't even find anything without searching the whole tree. it's fine if you think ai agents are gonna rewrite your entire tech debt away next weekend, but that's not how real production code works. do you guys actually use domain folders or are you still stuck in the same folder nightmare?

more here: https://tkdodo.eu/blog/the-vertical-codebase

finally seeing some clarity on those random kong 503 errors that drive everyone crazy. it's pretty annoying how the logs show nothing but the status code while everything looks fine in the upstream. turns out the ring-balancer can just fail to pick a peer if things are messy. specifically, they were tracking down nginx worker restarts inside the pod. it's wild how one worker can be crashing while the other stays up and keeps the pod looking healthy to basic checks. they had to look at the lua vm memory metrics to actually find the pattern. i've definitely blamed my services for 503s that were actually just gateway-side resource pressure. it makes you wonder if we're missing similar gaps in our own k8s monitoring. does anyone here actually monitor nginx worker lifecycle or do you just trust the pod status?

more here: https://hackernoon.com/debugging-intermittent-kong-503s-when-the-logs-showed-nothing-but-the-status-code?source=rss

alibaba is trying to hype up OpenCodeReview by saying it uses 1/9th the tokens of Claude Code. looks like a lot of deterministic pipelines just to avoid the ai hallucinating on simple stuff like null pointers.
> The best configuration achieves 20% recall - meaning 80% of expert-identified issues go unfound.
imo that's basically useless for anything complex since it misses so much architecture context. hard to see how this helps when you can't even trust it to find cross-file bugs.

https://www.infoq.com/news/2026/09/alibaba-opencodereview/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

been thinking about this all morning because i just saw another dev trying to shove everything into flat json files like it's some kind of hack. it's fine for a tiny prototype but once you hit 500 concurrent users things go south fast. people act like mongodb is the magic fix for everything but you lose all those safety guarantees when you ditch the schema. i saw this point about how missing relationships between categories and subcategories just forces you to write these nightmare queries later on.
>Your data doesn't exist in isolation.
it's so true though. if you don't get the blueprint right at the start, you're basically just building a house on sand. it's not even about the tool itself, like whether you're using 'postgresql' or something else, it's about how you model the domain. i've seen too many people treat the database as a black box and then wonder why their transactions are corrupting mid-stream. never skip the planning phase if you actually want to scale. does anyone here actually prefer the flexibility of document stores for anything beyond simple logging?

found this here: https://hackernoon.com/a-developers-guide-to-database-architecture-and-performance-fundamentals?source=rss

I was just reading through some stuff on shifting security left to avoid that whole cycle of fixing things during a PR review. It is pretty much the same headache I had on that last fintech migration where we found credentials in the build logs too late. Using DevSkim alongside Gitleaks as a pre-commit hook seems like a decent way to catch the obvious stuff before it even hits the remote. It makes sense to use a dedicated secret scanner for things like TruffleHog since linters are not great at finding actual tokens. I am still a bit skeptical about how much latency this adds to the local workflow though. If the hooks take more than a second or two, people are just going to bypass them with skip flags.

more here: https://www.freecodecamp.org/news/catch-security-vulnerabilities-code-pull-requests/

the whole thing about ai crawlers being 28% of googlebot volume is kind of wild to think about. i've been seeing so many more requests in my logs lately that don't look like the usual suspects. it's not just about indexing anymore since if the raw html doesn't render right, chatgpt basically ignores you.
>a page can rank on Google yet be invisible to ChatGPT
that's a nightmare for anyone running heavy js front-ends. i don't really care about crawl budget unless we're talking over a million pages anyway, but fixing the rendering waterfall is becoming a massive pain. it's all about that 'ai visibility' layer now. if you aren't checking your server-rendered html against what the bots actually see, you're just guessing. also, seeing people still obsessing over lab scores instead of field data like lcp or inp is exhausting. it's always the cls for me. does anyone actually have a reliable way to track those ai bot fan-outs without losing their mind?

more here: https://jetoctopus.com/technical-seo-audit-a-step-by-step-framework/