Making a coaching website fast by construction, and measuring it honestly.

The common failure is someone uploading a 4 MB phone photo of a classroom into a slot that shows it at 400 pixels wide. So the admin never stores the original. On upload, the site scales the photo down if it is very large, then makes three copies at 300, 800 and 1200 pixels wide, each saved as WebP at quality 85, 80 and 70, and, when the server's PHP can do it, also as AVIF at 70, 65 and 60. Smaller copies get lower quality because the eye can't tell.

On the page, one helper writes a picture tag: AVIF sources first, then WebP, then a plain WebP img, each with the three widths and a sizes hint. A phone downloads the 300 or 800 pixel file in the newest format it understands. The first image on a page is marked high-priority and eager, everything else is lazy-loaded, and every image carries a width and height so nothing jumps. In the live test, each home-page course photo came to between 26 and 53 KB.

The .htaccess file switches on compression, and asks the browser to keep images, styles, scripts and fonts for a year, while sending pages with no-store so a changed fee appears immediately. It also adds security headers and hides folder listings.

There's a trade-off here that is easy to miss. The stylesheets keep the same file names, so a visitor who already has sections.css keeps the old one for up to a year, even after I change it. The usual fix is to add a version to the file name when it changes. I haven't done that, so a design change today would not reach returning visitors until I do.

The site has a complete Razorpay flow. The student never sends a price: the server looks up the course fee in its own database, turns it into paise, creates a Razorpay order and saves an enrollment row marked "created" along with the visitor's IP address and browser. After the student pays in Razorpay's own window, the server verifies Razorpay's signature before it marks the row "paid", and refuses to process one that's already paid. A bad signature marks it "failed".

Then the button was hidden. On the public course pages the Enroll Now link is commented out, and students send an enquiry instead, which fits how a small institute actually admits students. So this page doesn't say that real money moves through the site, because right now it doesn't. Two things stand between this and live: the keys in my working copy are Razorpay test keys, written into the code instead of a private settings file, and there is no webhook, so a student who pays and closes the tab straight away would stay "created" until someone checks the dashboard.

The admin has several accounts, each with a role, and each role gets permissions per section: view, add, edit and delete, separately for courses, blogs, enquiries and the rest. Every admin page asks for its permission before it shows anything, so a front-desk login can read enquiries and can't change a fee. The lists in the admin are loaded through small AJAX endpoints, one per screen.

The foundation under it (the bootstrap file, the database and query helpers, the admin shell, the roles system and the image pipeline) is the one I use on other client sites such as Wander Yak, and the two share the same folder layout. I didn't turn it into a generic framework. It's two sites with the same bones, each with its own courses, bookings and design.

The institute has a site that scores 91 on mobile performance and 100 for SEO, with about 10 KB of its own code, and that its own staff can run. Courses, teachers, slides, reviews, blogs and every policy page are theirs to edit, and admin roles keep the wrong person away from the wrong screen.

What it isn't yet: a site that takes payments, a site that emails when an enquiry arrives, or one that scores 100. Those are three small, known tasks, and they're written above instead of left for a visitor to discover.