[{"data":1,"prerenderedAt":139},["ShallowReactive",2],{"system-performance-as-a-frontend-discipline":3,"MarkdownBody_l8YYZUGwQk1r9uuecNkN3AlKAtGhghLVFx0pxYk":134},{"id":4,"title":5,"slug":4,"company":6,"role":7,"period":8,"description":9,"isNda":10,"tags":11,"metrics":17,"highlights":21,"body":25,"bodyMarkdown":128,"order":129,"seo":130},"performance-as-a-frontend-discipline","Performance as a Frontend Discipline","Cross-project practice","Frontend Engineer \u002F Lead","2021 - Present","Performance work treated as a core frontend responsibility, not a final optimization pass.",false,[12,13,14,15,16],"performance","frontend","ux","architecture","product",[18,19,20],"Performance thinking integrated into implementation decisions","Faster interfaces and cleaner runtime behavior","Better user experience through practical frontend discipline",[22,23,24],"Treated performance as part of architecture, not cleanup","Focused on responsiveness and perceived speed, not only synthetic scores","Applied performance judgment across different products and stacks",[26,37,46,54,64,72,80,88,96,104,112,120],{"_key":27,"_type":28,"style":29,"markDefs":30,"children":31},"k0","block","h2",[],[32],{"_key":33,"_type":34,"text":35,"marks":36},"k1","span","Position",[],{"_key":38,"_type":28,"style":39,"markDefs":40,"children":41},"k2","normal",[],[42],{"_key":43,"_type":34,"text":44,"marks":45},"k3","Performance is one of the areas where frontend maturity becomes visible. It is rarely solved by one heroic optimization. More often, it is the result of many small technical choices made consistently over time.",[],{"_key":47,"_type":28,"style":29,"markDefs":48,"children":49},"k4",[],[50],{"_key":51,"_type":34,"text":52,"marks":53},"k5","Approach",[],{"_key":55,"_type":28,"style":39,"listItem":56,"level":57,"markDefs":58,"children":59},"k6","bullet",1,[],[60],{"_key":61,"_type":34,"text":62,"marks":63},"k7","Make performance part of architecture discussions early",[],{"_key":65,"_type":28,"style":39,"listItem":56,"level":57,"markDefs":66,"children":67},"k8",[],[68],{"_key":69,"_type":34,"text":70,"marks":71},"k9","Avoid shipping unnecessary complexity into the browser",[],{"_key":73,"_type":28,"style":39,"listItem":56,"level":57,"markDefs":74,"children":75},"k10",[],[76],{"_key":77,"_type":34,"text":78,"marks":79},"k11","Pay attention to responsiveness, rendering cost, and user perception",[],{"_key":81,"_type":28,"style":39,"listItem":56,"level":57,"markDefs":82,"children":83},"k12",[],[84],{"_key":85,"_type":34,"text":86,"marks":87},"k13","Prefer practical wins over benchmark theater",[],{"_key":89,"_type":28,"style":29,"markDefs":90,"children":91},"k14",[],[92],{"_key":93,"_type":34,"text":94,"marks":95},"k15","What This Usually Means",[],{"_key":97,"_type":28,"style":39,"markDefs":98,"children":99},"k16",[],[100],{"_key":101,"_type":34,"text":102,"marks":103},"k17","The work can involve many things: reducing waste in the rendering path, preventing avoidable slowdowns, simplifying heavy interfaces, and making better tradeoffs before problems harden into architecture.",[],{"_key":105,"_type":28,"style":39,"markDefs":106,"children":107},"k18",[],[108],{"_key":109,"_type":34,"text":110,"marks":111},"k19","I treat performance less as a specialty silo and more as a professional standard. Fast interfaces are not just a technical achievement. They change how reliable a product feels.",[],{"_key":113,"_type":28,"style":29,"markDefs":114,"children":115},"k20",[],[116],{"_key":117,"_type":34,"text":118,"marks":119},"k21","Why This Is Separate",[],{"_key":121,"_type":28,"style":39,"markDefs":122,"children":123},"k22",[],[124],{"_key":125,"_type":34,"text":126,"marks":127},"k23","This is presented as a standalone case because it cuts across roles and companies. It is a repeatable way of thinking, not a single isolated project.",[],"\n## Position\n\nPerformance is one of the areas where frontend maturity becomes visible. It is rarely solved by one heroic optimization. More often, it is the result of many small technical choices made consistently over time.\n\n## Approach\n\n- Make performance part of architecture discussions early\n- Avoid shipping unnecessary complexity into the browser\n- Pay attention to responsiveness, rendering cost, and user perception\n- Prefer practical wins over benchmark theater\n\n## What This Usually Means\n\nThe work can involve many things: reducing waste in the rendering path, preventing avoidable slowdowns, simplifying heavy interfaces, and making better tradeoffs before problems harden into architecture.\n\nI treat performance less as a specialty silo and more as a professional standard. Fast interfaces are not just a technical achievement. They change how reliable a product feels.\n\n## Why This Is Separate\n\nThis is presented as a standalone case because it cuts across roles and companies. It is a repeatable way of thinking, not a single isolated project.\n",3,{"title":131,"description":132,"ogImage":133,"noIndex":10},"Performance as a Frontend Discipline — ilsrbn","A cross-project view of frontend performance as a discipline, not a post-release optimization phase.",null,["Island",135],{"key":136,"result":137},"MarkdownBody_l8YYZUGwQk1r9uuecNkN3AlKAtGhghLVFx0pxYk",{"head":138},{},1775381663384]