It can sometimes be difficult to predict what will cause performance regressions when developing an application or web server with test data. So you do your best with what you know at the time of release, and then deal with performance issues when you know what is causing regressions (e.g. saved searches) and can then make measurements and profiling to see what exactly is causing the issue.
Likewise, improving performance pushes the limit at which performance regressions happen allowing more data (documents, triangles/pixels, etc.) to be processed. This allows things like more complex game graphics. That in turn makes it harder to improve performance for the next round (more advanced triangle/face culling and pre-processing).
There can also be trade-offs with things like data layout, memory usage (caching and memoization), or implementation. For example, when processing XML/HTML data you could use DOM (more memory and upfront parsing, but easier to perform complex queries across the data), SAX (less memory, but more complex to process due to tracking state), or reader API (similar to SAX but a different processing model).
There can be challenges with various features, such as type checking with higher-order generic types. Others add various levels of overhead, such as parsing a program, constructing an AST (Abstract Syntax Tree), generating an IR (Intermediate Representation), the optimization passes and final code generation.
JavaScript evaluation for example is complex. Before Chrome the approach was to use a slow interpreter. IIRC, Chrome was the first browser to introduce JIT (Just-in-Time) compilation, leading to faster JavaScript and eventually more complex applications running in that language. Modern browser JavaScript pipelines are complex in order to achieve and maintain performance:
1. start interpreting the code on the AST so it is run immediately (or only rely on (2));
2. generate a machine code equivalent of that interpreted code (for faster baseline performance);
3. run more aggressive optimizations on known types based on profiling/analysis for even faster performance, including special handling of things like asm.js.
[1] https://v8.dev/blog/ignition-interpreter
[2] https://benediktmeurer.de/2016/11/25/v8-behind-the-scenes-no...
[3] https://www.cs.cornell.edu/courses/cs6120/2020fa/blog/tracem...
[4] https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/