❔ How would you optimize a website that is loading too slowly?
✅ Answer:
I would start by analyzing the 'Critical Rendering Path' using tools like Lighthouse or Chrome DevTools to identify the biggest bottlenecks, whether it's large images, render-blocking JavaScript, or slow server response times.
Next, I would implement immediate 'Quick Wins' on the frontend. This includes compressing and converting images to modern formats like WebP, minifying CSS/JS files, and using "Lazy Loading" so that off-screen images only load when the user scrolls to them. I would also move non-essential scripts to the end of the HTML or use async/defer attributes.
Long term, I would look at architectural improvements. This might involve implementing a Content Delivery Network (CDN) to serve assets closer to the user, setting up efficient browser caching strategies, and potentially moving from a standard Client-Side Rendering (CSR) model to Server-Side Rendering (SSR) or Static Site Generation (SSG) to ensure the first paint happens as fast as possible.
❔What is CORS, and how do you resolve 'CORS Errors' in production?
✅ Answer:
I would explain that CORS (Cross-Origin Resource Sharing) is a browser security feature that prevents a web page from making requests to a different domain than the one that served it. It’s the browser's way of protecting users from malicious scripts.
In the short term, to fix a CORS error, I would configure the backend headers. I’d ensure the server sends the Access-Control-Allow-Origin header specifying the exact domain of the frontend. During development, a proxy can be used, but for production, the server must explicitly whitelist the allowed origins.
Long term, I would ensure the security strategy is robust. Instead of using wildcards (*), which are dangerous, I would implement a dynamic whitelist. I would also ensure that sensitive "pre-flight" requests (OPTIONS) are handled correctly by the server and that any authentication cookies are managed using the SameSite and Secure attributes to maintain a high security posture while allowing cross-origin functionality.
❔When should you choose Server-Side Rendering (SSR) over Static Site Generation (SSG)?
✅ Answer:
I would base the decision on how often the data changes. I’d use SSG (Static Site Generation) for pages where the content is the same for every user and doesn't change frequently like a blog, a documentation site, or a marketing page. SSG is the fastest option because the HTML is built once at build time.
I would choose SSR (Server-Side Rendering) for pages that need to show real-time, user-specific data, such as a personalized dashboard or a search results page. Since the server generates a fresh HTML page for every request, the user always sees the most up-to-date information, which is also great for SEO on dynamic pages.
Long term, I would look into Hybrid approaches like Incremental Static Regeneration (ISR). This allows us to keep the speed of SSG but update specific static pages in the background as data changes, giving us the best of both worlds, performance and freshness, without taxing the server on every single hit.